FreeWifi: Privátní 6to4 adresy?

3.2.2012 14:36 | Přečteno: 1768× | ostatní

3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:13:ce:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.193/24 brd 192.168.1.255 scope global em2
    inet6 2002:c0a8:102:1234:213:ceff:fexx:xxxx/64 scope global dynamic 
       valid_lft 298sec preferred_lft 118sec
    inet6 fe80::213:ceff:fexx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

Úvod

V bruselském hotelu máme k dispozici free wifi, přes které jsou přidělováný IPv4 i IPv6 adresy. Co mě ale zaujalo, že obě adresy, které jsem dostal, jsou privátní ve smyslu neroutovatelné z Internetu.

Na IPv4 je to běžná praxe, používá se privátní adresa například z rozsahu 192.168.1.0/24 jako zde a pro navázání TCP spojení a UDP pseudospojení se používá IP maškaráda neboli NAT většího množství privátních zdrojových adres na jednu veřejnou zdrojovou adresu.

Na IPv6 je použití privátních adres méně běžná praxe, používají se rovněž proto vyhrazené rozsahy, a zpravidla se privátní adresy používají pro přístup k místním službám případně proxy serverům. NAT se v tomhle případě nepoužívá a adresy se považují za čistě lokální.

6to4 se používá pro vytvoření veřejných IPv6 adres tam, kde není k dispozici nativní veřejný rozsah IPv6, ale je k dispozici alespoň jedna IPv4, která tvoří druhou a třetí šestnáctibitovou skupinu v IPv6 adresách.

Privátní 6to4

Co ale vidím poprvé je, že někdo pro něco více než jen rychlý test používá IPv6 prefix složený ze 6to4 prefixu 2002::/16 a privátní IPv4 adresy.

inet6 2002:c0a8:102:1234:213:ceff:fexx:xxxx/64 scope global dynamic

# python3 -c "print([int(b, 16) for b in ['c0', 'a8', '01', '02']])"
[192, 168, 1, 2]

Testování

# ping6 info.nix.cz
PING info.nix.cz(info.nix.cz) 56 data bytes
64 bytes from info.nix.cz: icmp_seq=1 ttl=60 time=105 ms
64 bytes from info.nix.cz: icmp_seq=2 ttl=60 time=103 ms
64 bytes from info.nix.cz: icmp_seq=3 ttl=60 time=135 ms

IPv6 tedy kupodivu funguje, ale například stránka http://www.test-ipv6.com/ prozradí, že vnější svět mě vidí pod adresou 2002:5e6c:1de:1234:213:ceff:fexx:xxxx.

# python3 -c "print([int(b, 16) for b in ['5e', '6c', '01', 'de']])"
[94, 108, 1, 222]

Pomocí dalších testů se ukázalo, že je celá síť mapovaná a vnitřní počítače jsou tedy dostupné pomocí vnější IP adresy, kterou ale nastavenou nemají. Substituce funguje obousměrně, jako klasické symetrické mapování.

Každý počítač má tedy přímo přidělenou nesmyslnou adresu a nepřímo (pomocí 1:1 NAT namapovanou) veřejnou 6to4 adresu.

Závěr

Napadá mě jedna jediná otázka....

Proč?        

Komentáře

[Piškot]

Nemají vlastní přidělené adresy, ale adresy providera. Mohou je střídat a tak nemohou rozdat veřejné. Natovat je mohou do dvou síti různých providerů podle potřeby (výpadku). Nic jiného mě nenapadá.

[Sten]

To všechno by hravě vyřešil správně nastavený router advertisment + prefix delegation (při výpadku dostane router informaci o novém rozsahu od ISP, následně síti oznámí, že se změnil rozsah, a všechna zařízení se automaticky překonfigurují). Spíše bude důvodem neznalost.

[Radovan Garabík]

A čo to spraví s existujúcim TCP spojením? (uvedomujem si, že je to akademická otázka, výpadky asi nenastávajú každých pár minút, a pád TCP spojenia raz za pár dní je nepodstatný, resp. treba s tým počítať)

