IPv6 már az elején elakadtam, help! :)

 ( mauzi | 2012. május 15., kedd - 8:18 )

#define ZOLDFUL TRUE

Gondoltam nagy mellénnyel, hogy 15+ év IPv4 hálózati tapasztalattal, párcsillió IPv6 tutorial elolvasása után, a világ legegyszerűbb topológiájában pár perc alatt rittyentek IPv6-ot.

Hát, nem így lett :P

Adott tehát:

- Egy LAN hálózat, rajta - egyelőre, az egyszerűség kedvéért - csak a Linux kliensek játszanak. A meglévő IPv4 világban a gépek DHCP-vel kapják a privát tartományú (192.168.x.y) címeiket, mégpedig MAC address alapján, statikusan. Néhány gépnek emellett publikus IP címe is van.

- Egy gateway, ami - szintén az egyszerűség kedvéért - egy közönséges Linux PC. A belső hálózat privát címtartományban lakó gépei számára NAT-ol, a publikus IP címes gépek számára pedig sima statikus routeolást végez.

- PPPoE kapcsolat a külvilág felé, szerencsére natív IPv6 támogatással (T-...) Ez működik is remekül.

Problémahalmaz:

1.) Miután beleforgattam a gépek kernelébe az IPv6 támogatást, annak rendje és módja alapján mindenhol felbukkantak a link local címek. Lehet, hogy csak nekem kellene szokni a gondolatot, de ez engem zavar. Nem akarok link local címeket. Minden gépnek lesz szép unique local address címe az egymás közti, ISP-független kommunikációhoz, és global scope címe a külvilághoz. Nem tudom, mire lehetne nekem jó ezeken felül a link local cím. Tehát: link local cím, menj vissza anyádba! Erre a google azt mondta, hogy:

sysctl -w net.ipv6.conf.all.autoconf=0
sysctl -w net.ipv6.conf.all.accept_ra=0

Ellenben ez nekem nem működik. (2.6.38.8) Hogyan lehet tehát kipusztítani egy életre a link local címeket? (Azon túl, hogy ifconfig ethXX inet6 del ....)

2.) Maga a natív IPv6 kapcsolat pillanatok alatt összejött, gyakorlatilag ugyanúgy kell hozzá "behívni" PPPoE-vel, mint IPv4-hez. (kell a ppp options-ba egy "+ipv6" és slussz) Hasonlóképp, a tűzfal szabályokat is pillanatok alatt megalkottam (ip6tables). Eddig öröm és boldogság.

A szolgáltató azt mondja, hogy DHCP6 DUID alapján tudok a belső hálómnak igényelni prefixet. Ezt a mondatot "nyelvtanilag" értem :) viszont az nem világos számomra, hogy pontosan mit és hogyan kellene elindítanom. IPv4 esetében ugye rátolom a DHCP klienst egy interfészre, és ott kér magának IP-t, feltételezvén, hogy azon a broadcast domainen belül van egy DHCP szerver. Na, de itt most a DHCP klienst akkor a PPPoE interfészre kellene elindítanom? És attól hogy lesz IP címe (prefixe) a LAN interfésznek, ami egy másik csatoló? Vagy, a LAN interfészre kellene elindítanom, de akkor honnan fogja tudni, hogy a prefix kérést a PPPoE csatolón kell megtennie? (ISC DHCP-t használok, tehát gondolom, dhclient -6 ... lesz a megoldás eleje)

3.) Ha az előbbi megvolna, és a gateway LAN lábára megérkezne a prefix és az IP cím, jön a következő kérdés: hogyan tudom én ezt tovább hirdetni a belső gépek számára? A doksik főként a radvd-t emlegetik, ami egy egyszerű és érthető szoftvernek tűnik. Azonban, ha jól értem a helyzetet, akkor nem tudok vele statikus IP allokációt végezni a belső gépeknek (DUID alapján) tehát radvd nem a barátom, hanem inkább itt is a DHCP6-tal kellene barátkoznom. Nade, hogyan?

