Routing update: IPv6 unicast
Jákó András
BME EISzK
Networkshop 2003., Pécs
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.
10.0.0.0/18 prefix a
10.0.0.0-10.0.63.255 IPv4 címtartományt
fedi le, azaz az összes olyan IPv4 címet, amely a bináris
00001010.00000000.00 mintával kezdődik, és tetszőleges 14 bittel
folytatódik. Hasonlóan vannak leírva az IPv6 cím prefixek is, pl.
3FFE:FF00::/24.
3FFE:FF00::/24 és a
3FFE:FF0A::/32 prefixeket is, akkor 3FFE:FF0A:B400::1 címre történő
csomagtovábbításhoz az utóbbi bejegyzést kell használni.
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 "F" 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.