[Sten]

To samý, co teď: spadnou, protože vnější IPv6 adresa se stejně změní. A pro místní použití jsou link-local nebo site-local adresy.

[sigma]

V lokální síti, která je trochu větší než malá, tohle často narazí na různé problémy. Třeba zajištění rychlého, spolehlivého a stabilního "přepnutí" RA + prefix delagation skrze několik vnitřních routerů.

Ještě horší je komunikace lokálních klientů mezi sebou. Jo, jsou na to site-local adresy. Jenže často je problém, jak donutit všechny klienty použít správnou zdrojovou+cílovou adresu pro daný typ provozu. Zvlášť v případě Windows.

Nemusí to být neznalost. Existuje RFC6296 - NPTv6 - může to být klidně jeho aplikace. Já bych jeho použití nepovažoval za neznalost nebo obecně špatnou věc. Někdy se trvale stabilní adresy počítačů v LAN hodí, a hodí se že neexistuje komplikace přítomností dalších ISP-dependent adres na každém rozhraní.

[w4rr10r]

To už je zase FOSDEM? Kruci, úplně jsem na to zapomněl.

[pavlix]

Už to tak bude :).

[David Jaša]

Network Prefix Translation v akci...

[petr_p]

Dokážu si představit proč, jen by mě zajímalo, jestli také funguje FTP nebo SIP. Správce by stejně zasloužil za uši, když si není schopen vygenerovat ULA prefix, ať je aspoň na první pohled vidět, že to Internet není.

[Kvakor]

SIP moc velký problém není, používá jen jeden port (5060, případně 5061 pokud se šifruje), ale u FTP jsou třeba dva a druhý je dynamický. Navíc starší klienti nemůžou jet nativně přes IPv6, protože se IP adresa a port datového spojení se posílá (v příkazu PORT) jako šestice čárkou oddělených čísel v rozsahu 0-255, zatímco v IPv6 se posílá (v příkazu EPRT) běžně napsaná adresa a port, oddělené svislítky. Pokud klient a/nebo server rozšířený standard (RFC 2428) neumí, tak má u IPv6 smůlu.

[pavlix]

SIP moc velký problém není, používá jen jeden port (5060, případně 5061 pokud se šifruje)

Tak nepřepokládám, že bys SIP používal jen tak naprázdno, takže se sem tam ještě nějaký ten portík hodí :). Ale volání mi funguje. Přece nebudu volat z mobilu.

[petr_p]

Pokud si přes SIP neposíláte jen zprávy, tak potřebujete přenést síťovou adresu pro RTP, kterýžto samotný přenáší multimédia. Ostatně i u obyčejného SIP pro registraci potřebujete něco napsat do hlavičky Contact. Je pravda, že kvůli zkriplenému IPv4 všichni SIP klienti implementují ICE nebo STUN, takže tady to asi funguje také.

FTP mi nemusíme vysvětlovat, dopisoval jsem jej do linksu. Samozřejmě, když se bavíme o FTP v IPv6, tak jsem předpokládal, že se bavíme o klientovi, který IPv6 umí.

Čekal jsem, že ctěné obecenstvo pochopí, kam dotazem mířím (jestli je implementován jen tupý překlad adres, nebo i přepis na úrovni aplikační vrstvy), protože to je přesně ten problém, který NAT vytváří.

[David Jaša]

FTP by fungovat mělo, pokud ho propustí případný firewall, protože mapování je staticky 1:1 a tudíž funguje oběma směry.

[petr_p]

EPRT.

[pavlix]

Tak, FTP k ničemu nepotřebuju (co je na FTP je i na HTTP), ale odchozí SIP hovor proběhl.

když si není schopen vygenerovat ULA prefix

No... mě přijde spíš škoda, že ty adresy nepoužívá přímo. Vždyť není zas takový problém provozovat dynamický prefix.