IPv6 a vše kolem

ladik souhlas s petrbacina. Nám přechod na IPv6 only výrazně zjednodušil (serverovou) infrastrukturu, zlikvidoval NAT boxy, zlikvidoval problémy s kolizí IP rozsahů mezi různými VPN, zjednodušil firewally. Když se teď dostanu občas k nějaké infra s NATem, tak si připomenu všechny nepěkné stavy, které jsme tím zlikvidovali. Neříkám, že to bylo zadarmo a nějaké investice to ještě bude stát, jak se to bude rozšiřovat a budou komplexnější DDOS útoky, ale jednoznačně musím říct, že přechod stál za to.

Tak i tak se tomu ale další generace nevyhnou, takže vlastně proč to neudělat hned.

ladik tech prinosu je spousta a kazdy si muze najit "ten svuj". Napriklad:

• neexistence koliznich rozsahu (nejen u VPN, ale treba pri propojovani vice siti pri odkupu firem)
• snizeni vytizeni operatorskeho NATu (pokud vetsina provozu pobezi po sestce)
• skutecna redundance cest v siti a zjednoduseni navrhu site (neni potreba routovat vse skrz jeden active/passive NAT)
• globalni (verejna) adresa az ke klientovi na pocitac, takze lze realne pouzivat i jine protokoly nez TCP a UDP (uznavam, tohle vyuzije malokdo) nebo zpristupnit vice zarizeni v siti zakaznika na standardnim portu (napr. nekolik webserveru na portech 80/443 za jednim IPv4 NATem jednoduse nezprovoznim)
• neomezene mnozstvi adres pro aplikace narocne na adresy (kontejnerizace)
• single stack IPv6-only serverova infrastruktura s prekladem IPv4<->IPv6 na hranici site (zjednodusuje konfiguraci a pritom zpristupnuje sluzby do "obou internetu")
  a dalsi a dalsi a dalsi.

miract Následující ber čistě jak to vidím já. My jsme členem RIPE, adresy nepřeprodáváme a tuhle situaci jsem ještě neřešil.

Pokud nejsi členem RIPE, tak předpokládám, že máš IP adresy od nadřazeného ISP. Stejně jako od něj získáváš IPv4 rozsah, tak od něj můžeš dostat blok IPv6 adres. RIPE dává /29 rozsah, který je dostatečně velký na to, aby se mohl segmentovat na větší bloky než doporučených /48 nebo /56. Pokud máš vlastní AS, tak nejmenším routovaným rozsahem by měl být /48, takže tam by omezení být nemělo.

Takže můj osobní názor je, že je to jen o domluvě mezi tebou a tvým upstreamem, který by ti klidně mohl přidělit /32.

miract a mate IPv4 PI nebo PA adresy (lze overit z whois)?
Jde hlavne o zachovani adres i pri prechodu k jinemu upstream ISP, nebo jde o to, ze upstream nechce "dat vic adres"?

miract a jak resite problem, kdy PI adresy mate pouzivat jen pro potreby vlastni organizace, ne pro sve zakazniky? Nebo neresite?

Je tam pravě ta výjimka pokud používáš NAT. Veřejná IP je fyzicky na mém železu. Ale to tu přeci neřešíte. Mě zajímá IPv6.

miract tou vyjimkou si nejsem jisty, ale hlavne tim chci rict, ze PI adresy nejsou pro poskytovani sluzeb jako ISP vhodne. V IPv6 dokonce uplne nepouzitelne.
Spravne reseni tedy je PA blok od nejakeho LIRa, pripadne stat se LIRem.
Technicky je mozne mit adresy od LIRa X, ale ten LIR vubec nemusi byt upstream ISP. Staci, kdyz v RIPE DB vytvori spravne route6 objekty (sparovany prefix a cislo autonomniho systemu). Kdysi o tom mluvil @bach na workshopu k IPv6, ze ISPAlliance takovou variantu nekterym clenum umoznila.
Samozrejme je potreba ro udelat spravne, pokud LIR X ma prefix 2001:db8::/29 a propaguje do sveta 2001:db8::/32, musi timhle zpusobem pridelit napr. 2001:db9:100::/40, 2001:db9:200::/40, atp.

Prakticky ale i v /32 muze byt dost tesno.

miract ze by stat se LIRem?

Pokud je jediná možnost jak IPv6 získat stát se LIRem, tak to odkládám na neurčit a tím to pro mě tato diskuze zase na dlouho končí. Se potom nedivte, že většina malých a středních ISP nemá o IPv6 zájem...

miract a co je maly? 150 lidi ... Uz od 500 se da uvazovat byt LIRem a i kvuli backup lince ...

miract porad je tu moznost IPv6 PA pridelu od toho LIRa, ktery Vam "zajistuje" IPv4 PI a ASN dnes. Nemusi to byt jen ISPA.
(Adresni plan uz mate? Jak velky blok byste pro sit potrebovali?)

Dobrý den @miract , Vám Váš aktuální LIR IPv6 nepřidělí? Pokud byste chtěl, máme jako ISPA i službu LIR sponzoring. Kdy se Vám o adresy můžeme starat a i přidělit IPv6 blok. Můžete mi napsat i na přímo na ladislav.ruzicka@ispalliance.cz

ISP, prosím. Když už nasazujete IPv6, tak to udělejte pořádně.

https://www.ripe.net/publications/docs/ripe-690#4-2-2---48-for-business-customers-and--56-for-residential-customers

4.2.3. Prefixes, longer than /56
It is strongly discouraged to assign prefixes longer than /56 unless there are very strong and unsolvable technical reasons for doing this.

There are enough IPv6 addresses to delegate end-users a /48, so a /56 already represents a sizeable restriction. There is no need to delegate fewer addresses than that, so if your IPv6 allocation is insufficient to provide a /56 to each end customer (remember there are 134 million /56s in a /29 and 16,7 million in a /32), explain to your RIR that your initial allocation was too small and that you require a larger allocation based on your IPv6 implementation plan. Offering less than a /56 can be feasible if just a /29 is allocated and 6RD is being used, as an IPv4 address is embedded in the IPv6 prefix. However, even in this case, a larger allocation from your RIR can be justified and the transition protocol allows other ways to sort it out.

Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc.

Teď to řeším s Giganet.cz, kteří přidělují jen /64 na přípojku, takže IPv6 nasazovat do jedné kanceláře nebudeme, protože by bylo dostupné jen pro jedno oddělení a zbytek by jel na IPv4. Tuhle nekonzistenci v síti nechci.

skrivy u nás dáváme /48 ..

https://www.google.com/intl/en/ipv6/statistics.html

IPv6 podle googlu poskočilo na 40%. Tak co, kdo se ještě brání pokroku?

Jinak update s giganetem (a mám pocit, že jsem to psal, jen to tu nevidím) - po výměně několika emailů jsme dostali /48, takže spokojenost.

skrivy tak brání se třeba všechny iptv a sip služby