Abból indulunk ki ugye, hogy a gatewayen már fut egy DHCP6 kliens, ami megszerezte a prefixet. Akkor, emellé még egy DHCP6 szervert is kell indítanom? Na, de mit írok a konfigjába, hiszen én nem tudom a prefixet? Vagy tudja hirdetni (A DHCP6 kliens által) az interfészre éppen felkonfiguráltat? És mi van akkor, ha változik a prefix, pl. újracsatlakozik a WAN? Gondolom, tudja értesíteni a klienseket, nem kell megvárni, amíg lejár a lease time, mint a hagyományos DHCP-nél?

Aztán persze vannak még további kérdések is, de ha idáig sikerülne eljutni, akkor legalább a ping kimenne a gépekről :)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

induljunk el innen: "A szolgáltató azt mondja, hogy DHCP6 DUID alapján tudok a belső hálómnak igényelni prefixet."
Szolj a szolgaltatonak es kerj egy prefixet!;)

Mármint a prefixet nekem kell kérni, DHCP6-tal :)
(Az ügyfélszolgálatuk aligha beszéli ezt a protokollt ;))

régen az ügyfélszolgálattól kellett kérni, hogy állítsák be rá;)
Az ügyfélszolgálattól magyar protokolok alapján kell, majd később lehet csak rángatni a döhöcöpöt ilyenért;)

Már a második körnél vagyunk, tehát már megadtam a DUID-ot nekik, tehát elvileg kapom a prefixet, ha elindítom a DHCP-PD-t.

ahh, akkor már megreformálták a dolgot. Bár tény hogy én valamikor évezredekkel ezelőtt foglalkoztam utoljára a dologgal;)

Kiegészítés a 2. ponthoz: wide-dhcp esetében találtam megoldást, hogy PPPoE interfészen intézze a kérést egy másik interfész (eth0) számára végezve a prefix delegálást:


interface ppp0{
send ia-pd 0;
request domain-name-servers, domain-name;
send domain-name-servers, domain-name;
};
id-assoc pd {
prefix-interface eth0{
sla-id 4;
sla-len 8;
};
};

Kérdés, hogy ugyanezt meg lehet-e csinálni ISC-DHCP-vel.

mi a gond a wide-dhcp-vel?

Márkahűség :PPP
Amióta kidobtam a BOOTP-t a DHCP kedvéért (kb. 1995 tájéka) azóta ISC-DHCP-t használok.

Egyébként pedig, szeretem magam sz.patni. Ez eléggé nyomós érv? :)

4.1 vagy újabb verzió kell és megy.

Az van. (Debian: 4.1.1-P1-17)
De hogy kell használni? (man alapján "-P" opció, de semmi további infó)

Nem lehet... egyszerűen...

https://bugzilla.redhat.com/show_bug.cgi?id=626514
https://lists.isc.org/pipermail/dhcp-users/2010-April/011624.html

Évek óta nem képesek megoldani, hogy tudjon ppp interfészen figyelni.

Köszönöm, ez hasznos infó.

Akkor tehát: apt-get install wide-dhcpv6-client...

1, link-local cím kell az IPv6-hoz.
3, T mindig ugyanazt a tartományt adja majd neked DUID alapján. (ingyen egy fix /56-ot, míg a dataplexben ez egy vagyon...)

> 1. link-local cím kell az IPv6-hoz.

Minek? :)

> T mindig ugyanazt a tartományt adja majd neked DUID alapján. (ingyen egy fix /56-ot, míg a dataplexben ez egy vagyon...)

Cool. És ha ez egyszer elmúlik? :) Gondolom, hosszútávon nem lesz minden júzer számára fix prefix...

1, ? (pl.: http://en.wikipedia.org/wiki/Link-local_address#IPv6 )
2, Akkor írjál rá scriptet...

Kiegészítve még az infókat.

Két lehetőséged van a belső hálózat kialakítására (ill. három).
1, Stateless
Ekkor radvd hirdeti a tartományt valamint a defgw-t és a kliensek felvesznek egy EUI-64 címet, de kell egy dhcpv6 server is mert sok kliens (pl w7 sem) nem támogatják az RA által hirdetett RDNS infókat ezért a dns szerver címet a dhcp szerver mondja meg nekik.

2, Statefull
Ekkor is kell a radvd, hogy hirdesse ő a gw, a dhcpv6 szerver pedig osztja a címeket illetve a dns és egyéb infókat. Itt tudsz DUID alapján fix címeket beállítani.

(3,) Kézzel
Kézzel azaz ha pár szervered van belövőd az IPv6 ipjüket, defgw és dns. A gw-n annyi kell, hogy ip forward be legyen kapcsolva ill. fel legyen húzva egy cím a lan interfészen ebből a tartományból vagy legalább a static route be legyen állítva. (persze ez az előző kettőnél is kellett)

> The link-local address is required for IPv6 sublayer operations of the Neighbor Discovery Protocol, as well as for some other IPv6-based protocols, like DHCPv6

Én mondom, hülyén van ez megcsinálva :)))))

