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

IPv6

#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 :)

( Mcsiv v | 2012. 05. 15., k – 09:32 )

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!;)

( mauzi v | 2012. 05. 15., k – 09:35 )

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.

( PunishR v | 2012. 05. 15., k – 09:37 )

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, ? (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)

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ó.

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.

> 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?

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.

( Mik v | 2012. 05. 15., k – 11:38 )


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é?

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!

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)

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.

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...

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.

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.

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.

( ha1dfo | 2012. 05. 15., k – 18:17 )

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."

( mauzi v | 2012. 05. 17., cs – 21:55 )

Ú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.)

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)

( mauzi v | 2012. 05. 18., p – 00:00 )

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.

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)

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.