Požadavky na IPv6 uzel

Jedná se o dokument jdoucí napříč existujícími specifikacemi. Jeho cílem je na jednom místě přehledně shrnout nároky stanovené různými RFC, a usnadnit tak život implementátorům protokolu a zároveň uživatelům, kteří by si chtěli ověřit, zda jejich systém má veškeré požadované vlastnosti. Vzhledem ke svému charakteru se RFC 4294 doslova hemží odkazy na další specifikace. V některých případech (konkrétně v oblasti bezpečnosti) jde i za jejich rámec a odráží dokumenty, jejichž přijetí se očekává v brzké budoucnosti.

Podřízené vrstvy se zde příliš neřeší. Pouze se celkem logicky konstatuje, že IPv6 musí být podporováno alespoň na jednom rozhraní a že nemusí nutně být na všech. Najdete tu také odkazy na definici přepravy IPv6 po některých linkových technologiích (konkrétně RFC 2464 pro Ethernet, RFC 2472 pro PPP a RFC 2492 pro ATM).

Zajímavé to začíná být v síťové čili IP vrstvě. Podporu jednotlivých prvků a mechanismů lze rozdělit na:

povinné (must)

• základ IPv6 (RFC 2460)
• ICMP (RFC 4443)
• adresní architektura (RFC 3513)
• většina z objevování sousedů (RFC 2461) – objevování směrovačů a prefixu, detekce nedosažitelnosti souseda (nepovinná je pouze na lince propojující dva směrovače), odpověď na výzvu sousedovi, detekce duplicity adres na všech linkách podporujících multicast na linkové vrstvě (např. Ethernet), zasílání výzvy směrovači a zpracování ohlášení směrovače, zasílání a odpovídání na výzvy sousedovi, přesměrování u směrovačů
• bezstavová konfigurace (RFC 2462) u koncových strojů
• výběr implicitní adresy (RFC 3484)

požadované (should)

• přesměrování při objevování sousedů u koncových strojů (nikoli směrovačů, tam je povinné)
• rozšíření konfigurace adresy chránící soukromí (RFC 3041)
• objevování MTU cesty (RFC 1981)

volitelné (may)

• stavová konfigurace čili DHCPv6 (RFC 3315)
• jumbogramy (RFC 2675)

Poněkud složitější je situace s požadavkem na podporu mechanismu Multicast Listener Discovery (MLD) pro skupinově adresované datagramy. Obecně je požadována podpora MLDv2. Nicméně záleží na požadavcích zdejších aplikací. Pokud si vystačí s any-source multicastem (RFC 3569), může uzel podporovat pouze MLDv1. Naopak jestliže má podporovat source-specific multicast, je rázem podpora MLDv2 povinná.

Požadavek na DNS je řešen šalamounsky. Nejprve se říká, že pokud aplikace nebudou požadovat konverzi mezi jmény a adresami, nemusí být DNS implementováno. Zároveň ale dokument konstatuje, že aplikace všeobecně tuto službu očekávají a obecně je třeba ji podporovat. Upřímně řečeno bych skoro považoval za rozumnější prohlásit rovnou DNS za povinné či požadované (případně s definovanými výjimkami).

Uzly, které potřebují řešit DNS dotazy, by měly obsahovat klienta (resolver) podporujícího AAAA záznamy, reverzní PTR záznamy v doméně ip6.arpa a EDNS0 podle RFC 2671 pro dlouhé DNS pakety. Doporučuje se, aby podporovaly DNSSEC (RFC 4033, 4034 a 4035). Naopak není doporučena podpora záznamů A6 a DNAME, jak požaduje RFC 3363.

IPv6 uzel může pochopitelně podporovat i IPv4. V takovém případě pak musí podporovat mechanismy dual stack a tunelování podle RFC 4213.

Mobilní IPv6 je rozděleno na několik funkčních částí s různou mírou naléhavosti. Ode všech uzlů je požadováno, aby podporovaly optimalizaci cesty při komunikaci s mobilním uzlem. Pouze volitelná je podpora těch prvků mobility, jež uzlu umožňují vydat se na cesty a stát se mobilním. Naopak povinná je pro směrovače podpora veškerých schopností, jež od nich požaduje mobilní IPv6. A konečně dobrovolná je schopnost směrovače stát se domácím agentem pro mobilní uzly.

V oblasti zabezpečení je pro všechny uzly povinná podpora základní bezpečnostní architektury (RFC 4301), hlaviček AH (RFC 4302) a ESP (RFC 4303) a manuální správy klíčů. Měly by navíc podporovat některý ze systémů pro správu klíčů, jako je například IKEv2 (RFC 4306) či Kerberos. Pokud se šifrovacích algoritmů týče, měla by implementace vyhovovat požadavkům RFC 4305. Máme tu opět tři skupiny algoritmů:

povinné

• HMAC-SHA-1–96
• 3DES-CBC
• AES-128-CBC

volitelné

• HMAC-MD5–96

nežádoucí

• DES-CBC je příliš slabý, proto je požadováno se mu vyhýbat

Podpora SNMP pro správu sítě je volitelná. Pokud je prvek podporuje, měl by implementovat MIB pro předávání IP (RFC 4292) a IP MIB (RFC 4293).

Speciálně na směrovače jsou pak kromě výše zmíněných kladeny dva požadavky navíc. Při objevování sousedů musí posílat ohlášení směrovače a zpracovávat výzvy směrovači. Druhý požadavek se týká volby router alert (RFC 2711) v rozšiřujících hlavičkách datagramu. Šíří se protokoly, které ji využívají, proto bude třeba ji podporovat.

Jak bylo řečeno výše, RFC 4294 neklade samo o sobě žádné nové požadavky, jen shrnuje nároky jiných specifikací. S jeho splněním by proto implementace neměly mít zásadnější problémy. Ty budou aktuálně plynout spíše z toho, že některé mechanismy se nedávno dočkaly nových definic (namátkou RFC 4443 s aktualizací ICMPv6 či veškeré bezpečnostní prvky) a může chvíli trvat, než se dostanou do reálného života. Ovšem změny v těchto RFC zpravidla jsou spíše kosmetické, takže ani tato překážka by neměla být nijak vysoká.