Az egésznek az a lényege, hogy ha van az interfésznek link-local címe (amit a host automatikusan fel tud konfigurálni az interfész fizikai címéből), akkor onnantól kezdve ipv6-on el lehet intézni mindent. Pl. ipv6 multicast segítségével lehet elérni az adott linken a routereket, dhcp szervereket, stb. Ne zavarjon, hogy egy interfésznek több ipv6 címe lesz, ez teljesen normális az ipv6 világban, a megfelelő rfc biztosítja, hogy mindig a megfelelő cím kerüljön kiválasztásra. A link-local cím amúgy sem routeolható.

> A link-local cím amúgy sem routeolható.

Az lehet, viszont helyi hálózatban tűzfalazást igényel.

Én nem tenném...
Itt: http://www.sixxs.net/wiki/IPv6_Firewalling sem javasolják.
Egyébként sem futnak rajta szolgáltatások, mégcsak a pingre sem reagál.

Válaszol pingre, nálam pl a dns szerver is azon hallgat és működik. Ugyanolyan működő cím, csak nem routeolható.

nálam nem válaszol...

akkor valamit rosszul csinalsz... intertfacet megadod neki?
[fsanyee@arch ~]$ ping6 fe80::1%br0
PING fe80::1%br0(fe80::1) 56 data bytes
64 bytes from fe80::1: icmp_seq=1 ttl=64 time=0.804 ms
64 bytes from fe80::1: icmp_seq=2 ttl=64 time=0.728 ms
64 bytes from fe80::1: icmp_seq=3 ttl=64 time=0.730 ms
64 bytes from fe80::1: icmp_seq=4 ttl=64 time=0.720 ms

ugyanugy hallgat mindent, ssh-val mindig ezzel a cimmel megyek routerre, mert egyszerubb beirni mint globalt vagy v4-et.

megelőztél, közben rájöttem, hogy elgépeltem az if-et

lassú vagyok:)

> 1, Stateless
> Ekkor radvd hirdeti a tartományt valamint a defgw-t és a kliensek felvesznek egy EUI-64 címet, de
> kell egy dhcpv6 server is mert sok kliens (pl w7 sem) nem támogatják az RA által hirdetett RDNS
> infókat ezért a dns szerver címet a dhcp szerver mondja meg nekik.
>
> 2, Statefull
> Ekkor is kell a radvd, hogy hirdesse ő a gw, a dhcpv6 szerver pedig osztja a címeket illetve a dns
> és egyéb infókat. Itt tudsz DUID alapján fix címeket beállítani.

Bázeg. Tehát ha jól értem, akkor praktikusan mindig kell radvd és dhcpv6 is? dhcpv6-tal nem lehet mindent kiosztani, hogy radvd ne kelljen?

beállíthatod kézzel is;)

A radvd nem csak a címosztáshoz kell, pl. ő válaszol a router solicitation message-ekre, azaz a kliensek a radvd-nek köszönhetően látják routernek a routered.

Biztos rossz kérdés, nem ástam bele magam mélyen a protokoll rejtelmeibe, de kell az nekem, hogy routernek lássák? Nem lehet dhcp-vel kiosztani egy gateway címet, vagy adott esetben kézzel felrouteolni, mint IPv4 esetében?

Kézzel lehet, dhcp-vel nem.

Nem lehet...Vagyis lehet, már van rá RFC, de a még kevés az implementáció. (draft-ietf-mif-dhcpv6-route-option)

Ekkor radvd hirdeti a tartományt valamint a defgw-t és a kliensek felvesznek egy EUI-64 címet, de kell egy dhcpv6 server is mert sok kliens (pl w7 sem) nem támogatják az RA által hirdetett RDNS infókat ezért a dns szerver címet a dhcp szerver mondja meg nekik.

