Számítva arra,
hogy az Olvasó jártas az IPv4 unicast routing technikákban és legalább
minimális ismeretekkel rendelkezik az IPv6 alapjairól, ebben az írásban összefoglalom
az IPv6 unicast routing újdonságait a tudomány jelenlegi állása szerint.
Az Internet
Protocol új verziója, az IPv6 egyre közeledik. Az Internet Engineering Task
Force-nak (IETF) egyik aktuális témája az IPv6, csak úgy, mint néhány Regional
Internet Registry (RIR) munkacsoportnak – hogy csak néhány példát említsek.
Sokan úgy gondolják, hogy előbb vagy utóbb ténylegesen el is fog érkezni
az IPv6, és egy feltehetőleg hosszabb együttélés után fel fogja váltani az
IPv4-t. Mivel a unicast IP routing alapvetően arról szól, hogy ismereteket
szerezzünk IP címtartományok helyéről és irányáról a hálózatban, majd ezen
ismeretek alapján továbbítsunk IP csomagokat a megfelelő irányba,
nyilvánvaló, hogy a routing protokollokat fel kell készíteni egy új IP verzióra.
A jó hír ezzel kapcsolatban az, hogy amit ma az IPv6 unicast routingról tudunk,
az nem tér el nagymértékben az IPv4 routingtól. A kissé rossz hír pedig az,
hogy a kép nem teljes még, ahogy ezt a „Megoldatlan problémák” című
fejezetben röviden ki is fejtem.
A routerek
különféle forrásokból gyűjtik össze a hálózati topológia információt. Az
adminisztrátor hálózati címeket állít be a router interface-ein és statikus
route-okat konfigurál. További topológiai információt tanul meg a router
dinamikusan, routing protokollok segítségével más routerektől. Ezek az
információk a routing table-be kerülnek, ahol aztán a router folyamatosan
gondoskodik a frissen tartásukról, hogy lehetőleg mindig a hálózat
pillanatnyi topológiáját írják le. Amikor egy IP csomag érkezik a router egyik
interface-én, akkor a router a csomag IP fejlécében található cél címet
kikeresi a routing table-ből, hogy kitalálja, merre kell továbbítania a
csomagot. Ez természetesen egy nagyon leegyszerűsített modell, azonban
mégis elegendő az IPv6 unicast routing alapvető koncepcióinak
tárgyalásához, melyek azonosak az IPv4 routing alapelveivel.
Az IPv6 cím 128
bites, négyszer olyan hosszú, mint egy IPv4 cím. Egyik tanárom a
kriptoanalízissel kapcsolatban jegyezte meg viccesen: „21000 fele
sajnos nem 2500, hanem 2999”. Hasonlóan nem csak négyszer
annyi IPv6 cím van, mint IPv4, hanem 296-szor annyi. Azonban ha a
unicast routing protokollokról beszélünk, akkor nem annyira a címek mennyisége,
hanem inkább a lehetséges prefix hosszúságok érdekesek, hiszen ez utóbbin múlik
többek között az aggregáció lehetősége. Ilyen tekintetben az IPv4 és az
IPv6 különböző. Mivel CIDR-t (Classless Inter-Domain Routing) használunk,
az IPv4 címekben nincs fix méretű host rész. Bizonyos esetekben mindössze
csak egyetlen bit a host rész a 32-ből. Ezzel szemben az IPv6 címek host
része szinte kivétel nélkül 64 bites.
Hasonló a helyzet
a hálózati résszel. Az IPv4 címek hálózati részének nincsenek szabványokban
definiált fix határai. Egy intézmény vagy telephely tipikusan 16-28 bit hosszú
prefixet használ, bár ez csak egy nagyon durva közelítés. 24 bitnél hosszabb
prefixeket nem illik BGP-vel meghirdetni a default-free zónába (DFZ) – ez nem
szabály, hanem a jelenleg elfogadott gyakorlat. Ehhez képest az IPv6 címek
hálózati részéről legalább annyit el lehet mondani, hogy van egy
többé-kevésbé fix határ benne: egy telephelyi IPv6 prefix rendszerint 48 bit
hosszú. A jelenleg érvényes ajánlások rövidebb prefix kiosztását csak speciális
esetekben javasolják, csak a címosztó „hatóság” általi jóváhagyással. 48 bitnél
hosszabb prefixek sem kerülnek kiosztásra általában. Kivételes esetben szó
lehet /64-es vagy /128-as telephelyi prefix kiosztásáról, ha a kapcsolódó
hálózatban csak egy subnetre vagy egy gépre van szükség vagy lehetőség
műszakilag.
A nagy különbség
ezen a téren az IPv4 és az IPv6 között tehát az, hogy az utóbbi esetben egy
átlagos subnet hostjai kényelmesen elférnek a /64-es prefixben, és a legtöbb
intézmény vagy telephely könnyen ki tudja alakítani a /48 és a /64 közti 16
biten a subnetjeit. Azaz a telephelyi címzési terv elkészítése
feltehetőleg többé már nem az esetlegesen szűkös címtartomány mégis
megfelelő feldarabolásáról szól, hanem általában meglesz a tervező
mérnöknek a lehetősége egy kényelmesebb, tágasabb címtérben a belső
aggregációra (pl. OSPF vagy I/IS-IS használatakor) is alkalmas címzési terv kialakítására.
Egyelőre az
első 48 bit lehetséges struktúrájáról, határairól nem lehet sokat tudni.
Jelenleg az IANA global unicast címtartományt a 2000::/3 prefixből
oszthat. A RIR-ek /32-es prefixeket osztanak ki az erre jogosultak (pl. ISP-k)
számára a 2001::/16 prefixből. Arról, hogy milyen írott vagy íratlan
szabályok lesznek az IPv6 prefixek DFZ-be való hirdetéséről, szintén nem
sokat tudni, kivéve talán azt, hogy a 48 bitnél hosszabb prefixek hirdetése
valószínűleg tilos lesz. Ezeket a szabályokat természetesen döntően
befolyásolhatják az inter-domain routing mechanizmusai, de azt ma még igen
nehéz lenne megmondani, hogy ezek a mechanizmusok mennyiben fognak hasonlítani
a jelenleg használatos IPv4 inter-domain routingra.
Az IPv6 terminológiában
a link olyan médiumot jelent, amelyen a hozzá kapcsolódó állomások az
adatkapcsolati (data link) réteg felett kommunikálhatnak egymással. Egy fontos
újdonság az IPv6-ben a link-local címek bevezetése. IPv4 esetén két szomszédos
(azonos linkhez kapcsolódó) állomás akkor tudott közvetlenül kommunikálni
egymással az adatkapcsolati réteg szolgáltatásait igénybe véve, ha azonos IP
subnetbe tartozó címük is volt. IPv6 használatakor két szomszédos állomás
mindig tud egymással ilyen módon kommunikálni, ha máshogy nem, akkor a
link-local unicast címeik segítségével.
Minden IPv6
interface-nek rendelkeznie kell link-local unicast címmel, és ez a cím az adott
linken egyedi kell, hogy legyen. A link-local cím tehát egyértelműen
azonosítja az interface-t az adott linken, viszont két különböző linken
már előfordulhat azonos link-local unicast cím. A link-local unicast címek
prefixe FE80::/10.
A link-local
unicast címeknek ezt a tulajdonságát, hogy egy adott linken egyértelműen
azonosítják az interface-eket, az IPv6 számos területen, így a routingban is
kihasználja. Pl. az ICMPv6 Router Advertisement és Redirect üzenetek forrás
címe a router link-local címe kell, hogy legyen. A specifikáció szerint az
ICMPv6 Redirect üzenetekben a cél címnek (ahova átirányítja a forgalmat a
Redirect üzenet küldője) szintén link-local címnek kell lennie. Szükséges
tehát, hogy az azonos linkhez kapcsolódó routerek ismerjék egymás link-local
unicast címét.
A statikus
routing nem routing protokoll, a routerek közt nincs üzenetváltás ezzel
kapcsolatban. (Természetesen a statikus route-okból származó információt is
megoszthatja egymással több router, redisztribúció és egy dinamikus routing
protokoll segítségével. De ez egy egészen más történet.) A statikus route-ok
egyszerűen ugyanolyan, lokális információforrást jelentenek a routing
table kialakításához és a csomagok továbbításához, mint bármelyik dinamikus
routing protokoll.
Egy kis különbség
lehet az IPv4 és az IPv6 statikus route-ok között. Ha multi-access linken a
next hop router is az adott linkhez csatlakozik, akkor praktikus annak a
link-local címét adni meg a statikus route-hoz. Ez nem kötelező, de egy
picit megkönnyíti a router dolgát az ICMP Redirect üzenetekkel.
A Routing
Information Protocol (RIP) egy a Bellman-Ford (vagy más néven Ford-Fulkerson)
algoritmuson alapuló distance vector IGP. A RIP igen egyszerű, és
meglehetősen régi, az őseit már több mint 30 éve is használták. A RIP
csak nagyon kicsi hálózatokon használható. Annak ellenére, hogy sok korlátja van,
az egyszerűsége miatt könnyen implementálható, és bizonyos szituációkban
jó szolgálatot tehet.
A Routing
Information Protocol IPv6 verzióját RIPng-nek („next generation”) hívják, csak
úgy, mint ahogy az IPv6-et is IPng-nek hívták azelőtt. A RIP korábbi
verziói a RIPv1 és a RIPv2. Mindkettő IPv4-hoz használható, és
IPv4/UDP/520 felett működik. A RIPv1 és RIPv2 PDU-k a fejléc (rendre 1 és
2 értékű) protokoll verzió mezője alapján különböztethetők meg
egymástól.
A RIPng még
mindig ugyanúgy RIP, drámai újdonságai nincsenek, inkább a RIPv2 természetes
továbbfejlesztése. A RIPng IPv6 felett működik, és új UDP portot is
kapott, az 521-est. A RIPng PDU fejléc verzió mezőjének tartalma 1, ami
persze nem okoz konfliktust az új transzport (IPv6/UDP/521) miatt.
A RIP update
üzenet egy fejlécből és egy vagy több RTE-ből (route table entry)
áll. A RIPng és a korábbi RIPv1 ill. RIPv2 másképp kezeli a next hop címeket. A
RIPv1 nem ad meg explicit next hop információt, ehelyett az update üzenet
forráscímét használja next hop címnek. A RIPv2 üzenetben ezzel szemben minden
RTE tartalmaz next hop címet is. A RIPng-ben opcionálisan speciális RTE adja
meg a next hop címet a soron következő RTE prefixekhez egészen a
következő next hop RTE-ig vagy az update üzenet végéig. Next hop RTE
hiányában az egyes verzióhoz hasonlóan az IP forráscím tekintendő next
hopnak. Ilyen módon csak egy IPv6 cím kerül minden RTE-be (néhány rövid
mezővel kiegészítve). Ez a cím általában cím prefix, néha next hop cím.
Ezzel a megoldással megmarad a RIPv2 flexibilitása, és általában sok helyet meg
is lehet takarítani az update üzenetben, hiszen gyakran akár az összes
prefixhez tartozó next hop cím azonos.
Az ICMPv6
Redirect üzenetek miatt szükséges, hogy a RIPng által terjesztett next hop
címek mindig link-local IPv6 címek legyenek. Ezért a RIPng update üzeneteket
minden router a saját link-local címéről küldi, és a next hop RTE-ben is
csak link-local címet ad meg.
A RIPng update
üzenetek cél IP címe lehet az FF02::9 (minden RIP router) multicast cím, vagy
egy link-local IPv6 cím, a link képességeitől illetve az update üzenet
küldésének okától függően.
A RIPv1-hoz
képest fontos fejlesztés volt a RIPv2-ban az autentikáció lehetősége. Az
IPv6 viszont már „beépített” biztonsági megoldásokkal (AH, ESP) rendelkezik,
ezért a RIPng ezeket használja a saját autentikáció helyett, ha szükséges.
Az Open Shortest
Path First (OSPF) egy link-state routing protokoll, mely a közelmúltban elhunyt
holland tudós, Edsger Wybe Dijkstra algoritmusán alapul. Az OSPF protokollt
futtató routerek tájékoztatják egymást a hálózati összeköttetések állapotáról
(erre utal a link-state elnevezés). Az így összegyűjtött információból
minden router összeállítja a memóriájában a hálózat pillanatnyi állapotát reprezentáló
súlyozott élű gráfot, majd lefuttatja ezen a gráfon a Dijkstra
algoritmust. Az algoritmus eredménye a legrövidebb utakból álló fa gráf,
melynek gyökere a router önmaga. Ez alapján kerülhetnek bejegyzések a routing
table-be.
Az OSPF harmadik
verzióját leíró RFC címe „OSPF for IPv6”. Ez a cím bizonyos tekintetben jobb,
mint az OSPFv3 elnevezés, hiszen az OSPFv3 kizárólag IPv6-hez használható, míg
az OSPFv2 csak IPv4-hoz. Ezért könnyen előfordulhat, hogy egy hálózaton
egyszerre használunk OSPFv2-t és OSPFv3-t, az előbbit IPv4, az utóbbit
pedig IPv6 IGP-ként. Természetesen az OSPF protokoll verziók szerinti
megkülönböztetése is megállja a helyét, nem csak azért, mert az OSPF csomagok
fejlécének verzió mezőjében 2 illetve 3 szerepel, hanem azért is, mert az
OSPFv3 sok nagyon fontos javítást, továbbfejlesztést tartalmaz a második
verzióhoz képest.
Az OSPF a
protokoll üzeneteket közvetlenül IP csomagokba ágyazva továbbítja: a 89-es IP
protokoll az OSPF. Természetesen az OSPFv2 IPv4 felett, az OSPFv3 pedig IPv6
felett küldi a protokoll üzeneteket.
Az OSPFv3 az
előző protokoll verzióhoz hasonlóan használ multicast kommunikációt
is szomszédos routerek között. Az összes OSPF routert (AllSPFRouters) azonosító
multicast cím IPv4 esetén 224.0.0.5, míg IPv6-nál FF02::5.
A designated és backup
designated routert (AllDRouters) azonosító cím pedig 224.0.0.6 illetve FF02::6.
A link-local
címek koncepciójának megfelelően az OSPFv3 linkeken működik IP
subnetek helyett. Egy adott linkhez kapcsolódó két router tehát ki tudja
alakítani az OSPF szomszédsági viszonyt egymással akkor is, ha nincs azonos
subnet prefixbe tartozó globális unicast címük. Egymás közti unicast
jellegű kommunikációhoz az OSPFv3 routerek a link-local unicast címeket
használják. (Kivételt képeznek ez alól a virtuális összeköttetések, ahol ez az
út természetesen nem járható, hiszen a két egymással kommunikáló OSPF routert
ilyenkor nem köti össze közvetlen IPv6 link.) A routing table-ben az
OSPF-től származó bejegyzések next hop címe szintén a szomszédos router
link-local unicast címe lesz.
Az OSPFv3 bevezet
egy új LSA típust is, ez a Link-LSA. A Link-LSA csak az adott linkhez
kapcsolódó routerekhez jut el, azaz az elárasztási területe kisebb, mint az
OSPFv2 LSA-k esetén használt legkisebb elárasztási terület, az area. A Link-LSA
célja, hogy az adott link routerei megtanulják egymás IPv6 link-local címét, a
linken használt IPv6 subnet prefixeket, valamint néhány egyéb paramétert.
Az OSPFv3 LSA
adatszerkezetekben az IPv6 prefixek ábrázolása a prefix hosszának és a cím
első (32-vel osztható számú) bitjeinek megadásával történik. Ez a megoldás
segít az OSPFv3 protokoll üzenetek méretét és mennyiségét csökkenteni. Ahol nem
prefixek, hanem IPv6 címek szerepelnek (pl. a Link-LSA link-local címet leíró
mezőjében), ott természetesen a mező mérete fixen 128 bit.
A router ID és az
area ID nem változott az OSPF harmadik verziójában, mégis érdemes említést
tenni róluk. Mindkét azonosító 32 bites, és gyakran ábrázolják őket az
IPv4 címeknél szokásos pontozott decimális formában. Az ilyen ábrázolásnak
rendszerint praktikus oka van, hiszen az OSPFv2 router ID legtöbbször a router
valamelyik loopback interface-ének IPv4 címe. Ez azonban csak az operátorok
munkáját hivatott egyszerűsíteni, az OSPF számára mindkét azonosító egy egyszerű
32 bites érték, tehát a protokoll változtatására e téren nincs szükség az IPv6
miatt.
A RIPng-hez
hasonlóan az OPSFv3 sem tartalmaz már autentikációt, hanem az IPv6-ra bízza ezt
a feladatot.
Ugyan nem
kötődik szorosan az IPv6-hez, mégis érdemes megemlíteni néhány egyéb
változást az OSPF protokollban. A Link-LSA mellett szintén új LSA típus az
Intra-Area-Prefix-LSA. Ez az LSA tartalmazza azokat a prefixeket, amelyek az
OSPF második verziójában a Network-LSA-ben és a Router-LSA-ben szerepeltek. Az
OSPFv2 type 3 és type 4 summary-LSA új, kifejezőbb nevet kapott:
Inter-Area-Prefix-LSA és Inter-Area-Router-LSA. Újdonság még az Instance ID
bevezetése is, mely lehetővé teszi, hogy egy linken egyszerre több OSPFv3
processz is működjön (erre korábban csak autentikáció és eltérő
jelszavak használatával volt lehetőség).
Az Intermediate
System to Intermediate System (IS-IS) eredetileg egy ISO szabvány IGP, az Open
Systems Interconnection (OSI) protokollcsalád tagja. Azért készült, hogy a
routerek (intemediate system az OSI terminológia szerint) CLNP
(Connectionless-mode Network Protocol) csomagokat tudjanak továbbítani,
illetve, hogy az ehhez szükséges topológia információt kicserélhessék
egymással. Az IETF kiegészítette az IS-IS-t, hogy az átvihessen IP topológia
információt is. A kiegészített protokoll az Integrated IS-IS (vagy Dual IS-IS)
nevet kapta, hiszen egy közös OSI és TCP/IP környezetben használható egyszerre
mind CLNP-hez mind IP-hez routing protokollként.
Az IS-IS
link-state protokoll, Dijkstra algoritmusát használja, akárcsak az OSPF.
Az IS-IS PDU-k
továbbítása közvetlenül az adatkapcsolati réteg felett történik, függetlenül
attól, hogy CLNP, IPv4 vagy IPv6 csomagok route-olásához használjuk.
A hálózat
topológiájáról és egyéb jellemzőiről szóló információk nagy része ún.
TLV-k (type-length-value) formájában szerepel az IS-IS PDU-kban. A 236-os
típusszámú „IPv6 Reachability” TLV felel meg az IPv4 „IP Internal Reachability
Information” (128) és az „IP External Reachability Information” (130) TLV-knek.
Ezek a TLV típusok szolgálnak a hálózaton elérhető IP prefixek
hirdetésére. Az „IPv6 Reachability” TLV-ben az IPv6 prefixek megadása a prefix
hosszával és első (8-cal osztható számú) bitjeivel történik, a prefix
eredetét (internal/external) pedig egy jelzőbit adja meg. A másik új TLV
típus a 232-es „IPv6 Interface Address” TLV, mely az IPv4 „IP Interface
Address” TLV-hez hasonlóan egy router interface-einek címeit adja meg. Amikor
az „IPv6 Interface Address” TLV a szomszédos routereknek küldött IS-IS Hello
csomagokban szerepel, akkor az adó router interface link-local címét
tartalmazza. Ha viszont LSP-ben szerepel ez a TLV, akkor a router összes nem
link-local címét kell tartalmaznia.
Az itt leírtakból
jól látszik, hogy csak egyszerű kiegészítésekre (lényegében mindössze két
új TLV bevezetésére) volt szükség ahhoz, hogy az I/IS-IS IPv6-hez is
használható legyen.
A Border Gateway Protocol (BGP) egy path vector EGP. Az Interneten az unicast routinghoz ma használatos egyetlen EGP a BGP 4-es verziója. Pontosabban használatban van a BGP4 és annak egy kiegészített változata is, az MBGP (Multiprotocol BGP) vagy más néven BGP4+. Az MBGP felülről kompatibilis a BGP4-ral, így a két változat együttélése valamint az átállás MBGP-re egyszerű.
A BGP4 csak
unicast IPv4-hoz használható, bár maga a protokoll viszonylag független az
IPv4-tól. A kiegészített MBGP alkalmas többek között IPv6 unicast routingra is.
A BGP protokoll
üzenetek közül esetünkben az UPDATE a legfontosabb, hiszen ez az üzenet
tartalmazza a routing információ döntő részét. Az UPDATE üzenet két
fő részre bontható: 1) a visszavont és 2) a bejelentett vagy módosított
routing információra. Az első rész BGP4 esetén egyszerűen csak a
visszavont IPv4 prefixek listája. A második rész tartalmazhat IPv4 prefixeket
(Network Layer Reachability Information, NLRI), valamint az ezekre vonatkozó
attribútumokat (pl. AS_PATH, NEXT_HOP). Az MBGP két új attribútumot vezet be:
MP_REACH_NLRI (Multiprotocol Reachable NLRI) és MP_UNREACH_NLRI (Multiprotocol
Unreachable NLRI). Az MP_UNREACH_NLRI szemantikailag az UPDATE üzenet első
részéhez tartozik, hiszen nem áll másból, mint egy protokollcsalád
megnevezéséből (pl. IPv6 unicast), és az ebbe a családba tartozó
visszavont prefixekből. Az MP_REACH_NLRI a második, újonnan bejelentett és
módosított információkat leíró részbe tartozik. Ez az attribútum is tartalmaz
protokollcsalád azonosítót és prefix listát. Mivel a NEXT_HOP attribútum
praktikusan a prefixszel azonos családba tartozó címet ad meg, ez az információ
is belekerült az MP_REACH_NLRI-ba.
Már a BGP4 NLRI
prefixek is hossz és 8 bitre kiegészített cím formájában voltak megadva az
UPDATE üzenetekben, így ezen az MBGP esetén sem volt szükséges módosítani. Az
új MP_REACH_NLRI belsejében megadott next hop tartalmaz egy byte-ban kifejezett
„hossz” mezőt is, ami IPv6 esetén 16 vagy 32 lehet. 16 byte egy IPv6 cím
hossza, ezen nincs mit taglalni. A next hop mező hossza akkor lehet 32
byte, ha két IPv6 címet tartalmaz. Ilyenkor az egyik cím a szokásos global
(vagy esetleg site-local) cím, a másik pedig a hozzá tartozó link-local cím. Az
ICMPv6 specifikációval összhangban a link-local BGP next hop címre kizárólag
akkor van szükség, ha a next hop címhez tartozó router valamint a két BGP peer
egy közös linkhez kapcsolódik.
Az OSPF-hez hasonló
helyzet állhat elő a BGP router ID-vel is. A router ID egy 32 bites
azonosító, BGP4 esetén a router egyik IPv4 címe kell, hogy legyen. MBGP esetén
viszont lehetséges, hogy a routernek egyáltalán nincs IPv4 címe. Ilyenkor egy
egyedi 32 bites azonosítót kell választani. Ennek az azonosítónak praktikusan
az egész Interneten egyedinek kell lennie, hiszen szerepel pl. az AGGREGATOR
attribútumban is, amely az Internet bármely pontjára eljuthat. A javasolt
megoldás egy a 240.0.0.0/4 prefixbe tartozó (korábbi „E” címosztály, jelenleg
is fenntartott státuszú), az AS azonosítóból és 12 bitnyi, az autonóm
rendszeren belül egyedi értékből álló cím használata.
Az MBGP csak úgy,
mint a BGP4 TCP felett működik, a 179-es porton. Emiatt érdektelen lenne,
hogy a TCP kapcsolat IPv4 vagy IPv6 felett épül ki a BGP peerek között.
Előfordulhat viszont olyan eset (pl. a hirdetendő NEXT_HOP
meghatározásakor), amikor a routernek szüksége van a BGP szomszédja IPv4 vagy
IPv6 címére, így ez problémát jelenthet, ha éppen a másik IP verzió felett
működik az MBGP TCP kapcsolata. Ilyenkor a router konfigurációját a BGP
peer másik (IPv4 vagy IPv6) címével is ki kell egészíteni.
Az IPv6 unicast
routing talán legfontosabb, egyelőre megoldatlan problémája a multihoming
kérdése. Ahogy arra tanulmányok is rámutattak már, az IPv4 jelenlegi gyakorlata
ezen a téren nem skálázható megfelelően. Igaz, hogy a nagy IPv6 címtér
kitűnő lehetőséget nyújt az aggregációra, de sajnos jelenleg
egyetlen olyan széles körben elfogadott javaslat sincs a multihoming kérdésére,
amely ne törné meg az aggregációt. Pozitívum, hogy az elmúlt hónapokban az IETF
multi6 munkacsoportjának aktivitása folyamatosan nagy volt, szemben az azt
megelőző időszakkal, amikor gyakorlatilag csak az IETF keretein
kívül folyt munka ezen a területen, hosszú hónapokon át. Ezzel együtt a széles
körben elfogadott megoldás még nem igazán látszik körvonalazódni sajnos.
Évekkel
ezelőtt volt néhány ígéret és cél, melyek meg nem valósulása szintén
kellemetlen volt a multihoming kérdés szempontjából. Ilyen például a
renumbering, vagyis az az elképzelés, hogy IPv6 esetén viszonylag nagy
hálózatok teljes átcímzése is egyszerűen megoldható lesz. Az persze, hogy
ez ma nem lehetséges, nem az IPv6 hibája. Egyszerűen túl sok helyen szerepelnek
egy tipikus hálózatban IP címek ahhoz, hogy az átcímzés triviális legyen.
Az IPv6 unicast
routinghoz használható, itt tárgyalt protokollok mindegyike több
különböző, többé-kevésbé helyesen működő implementációval
rendelkezik. Az implementációk jelentős része dedikált router platformokon
fut.
A kísérleti IPv6
hálózatok, amelyekben ezeket a protokollokat alkalmazzák, gomba módjára
szaporodnak és növekednek. Néhány produkciós IPv6 hálózat is létezik már,
főleg az APNIC régióban.
Mindezek ellenére
az IPv6 széleskörű elterjedése produkciós hálózatokban még várat magára,
többek között a multihoming kérdés megoldatlansága miatt. Sajnos ebben a
pillanatban még az sem látszik teljesen tisztán, hogy el fog-e terjedni az IPv6
használata valamikor, vagy sem.