Současné možnosti získání veřejné IPv6 za NATem

pavels

Re:Současné možnosti získání veřejné IPv6 za NATem.
« Odpověď #15 kdy: 11. 02. 2017, 15:13:05 »
Dotaz: Lze v domací (Mikrotik) síti používat IPv6 (only) i bez (stabilního) připojení?

Jde o to, že pokud mi vypadne internet, pořád bych chtěl aby mi fungovala alespoň lokální síť.


Jenda

Re:Současné možnosti získání veřejné IPv6 za NATem.
« Odpověď #16 kdy: 11. 02. 2017, 15:50:07 »
Jak lokální adresy (fe80), tak adresy přidělené RA běžícím na Mikrotiku, budou dál normálně fungovat.

M.

Re:Současné možnosti získání veřejné IPv6 za NATem.
« Odpověď #17 kdy: 11. 02. 2017, 16:06:33 »
Dotaz: Lze v domací (Mikrotik) síti používat IPv6 (only) i bez (stabilního) připojení?

Jde o to, že pokud mi vypadne internet, pořád bych chtěl aby mi fungovala alespoň lokální síť.

Možnos je vygenerovat si ULA (unique local address fc00::/7) prefix o velikosti /48, který používám pořad stejně v rámci vnitřní sít a vedle něj paralelně nějaký globální dle toho, co mám od ISP aktuálně přiděleno. Lokální zařízení tak mám pořád stjně na stejných ULA adresách a jen provoz ven na globálních.
Čístý IPv6 only provoz v domácí síti je relaticně smutný, pokud je podpořen NAT64, tak dnes realativně OK (sám to tk mám), poku nemám doma věci, co jsou vyloženě IPv4 only.

rezerovávné jméno

Re:Současné možnosti získání veřejné IPv6 za NATem.
« Odpověď #18 kdy: 11. 02. 2017, 22:15:26 »
Tak jsem teda rozchodil teredo. na http://nic.cz mi ve frirefoxu svítí u IPv6 zelená, v Chromiu červená :D a když se přes http://www.ipv6proxy.net/ na tu adresu podívám, tak to i funguje. Ještě nevím proč mi ale nejde, když mám 2 zařízení s teredy, tak se navzájem nepingnou (ani ten server) nejede i přestože ping z internetu (http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-ping.php) na oba jde a oba můžou pingnout ipv6.google.com.

M.

Re:Současné možnosti získání veřejné IPv6 za NATem.
« Odpověď #19 kdy: 11. 02. 2017, 23:12:18 »
Protože přímá komunikace mezi dvěmi teredo konci funguje kapánek jinak, než při teredo-zbytek IPv6 světa. Záleží na typu NATu, za kterými jsou klienti, protože dva Teredo klienti snaží bavit přímo mezi sebou přes ty svoje NATy (Teredo server se použije jen pro otevření UDP portu v NATu a Teredo relay se nepoužívá).
A situace se ještě výrazně komplikuje, pokud oba Teredo konce jsou za stejným NATem, ale nejsou ve stejném LAN segmentu (pokud jsou velde sebe na LAN, tak se mají nají přes multicast a bavit se přímo), zde bývá totální smůla.


Kolemjdoucí

Re:Současné možnosti získání veřejné IPv6 za NATem.
« Odpověď #20 kdy: 12. 02. 2017, 18:13:12 »
Je nutné to tunelovat i s Ethernetem? Proč do IPv4 paketu nenacpat rovnou IPv6 paket?

Pokud máte jen /64 tak ethernet umožní jednu z těch adres nechat rovnou na VPS (a zároveň to bude default gateway pro domácí síť) a na protistraně použít bridge. Navíc to umožní spustit na VPS radvd což zajistí že při delší nedostupnosti VPS všichni klienti v domácí síti automaticky mohou přestat používat globální IPv6 adresu což povede k tomu že budou do internetu komunikovat přes IPv4 (neboli nebudou odříznutí od dual-stack serverů).

A adresa z toho /64 bloku je přidělena na eth0 toho VPS. Je v tomto případě správné a vůbec možné tunelovat celé /64? Tunelovat celé /64 v podstatě ani nepotřebuju.

Spousta lidí si myslí že v IPv6 můžou fungovat i s užšími podsítěmi než /64, ale zadělávají si tím na problémy - viz např. https://tools.ietf.org/html/rfc5375#section-3

Pokud by navíc u eth0 na VPS byla sirší maska než /64 (třeba /56) tak bude potřeba pořešit odpovědi na neighbor solicitation, rozhodně ne tak že VPS bude odpovídat že má všechny adresy z /64 (to by vedlo na přeplňování tabulky na default gateway poskytovatele VPS) ale buď to nakonfigurovat ručně jen pro používané IPv6 adresy v domácí síti (to je otrava a navíc to nefunguje s privacy extensions které například Android vyžaduje) nebo použít něco jako ndppd s "iface tap0" což do tap0 (to je ten ethernetový tunel) bude neighbor solicitation přeposílat.