De ez ugye opcionális. dhcpv6 nem kell, csak akkor nem lesz pl. v6-on névfeloldása. De mivel a v4 szerverek is megmondják a v6 neveket ezért ezzel még lehet együtt élni. Persze ha már nekiálltál akkor érdemes végigjátszani mindent, csak kiegészítésnek írtam.

1. +1
Ne tiltsd le a link local, kell a normál működéshez. Csak magadat fogod vele megszívatni.
3. Nevetséges. Rendes szolgáltatók ingyen adják a v6 címeket...
--
Discover It - Have a lot of fun!

Subscribe

+1

sub

+

+1

sub

+1

-+-+-+
Dropbox tarhely
Hockey & Foci Manager
Cave Canem
+-+-+-

+

+1
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.37 | 2.6.39.3-janos

sub


sysctl -w net.ipv6.conf.all.autoconf=0
sysctl -w net.ipv6.conf.all.accept_ra=0

ez ugye NEM a link-local címeket tiltja le, hanem a stateless/autoconf cím"kérést".

Abból indulunk ki ugye, hogy a gatewayen már fut egy DHCP6 kliens, ami megszerezte a prefixet. Akkor, emellé még egy DHCP6 szervert is kell indítanom?
Oszt minek? Ha gateway IPv6 kliens akkor a desktop miért nem lehet IPv6 kliens a szolgáltató felé?

1 DUID-ot regisztrálsz T-nél és egy prefixet kérsz a dhcp szerverüktől amit a te ppp interfészed link-lokal címe felé routolnak. Onnantól kezdve neked kell megoldani a további hálózatoddal kapcsolatos beállításokat.

Jahogy ja. Mea culpa!
Mi a szolgáltató felé fix címtartománnyal megyünk, csak belső hálón dhcp-zünk.

Sőt, az elmúlt fél óra tapasztalata azt mutatja, hogy amíg nem regisztrálod a DUID-odat, addig a PPPoE interfészen kapsz egy scope global címet, amivel egyből tudsz netezni. Ha viszont regisztrálod a DUID-ot, akkor onnantól nincs scope global cím, hanem csak link local címen keresztül tudsz DHCP-PD-vel prefixet kérni.

(És: nem validál a regisztrációs rendszer, így az elgépelt DUID-ot is megette, csak nem ad hozzá prefixet. A DUID eleje ugyanis meghatározza a DUID típusát. És köcsög a T-, mert most azt mondja, hogy elhasználtam a mára engedélyezett 2 DUID regisztrációs lehetőségemet. Mert, ha azt mondják, hogy naponta csak kettő van, akkor biztosan nem regisztrálok be egy "homokozó" DUID-ot. Fsck!)

Ennél kicsit árnyaltabb a dolog:)
PPP interfészt mikor felhúztad kaptál egy címet (/64),mert be volt kapcsolta az autoconf és az accept_ra.
Viszont amikor bekapcsolod az ip forward-ot akkor lekapcsolódik az autoconf és az accept_ra ezért nem kapsz címet a ppp interfészre. És defgw sem lesz beállítva!

B.sszameg, és ezt miért nem lehet minden howto elejére 72 pontos, pirosan villogó comic sans ms-sel kiírni? :)

Idézek neked a debian sysctl.conf-jából:)

# Uncomment the next line to enable packet forwarding for IPv6
# Enabling this option disables Stateless Address Autoconfiguration
# based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1

Nem jártam a sysctl.conf-ban. Egyelőre kézzel kapcsolgattam. Másrészt, a régi jó IPv4 világban, PPP csatlakozásnál az ilyen jellegű paraméterek mind LCP/IPCP paraméterként mentek át, én így jó szokás szerint a PPP adatforgalmat kezdtem el kukkolni. Ezt a Router Advertisement mókát még szokni kell. (Lásd, hogy LAN kapcsolaton is radvd-el szórod ki az átjárót, nem DHCP(v6)-al)

radvdump programmal (radvd-hez tartozó program nem kell külön csomag) meg tudod nézni, hogy T mit hirdet feléd.

