Szia Jeti,
Elég sok kérdésednek nincs köze az IPv6-hoz, és eléggé eltérő dolgokra kérdeztél rá.
Az 1, 2 , 3, 5, 9, 10, 11 olyan kérdések amelyeknek még megerőszakolva sincs köze magához az IPv6-hoz, illetve maga a megválaszolásban nem kell külön használni az IPv6 kifejezést (nincs kapcsolat)
ezek egy része hálózati kérdés (1, 2, 3) ami hálózati ismereteket igényel. (ezek inkább papírbázisú könyvekből (javasolni nem tudok) vagy wikiből innen kezdve tudsz mélyebb ismereteket szerezni) a kérdéseidre specifikusan már előbb többektől megkaptad a választ.
A 4-es kérdés valódi IPv6 kérdés. Jelentős különbség lesz az IPv4-hez képest. Broadcast fogalma megszűnik helyette az Anycast és a Multicast veszi át ezt a szerepet, a kérdésedre igen a válasz.
Az 5-ös kérdés nem érthető számomra, tippelni sem tudok mit akartál kérdezni, azonos címeket felkonfigurálni? vagy mi ez?
A 6, os kérdés trükkös, mert itt áthallás van IPv4/ARP tekintetében. Az fog változni, hogy hogyan kommunikálnak az IP-vel ellátott eszközök illetve, ha lehet akkor a MAC helyére helyettesítsd be a EUI-64-et (au OUI-król Itt a MAC addressről (EUI-48/MAC-48/EUI-64) Itt olvashatsz. Vagy az IETF idevonatkozó szabványai doksijai adnak részletesebb képet.
A 7-8 az IPSec kérdés és csak annyiban érdekes az IPv6 hogy az IPv6 "kötelező" eleme az IPSec létezése (stack szintjén) de egyébként a kérdések a titkosítás, azonosítás és a IPSec ismeretének hiányára vezet vissza
A 9, 10 ,11 kérdés adat és kapcsolat titkosítással foglalkozó kérdés amit többen kiveséztek.
Semmiképp nem szerettem volna bántásnak szánni semmilyen hivatkozást arra, hogy esetleg nem elégséges a jelenlegi ismereted, csak épp nehéz lett volna enélkül válaszolni.
Annyit még: annak ellenére hogy sok éves bevezetésre kész stádiumban van az IPv6 néhány problémára semmilyen megoldás nincs. Azzal hogy az IPv4 címek igénylése megnehezül azáltal reflektorfénybe került az IPv6 bevezetése ismét, de a problémák még mindig léteznek, és maguktól nem fognak megoldódni
Az egyik ilyen probléma (migrációs jellegű gond):
A szálban elburjánzott az IPv6 NAT kapcsolata, amelynek én nem nyitnék külön topicot, sőt külön hozzászólást sem írnék.
Itt egyesek részéről a NAT úgy van kezelve: Ez egy tévesen security megoldásnak beállított megoldás, amelynek az IPv6 címtartomány méretéből fakadóan semmi értelme. Ez jól van így és nem is kell ez nekünk és nagyon gáz hogy egyáltalán létezik. Aki mást mond minimum "képzetlen".
Én ezzel valamilyen szinten nem értek egyet. Természetesen a NAT NEM egy biztonsági megoldás. Ez egy címfordítás amelynek a megvalósításából ered pár tulajdonság, amely az elterjedtségéből, a felhasználói rétegéből és a jelenlegi környezetből fakadóan fájdalmat fog okozni váltáskor. ezek a következőek:
Renumbering:
Jelenleg PA címeket használ a világ nagy része, így NAT nélkül szolgáltató váltásnál a saját belső hálózat újracímezése és a használt eszközök elérése gondot jelenthet. Erre a NAT kiváló megoldást adott. Most sem egységes a megoldás.
Otthoni (kis méretű hálózat szabvány környezet) felhasználók esetén eszközcserével és némi plusz technológiával ezt át fogják vészelni (bár nem fájdalom nélkül)
A nagyobb hálózatok ahol nat van (nem szolgáltató, hanem vállalkozás) példáúl PI címtartomány igénylésével kerülheti el ezt a problémát. Persze a RIR-ek ezentúl sem fognak örülni a PI kérésnek tehát marad a trükközés.
Több szolgáltató probléma (site multi-homing)
Vannak olyanok akiknek nem elégséges valamilyen okból ha 1 kijáratuk van az internet felé, és nem annyira nagyok, vagy a NAT többi előnyél fogva nem kívántak külön erre a célra szolgáló megoldást találni. Továbbra is lesznek olyanok akik ebbe a státuszba fognak tartozni. Nekik a megoldás jelenleg nem létezik. Az IPv4 megoldás sem volt persze erre tökéletes de most egyszerűen kiváltó alternatíva hiánya lesz. Erre lenne majd kitalálva a Locator/ID Separation Protocol (LISP) IETF LISP draft
Ami még nincs.
Topológia elrejtés
NAT-ot használva elrejthető a mögötte lévő hálózat topológiája, és mérete (persze ez nagyon sok hátránnyal is jár a különböző hálózati alkalmazásoknál)
Nincs alternatíva jelenleg RFC által. A sugalmazott megoldások (host route-ok menedzselése, vagy mobil ipv6 tunnellel nekem picit nevetséges)
(és a kedvenc emlegetett) Egyszerű biztonság
A NAT sokszor van így alkalmazva, és a hatása jó, mivel a képzetlen és tanulni nem is akaró embereket valamint a default konfiggal kiadott (és 4 évig úgy használt) hálózati eszközöket valamennyire megvédi.
Ennek azonban van alternatívája a stateful filtering. Ebből a szempontból szinte ugyanaz( a többi probléma megmarad), csak nincs címfordítás.
Igen lehet úgy tekinteni továbbra is, hogy a világ kis (és tudatlan) részét foglalkoztató probléma. Ettől ezekkel a problémákkal az IAB is foglalkozik RFC5902 ennek kifejtésére született. Persze ők is csak cipőfelsőrész készítők.
Aki pedig nem így gondolja, remélem ez jó vitaindítónak.