Hát igen, bőven van eltérés. Én a Cisco-val szórakoztam sokat, mire a dhcp összeállt. Ugyanis a Cisco alapból RA-zik és ahhoz, hogy a dhcp menjen az interface-en neighbour discovery-t fel kell paraméterezni: ipv6 nd prefix 2001:aaaa:bbbb:cccc::/64 no-advertise
Így már a dhcp-től jönnek a címek.

Használd ilyen esetekben a 2001:db8::/32 tartományt, ha már külön ilyen célra lett megtartva:)

Kössz, ma is tanultam :)

Cool, tehát akkor kiindulván a korábbi probléma-felvetésből, miszerint is radvd-re is szükségem van a gateway miatt, és a dhcpv6-ra is a fix IP címek miatt, akkor ez alapból konfliktust okoz a hálózatban, tehát ahhoz, hogy a kliens garantáltan a dhcpv6-tól kapja a címét, ne pedig a radvd-től, akkor a radvd-ben valamit korlátoznom kell, ugye? Mert én ott elsőre csak azt láttam, hogy milyen prefixet hirdessen, de azt nem, hogy ő csak átjárónak hirdesse magát ennek a hálózatnak, vagy címet is fogadjanak el tőle...

prefix + eui64 nem eleg fix?

Nem. Nem szeretnék IP címeket és/vagy DNS bejegyzéseket módosítani, ha kicserélek valahol egy hálókártyát. Vagy éppen Mancika nyomtatóbeállításait átírni, ha lefossa a bokáját az egyik Jetdirect.

Lásd PunishR 8:49-es írását:
http://hup.hu/node/114531#comment-1458586

Ez oké, csak azt nem látom még, hogy ha egyidejűleg van radvd és dhcpv6, akkor garantált-e a dhcpv6 elsősége IP osztásra.

Nem ismerem behatóan a radvd, így pár perc doksi nézegetés és google után szerintem ez az amit keresel:
link
Tehát vagy radvd vagy kliens oldalon kell gondoskodni róla, hogy az stateless ne működjön. Ha dhcp is van meg statless is akkor nem tudom mi történik, elképzelhető, hogy mind2 oszt címet.

a radvd nem oszt cimet.
a kliensben beallitod hogy milyen cimet szeretnel az interfacenek (static/stateful/stateless).

ok, csak prefixet ad, ha a kliens stateless, kezdek megvilágosodni :)

Garantált, ha radvd úgy van konfigurálva.

Bővebben itt egy régi, de jó leírás a stateless és stateful radvd/dhcpv6 beállításról:
http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf

Oké, akkor lépjünk tovább:

A forward kell, hiszen ez a gép lesz az átjáró a belső hálózat számára. Így tehát, ha most belépek, akkor felépül a kapcsolat, de stateless autoconf hiányában csak Link-local címeim vannak a PPPoE kapcsolaton. Hogyan fogok én ezen akkor kifelé látni? Kézzel, statikusan nem tudom felkonfigurálni, mert nem tudom a címeket...

És mégegy kérdés:

A "belső" gépen konfiguráltam magamnak kézzel, statikusan IPv6 címet. Ennek ellenére, a gép RA-val is konfigurált magának egy címet. (azonos prefixszel)

Ha jól értem, akkor ezek szerint ha statikusan akarok konfigurálni, akkor a sysctl változót az adott interfészre feltétlenül át kell állítanom 0-ra, ugye? (Tehát a neighbour discovery magától nem jön rá arra, hogy hopp, ilyen prefixszel már van statikus címünk, akkor nem kell stateless is?)

Ha csak manuálisan konfigurált címet akarsz, akkor valóban kapcsold ki az RA hirdetések kezelését.

A ND és DAD nem foglalkozik azzal, hány cím van az interfészen, mert egyiknek sem dolga. Ahogy már többször megírták, az IPv6-nál az a normális, hogy egy interfésznek sok címe van.

Ennek ellenére, a gép RA-val is konfigurált magának egy címet. (azonos prefixszel)

Akkor a radvd konfig nem jó. Biztos hogy RA-val konfugurálódott és nem dhcp-vel?

De, minden rendben van. A radvd úgy van konfigurálva, hogy legyen stateless autoconf, csak egy gépen nem akartam. dhcpv6 szerver egyelőre nincs a hálózatban.

A /etc/network/interfaces-ben (Debian) kapott az interfész egy ilyet:
pre-up /sbin/sysctl -q -w net.ipv6.conf.eth0.autoconf=0

A sysctl.conf nem jó, mert sorrendbeli problémák vannak bootolásnál.

Így viszont minden klafa.

a pppoe-re nem is kell global cim, amit korabban copyztal dhcp6c.conf abban is eth0-ra huzza ra. megnezed a prefixet, aztan mar tudod statikusan allitani a cimet.

duidot kezzel is meg lehet adni, nalam is egy korabban regisztralt duid-dal dolgozik a router.
az volt az erdekes hogy amikor regeltem a T-nel, enis tobbszor tettem, de nem az utolso volt az ami mukodott hanem egy korabban regisztralt.

Lényegében itt is fix lesz a tartomány/duid páros.

No, ez lehet valahol el van rejtve a szövegben csak én nem találtam meg elsőre: Melyik szolgáltató oszt neked IPv6-ot (is)?

--
"A herceg én vagyok."

"PPPoE kapcsolat a külvilág felé, szerencsére natív IPv6 támogatással (T-...) Ez működik is remekül."

Magyar Telekomnak van még mindig teszt időszaka, de csak dsl és optinettel.
Egyébként az Externet oszt még.

+1
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

Újabb probléma van. Mutatom a jelenlegi IPv4 hálózati topológiát:

---- WAN kapcsolat publikus IP-vel ----[ ROUTER 1 ]---- Belső subnet #1 privát IP-vel ----[ ROUTER 2 ]---- Belső subnet #2 privát IP-vel

- Belső subnet #1 és Belső subnet #2 között közönséges routeolt hálózat van, a ROUTER 2 jóvoltából.
- Mindkét belső háló a ROUTER 1-en keresztül lát ki a külvilágba (NAT)

Namostan, hogyan tudnám mindezt IPv6-ra átültetni?

Addig oké, hogy ROUTER 1 PPPoE-n kap natív IPv6 kapcsolatot, amin DHCPv6-PD-vel kér egy /64 prefixet a rendelkezésre álló 256-ból (a szolgáltató /56-ot ad) a Belső subnet #1 számára.

Na, de hogyan fogok delegálni a ROUTER 2 mögött lakó gépeknek egy másik /64 prefixet?

(A kapcsolódási topológiát nem lehet megváltoztatni. A két külön tartománynak meg kell maradnia, és nem lehet a subnet #2-t a ROUTER 1-re fizikailag csatlakoztatni.)

router 2 is egy linux?

Most minden szereplő Linux, mert a tanulási fázisban legalább azzal nem akarok szívni, hogy a különböző oprendszerek/IP stackek/júzerszpész okosságok miben működnek másképp...

(Linuxhoz a legegyszerűbb dokumentációt, és support közösséget találni. Ha majd akkor is megy, ha álmomból felébresztenek, akkor jöhetnek mindenféle cickók meg ablakok)

Ott van még 255db /64-es prefixed. Kiválasztasz egyet, a ROUTER 2 pedig radvd-vel hirdesse azt a subnet #2-nek. A ROUTER 1 számára állítsd be, hogy a kiválasztott prefix a ROUTER 2 mögött van. A ROUTER 2-nek pedig a ROUTER 1 legyen a default gw. Teljesen, mint IPv4-nél :-).

Kösz, kipróbálom. Biztos voltam benne, hogy van benne valami csavar az IPv4-hez képest :)

[update: működni látszik]

A dhcpv6c egyébként mit csinál, miután(!) megkérte a prefixet? Mert ha kilövöm, akkor megáll az adatforgalom, hiába vannak továbbra is felkonfigurálva az interfészek és a routeolás... Értem én, stateful...

Még okosság:

a.) valaki magyarázza el please, hogy miért jó nekem gateway-ként a link local címet megadni, ha egyszer van velem egy hálózatban lévő (= azonos prefixszel rendelkező) gateway cím?

b.) hogyan jutok át publikus (global scope) IP-vel úgy egy PPP linken, hogy a link végpontjának csak link local címe van? (feltételezem, hogy a link local felett a ND megbeszéli multicasttal, hogy kik a valódi gatewayek?!)

a, Ez egy ajánlás, de ha másik címet használsz nem lesz gyorsabb vagy lassabb a kapcsolatod, csupán a link-local címed mindig ugyanaz lesz kizárva ezzel pár hibalehetőséget.

b, Csak vedd alapul az otthoni hálózatodat, ahol te is routeolsz link-local címek között.

> a, Ez egy ajánlás, de ha másik címet használsz nem lesz gyorsabb vagy lassabb a kapcsolatod,
> csupán a link-local címed mindig ugyanaz lesz kizárva ezzel pár hibalehetőséget.

Vegyes érzelmeim vannak ezzel kapcsolatban. Eddig, ha volt egy Layer 3 IP hálózatom, akkor azonos szinten, a Layer 3 hálózat tagjai közül mondtam meg, hogy "ki a főnök". A link-local címmel kicsit belevonom a rendszerbe a Layer 2 szintet, hiszen kiindulván abból, hogy Pistike mondjuk hardver okokból kicseréli a routert, azzal változik az MAC-48, attól változik az EUI-64, és már cseszhetem is a többi gépen beállított átjárót. Az ajánlás nekem mondhatja, hogy hallgassak az ilyenkor érkező friss NDP RA hirdetésre, én a statikus beállítást néha praktikusabbnak és átláthatóbbnak tartom. (Aztán majd pár év IPv6 használat után lehet, hogy azt fogom mondani, hogy hej' de jó ez így)

> b, Csak vedd alapul az otthoni hálózatodat, ahol te is routeolsz link-local címek között.

Ezt a példát most nem értettem. (vagy Te nem értetted a kérdésem lényegét)

link local cimet ugyanugy beallithatod kezzel, nem kozelezo eui-t hasznalni.

Nézzünk 3 esetet:
1. stateless RA hálózat (router határoz meg mindent)
2. statefull hálózat (IPv6 dhcp-től, átjáró RA)
3. kézi konfig

1. a géped megbeszéli a link-local átjárót is meg az ip perfixet is a routerrel. Nincs beállítanivalód. Pistike kicseréli a routert, akkor a desktopod és a router megint meg fogják beszélni az átjáró és ip cím kérdéseket, nincs tennivalód.
2. megkapod a link-local átjárót a routertől, az ip-t a dhcp től. Pistike kicseréli a routert, akkor a desktopod és a router megint meg fogják beszélni az átjáró kérdést és a korábbi címedet megkapod a dhcp-től. Nincs tennivalód.
3. kézzel állítasz mindent (global ip című átjáró+global ip), Pistike akármire cseréli a routerét, ha a global ip címét nem változtatja akkor nincs tennivalód.

Ezen a linuxos gépen amiről írok a default ipv6 átjáró a router global ipv6 címe, mert ez egy kézzel beállított gép. Ugyanezen a hálózaton futó win7-nek meg a router link-local címe mert az meg egy statefull dhcp-s gép.

Nem tudom, segített?

A működést értem. Azt nem értem, hogy miért _jobb_, de mindegy, túltárgyaltuk a témát.

Ha autoconf van, és radvd küldi a gatewayt, akkor ugyanazzal az energiával, amivel a link-local címet küldi, küldhetné a global címet is. Ha meg kézi beállítás van, akkor meg úgyis az van, amit beállítok. Tehát, nem látok pro/kontra érveket. Akkor én meg maradtam volna a "régi módinál".

Téma lezárva :)

Van a két routered amik szintén csak egymás link-local címeit ismerik, de r1 tudja, hogy a r2 felé van a másik /64-ed static route miatt. Illetve r2 is tudja, hogy r1 link-local címe felé van a 2000::/3. A ppp linkednél ugyanez a helyzet. A cső másik végén tudjak, hogy feléd van az a /56, persze ha lelövöd a dhcp6c-t akkor letelik a lease time és megszakadsz. Te pedig szintén bezavarod a csőbe a 2000::/3 felé menő forgalmadat (ip -6 r).
Ne zavarjon meg, hogy nincs link-global cím a ppp if-eden. Diginél nekem pl v4-nél 10.0.0.1 másik végpont.