IPv6.. We moeten er toch aan

Iemand moet de spits afbijten, dus laat ik dat maar zijn. Ik heb deze blogpost al maanden op de plank liggen, maar nooit afgemaakt. Ik dacht: dat is een mooie voor de PFE blog:

Sinds het millennium zingt het al rond. IPv6 komt eraan! We raken zonder IPv4 adressen! Nu 8 jaar later willen we er eigenlijk toch nog niet aan. De enige regio waar IPv6 een grote vlucht neemt is Azië, en met name China die de doelstelling heeft de leidende natie te zijn in het 'Next Generation Internet' waar IPv6 een belangrijke rol speelt.

Bedrijven willen echter nog niets weten van IPv6, waarbij het belangrijkste struikelblok uiteraard de kosten is. Wij hebben door de jaren heen allerlei technieken gebruikt om het tekort aan IPv4 adressen te omzeilen, denk maar aan Network Address Translation (NAT) en Dynamische IP addressen via DHCP. Bedrijven zien daardoor nog niet de noodzaak om intern de hele netwerkinfrastructuur om te gooien om IPv6 te gaan ondersteunen, daar binnen de firewalls het probleem zich niet voordoet.

Het probleem doet zich voor buiten de firewalls. Met IPv4 hebben we de beschikking over 4.294.967.296 addressen. De verwachting is dat ergens in 2010 alle IP ranges door IANA en de RIRs (Regional Internet Registers) zijn toegekend aan Internet Service Providers en –bedrijven, en we dus voor het eerst echt iets gaan merken van het nijpende tekort. Ondertussen wordt er door partijen als het Internet Engineering Task Force hard gewerkt om het internet klaar te stomen voor IPv6. Zo is de backbone al klaar, en zijn de meeste Internet Exchanges ook al gereed. Het probleem ligt bij de duizenden, zo niet tienduizenden Internet bedrijven. Ook in Nederland is dat nog steeds een probleem.
Naast de kosten voor de implementatie van een IPv6 infrastructuur speelt kennis en onzekerheid volgens mij ook een grote rol. Ik merk het aan de mensen met wie ik spreek, en aan mezelf. IPv6 is een ander beestje dan IPv4 en in veel opzichten een stuk ingewikkelder. Echter is het in veel opzichten ook weer een stuk eenvoudiger. Ik moet echter de eerste klant nog tegenkomen, waar ze al grootschalig bezig zijn met IPv6. Het overgrote gedeelte heeft zich er nog helemaal niet in verdiept.
Windows Server 2008 en Windows Vista hadden moeten zorgen voor een impuls, maar helaas zie ik er nog weinig van terug. Dit zal vermoedelijk veranderen met Windows Server 2008 R2 en Windows 7, waar functionaliteiten als Direct Access en sommige geavanceerde features op het gebied van Network Access Protection IPv6 vereisen. Ik verwacht een grote groei in het gebruik van IPv6, zeker door het gebruik van Direct Access, wat een geweldige oplossing is voor mobiele werkers.

Met deze post wil ik de basisprincipes van IPv6 uit de doeken doen, met de hoop dat meer mensen deze techniek gaan gebruiken. Let wel: Dit gaat over de Microsoft implementatie. Op sommige punten kan het iets verschillen met andere systemen. Niet dat het een eigen custom implementatie is, maar sommige punten in de RFCs zijn minder strikt en laat de mogelijkheid vrij deze op verschillende manieren toe te passen.

Adressering

De adressering is al het eerste waar we aan moeten gaan wennen. Waar IPv4 nog een 32 bits adres was, met de mogelijkheid dit weer te geven in 4 door punten gescheiden decimale getallen tussen de 0 en 255, is IPv6 een 128 bits adres met 8 door dubbele punten gescheiden hexidecimale getallen tussen de 0000 en FFFF (groepen van 16 bits dus). Een geldig IPv6 adres ziet er bijvoorbeeld zo uit:

2001:0:836b:b7:415:b86:ad33:e20a

In dit adres zien we een enkele 0. In IPv6 adressen, mag je voorloopnullen in een groep weglaten en mag je hele groepen nullen vervangen door dubbele 'dubbele punten' ( :: ). Dit kan echter maar een enkele keer in een adres. Nullen aan het eind van een groep mogen niet weggelaten worden. Een adres als hierboven kan dus ook geschreven worden als:

2001::836b:b7:415:b86:ad33:e20a

Een ander voorbeeld zou zijn:

2001:0:836b:b7:415:0:0:e20a

Wat geschreven kan geschreven worden als:

2001:0:836b:b7:415::e20a of 2001::836b:b7:415:0:0:e20a

Maar niet als:

2001::836b:b7:415::e20a

Je kunt met deze notatie namelijk niet meer zien op welke plekken de 'lege' groepen stonden.

Een IPv6 adres bestaat globaal gezien uit twee delen, namelijk een 64 bits Network ID en een 64 bits Interface ID. Het Network ID geeft aan op welk netwerk de interface zich bevindt, en het Interface ID identificeert de interface. Ik gebruik nu al meerdere malen het woord Interface in plaats van machine, node of computer. Dit omdat IPv6 er vanuit gaat dat een computer of node eigenlijk altijd Multi-Homed is (meerdere network interfaces of adressen bevat):

Het Interface ID is niet heel spannend. Het meest lastig is het Network ID. Om dit te doorgronden is een stukje theorie nodig (eigenlijk net als met IPv4 subnetting J ). Zoals gezegd geeft het Network ID aan op welk netwerk de interface actief is. Om dit te bepalen bestaat het Network ID ook weer uit een aantal delen. Voor het gemak zijn dat de Format Prefix (FP) en een Subnet ID. Het Format Prefix geeft het adrestype aan, en het Subnet ID geeft het subnet aan.

Nu is deze verdeling niet helemaal correct voor alle adressen. Het verschilt namelijk lichtelijk per adrestype, maar onthoud voor het gemak deze verdeling. Zoals gezegd bepaald de Format Prefix het adrestype. Dit adrestype bepaald op wat voor manier het adres gebruikt kan worden en wat de scope is van het adres (vergelijkbaar met de 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 IPv4 ranges voor lokale addressen, die niet routeerbaar zijn op het internet

Om Prefixes te snappen moet je enigszins bekend zijn met het Hexadecimale en Binaire tallenstelsel.
Het hexadecimaal stelsel is een veelvoorkomend tallenstelsel in de IT, maar toch merk ik dat veel mensen er problemen mee hebben. Hexadecimaal is een 16tallig tallenstelsel en loopt van 0 tot 15 of in Hexadecimaal van 0 tot F, of in binair van 0000 tot 1111. Een hexadecimaal getal bestaat dus binair uit 4 bits.

Het omrekenen van binair naar hexadecimaal naar binair en andersom is met bovenstaande tabel redelijk simpel. Hexadecimaal naar Binair reken je om door het hexadecimale getal op te splitsen en te matchen naar groepen van 4 bits.
FE80 wordt zo dus:

    F à 1111, E à 1110 , 8 à 1000, 0 à 0000 = 1111 1110 1000 0000

Andersom is binair net zo makkelijk om te rekenen naar binair. Splits het binaire getal op in groepen van 4 bits en reken elke groep om naar hexadecimaal.
1101010001111010101 wordt zo dus

    1101 à D, 0100 à 4, 0111 à 7, 1010 à A = D47A

Om een tallenstelsel om te rekenen naar decimaal, maak je gebruik van de posities in het getal en de machten die daarbij horen. Voor een 16tallig stelsel ziet dat er als volgt uit:

Eerste positie     = n*16^0 (1)

        +

Tweede positie    = n*16^1 (16)

        +

Derde positie    = n*16^2 (256)

        +

Vierde positie    = n*16^3 (4096)

    ETC

(dit geldt voor elk tallenstelsel. Octaal (8tallig) zou zijn n*8^0, Binair (2tallig) zou zijn n*2^0 etc)

Voor FFFF zou dat dus zijn:

FFFF = 15*1 + 15*16 + 15*256 + 15*4096 = 15 + 240 + 3840 + 61440 = 65535

Het omrekenen van decimaal naar een ander tallenstelsel is iets ingewikkelder. Je probeert het getal te delen door de hoogste macht van n waardoor het getal nog deelbaar is, waarbij n staat voor het tallenstelsel. Vervolgens werk je daaruit terug door de restwaarde elke keer te berekenen en te delen op de volgende macht van n. Deze hoogste macht moet je dus eerst zoeken.
54234 wordt zo dus:

    54234 / 16^4     = 54234 / 65536     = 0
    16^4 past dus niet...

54234 / 16^3     = 54234 / 4096     = 13     = D
Restwaarde         = 54234 % 4096     = 986

986 / 16^2         = 986 / 256     = 3     = 3
Restwaarde         = 986 % 256     = 218

    218 / 16^1         = 218 / 16         = 13     = D
    Restwaarde         = 218 % 16         = 10

    10 / 16^0         = 10 / 1         = 10     = A
        

    54234 = D3DA

Nu je hopelijk begrijpt hoe het ongeveer werkt met tallenstelsen, kom ik terug op Prefixes. IANA heeft een aantal Prefixes vrijgegeven en gereserveerd, welke zijn weergegeven in de volgende tabel:

Het Prefix wordt weergegeven door /n, waarbij n staat voor het aantal bits van het IPv6 adres dat gebruikt wordt voor het prefix. /3 staat dus voor de eerste 3 bits. Als je dan kijkt naar het Global Unicast prefix wat 2000::/3 is, zijn de eerste 3 bits van het adres dus gereserveerd met de waarde 001, wat in de eerste groep van een IPv6 dus vertaald naar:

    0010 0000 0000 0000:: = 2000

Maar… Waar gebruiken we die adrestypes nu voor?

Global Unicast

Global Unicast adressen zijn adressen die routeerbaar zijn op het internet. Elk adres dat je over het internet direct wilt benaderen moet dus beginnen met een 2. Als een router op het internet dit ziet, weet hij dat hij het kan en mag routeren. Aan de rest van het netwerkgedeelte kan de router vervolgens bepalen voor welk netwerk het bestemd is. Het adres is als volgt opgebouwd:

Het Global Routing Prefix is een Prefix die aangeeft bij welke organisatie het adres hoort. Deze worden uitgegeven aan bedrijven, om zo een uniek Network ID te verkrijgen. De 16 bits van het Subnet ID kan een bedrijf weer gebruiken om zo verschillende sites (In totaal 65535 locaties) aan te geven. Microsoft heeft bijvoorbeeld als Global Routing Prefix 2001:4898::/32:

Link-Local adressen

Link local adressen zijn adressen die alleen gebruikt worden binnen het subnet, of eigenlijk beter gezegd op dezelfde link. Deze adressen worden niet gerouteerd en zijn te vergelijken met de APIPA IPv4 adressen (169.254.0.1 - 169.254.255.254).
De opmaak van het adres is:

De prefix FE80::/10 wordt tot 64 bits aangevuld met nullen om het Network ID te vormen. Samen met het Interface ID maakt dat een adres als fe80::608d:e636:f0d7:280f
Een link-local adres wordt altijd automatisch geconfigureerd, en is vereist voor Neighbor Discovery, waar ik later nog op terug zal komen. Een interface heeft dus vaak zowel een Local Unicast adres alsmede een link-local adres.

Unique Local Unicast

Local Unicast adressen zijn adressen die 'lokaal', of beter gezegd in intranetomgevingen gebruikt worden en zouden dus niet globaal te routeren zijn. Het adres is als volgt opgebouwd:

De eerste 7 bits zijn de Prefix (FC00::/7), vervolgens is er een L ocal bit. Deze staat standaard op 1, wat dus aangeeft dat het een lokaal adres is. In de toekomst kan het zijn dat er de mogelijkheid komt dat deze Local Unicast adressen ook globaal te routeren zijn. Dan zal dit bit op 0 gezet worden. Op dit moment moet deze te allen tijden op 1 staan. Echter, doordat de mogelijkheid bestaat dat dit in de toekomst gewijzigd gaat worden, moet het Global ID eigenlijk ook uniek gemaakt worden, om globaal routeerbaar te zijn. Er is echter in deze versie van de IPv6 rfcs niet voor gekozen om dit centraal te regelen. Daartegenover adviseert IETF een randomizer te gebruiken om dit ID te genereren. De kans dat er twee dezelfde Global ID gegenereerd worden is daarmee zeer klein is.
Het Global ID kan dus door de organisatie zelf bepaald worden, en is bedoeld om een site te identificeren (denk hierbij aan een gebouw, campus, stad, desnoods regio). Na deze 40 bits zijn er nog 16 bits over voor subnetting, en uiteraard nog 64 bits voor de Interface ID.

De overtuiging bestaat dat Local Unicast adressen voor een groot deel overbodig zijn, daar er zo verschrikkelijk veel Global Unicast adressen zijn, dat een bedrijf gemakkelijk elk interface van tig verschillende globale adressen kan voorzien. Edge devices kunnen er voor zorgen dat lokaal verkeer binnen de bedrijfsgrenzen blijft. Ik persoonlijk denk daar anders over, daar het feit dat Local Unicast adressen niet routeerbaar zijn op het internet (en dus ook niet direct benaderbaar), al een stuk beveiliging op zich is. Proxies en gateways zullen we ook in het IPv6 tijdperk nog steeds zien (misschien zelfs NAT nog wel).

MultiCast

Multicast addressen hebben prefix FF00::/8 en zijn bedoeld om een enkel packet naar meerdere interfaces te sturen. Elk adres dat dus begint met FF is een multicast adres. Het adres is verder als volgt opgebouwd:

De Flags kunnen gebruikt worden voor uitbreidingen van multicast. Op dit moment is er slechts 1 flag gedefinieerd, namelijk 0001 – de Transient flag, wat aangeeft of het adres permanent is of niet. De scope bepaald op welke scope het multicast adres gebruikt kan worden, en uiteindelijk is er nog het Group ID wat de groep aangeeft.

Op dit moment zijn de volgende scopes gedefinieerd:

Bekende multicast adressen zijn:

Anycast

Een ander type adres is het Anycast adres. Er is echter geen verschil aan te geven tussen een Anycast adres of een Unicast Local of Unicast Global adres. Een Anycast adres is gewoon een Unicast adres, maar de routing topologie maakt het mogelijk om het adres op meerdere plaatsen te gebruiken. Anycast maakt het vervolgens mogelijk om een pakket te sturen naar 1 van meerdere hosts, waarbij de meeste implementaties zorgen voor routering naar de interface die het dichtst bij is.

Broadcast?

Een andere verandering met IPv6 is het ontbreken van het broadcast adressen. Multicast is de enige manier om meerdere interfaces tegelijk te benaderen.

Interfaces

In de vorige paragrafen heb ik voornamelijk stilgestaan bij het Network ID. Het Interface ID zit echter ook een verhaal achter. Het interface ID kan volgens de RFCs bepaald worden op de volgende manieren:

1. Alle unicast-adressen met de prefixen 001 tot en met 111 (Daar vallen dus de Global Unicast adressen onder) moeten een 64-bits interface-id gebruiken die is afgeleid van het EUI-64-adres (nieuwste standaard voor MAC Address).
2. Willekeurig gegenereerde Interface ID die regelmatig wordt gewijzigd ten behoeve van de anonimiteit. De Windows implementatie gebruikt willekeurige adressen voor Link-local adressen.
3. Toekennen van een adres door automatische adresconfiguratie (bijvoorbeeld via DHCPv6). De DHCPv6-standaarden worden momenteel gedefinieerd. Hier kom ik later op terug.
4. Handmatig configureren van het Interface ID.

Nu spreken de laatste 3 voor zich (op automatische adresconfiguratie kom ik nog terug) Wat nu even van belang is, is het Interface ID van een Global Unicast adres. Deze moet volgens de RFC gebaseerd zijn op het MAC Address. Nu is de huidige standaard de IEEE EUI-64 standaard, welke is opgebouwd uit een 24 bits Company ID, die de NIC fabrikant aangeeft en een 40 bits Extension ID die uniek is voor de netwerkkaart.

Een Interface ID voor een kaart met MAC adres 00-AA-00-3F-2A-1C-3C-FF ziet eruit als :AA:3F:2A1C:3CFF

Nu is de EUI-64 standaard redelijk nieuw en hebben de meeste kaarten een MAC adres in de IEEE 802 standaard die eruit ziet als 00-1E-37-E8-09-56, met als verdeling een 24 bits Company ID en een 24 bits Extension ID:

Om er toch voor te zorgen dat we een Interface ID kunnen maken, wordt er tussen de Company ID en de Extension ID een aantal extra bits geplakt:

Het MAC adres 00-1E-37-E8-09-56 wordt daardoor :1E:37FF:FEE8:956

Zone ID

Het laatste wat opvalt aan sommige IPv6 adressen is het percent teken aan het eind van een adres (bijvoorbeeld: fe80::608d:e636:f0d7:280f%12 ).
Dit is het Zone ID en geeft voor een link local adres aan welke interface het is, zodat je een node op een specifieke interface kan benaderen.

Prefix policies

Omdat een node meerdere interfaces en een interface meerdere adressen kan hebben, is er een algoritme nodig om te bepalen welk source en destination gebruikt moet worden in een connectie. Dit wordt in Windows bepaald door de Prefix policies. Een tabel kan er als volgt uitzien:

De laagste Precedence waarde geeft de hoogste prioriteit aan. In dit geval kijgt het Teredo (Kom ik later op terug) adres de hoogste prioriteit.

Automatisch Configureren van interfaces

Ook voor IPv6 zijn er mogelijkheden om interfaces automatisch te configureren. Hierbij speelt Neighbor Discovery een grote rol. Neighbor Discovery is een nieuwe functionaliteit die voor IPv6 ontwikkeld is. Het ondersteunt een aantal netwerkberichten om de topologie van het netwerk te 'discoveren', maar ook om bepaalde settings van het netwerk te verkrijgen, en dubbele adressen te voorkomen. Deze berichten zijn onder andere Router Sollicitation en Advertisement berichten, en Neigbor Sollicitation en Advertisment berichten.
Maar hoe helpen deze berichten om een interface te configureren?
Wanneer een interface geen statisch adres toegewezen heeft gekregen doorloopt deze het volgende proces om toch een adres te verkrijgen:

1. De interface krijgt een willekeurig gekozen link-local adres.
2. De interface stuurt vervolgens zowel een Router Sollicitation bericht alsmede een Neighbor Sollicitation bericht. Het RS bericht is bestemt om de routers te vinden op de link; Het NS bericht is om het link-local adres te verkondigen op de link.
3. Mocht een andere interface op de link dit adres al hebben, stuurt deze een Neighbor Advertisement, en zal een nieuw link-local adres gegenereerd worden.
4. De interface wacht op een Router Advertisement bericht. Mocht deze niet ontvangen worden, dan stop het Autoconfiguration proces en behoudt de node alleen de link-local adressen.
5. Als de interface een Router Advertisement bericht ontvangt kan het twee kanten op: Hij kan stateless of statefull een Global Unicast of Local Unicast adres krijgen.
   Statefull of Stateless wordt bepaald door de M en O flags in een router advertisement bericht. M staat voor Managed, O voor Other Managed.
   Als M = 1, dan zal de interface het IP adres bij een DHCP server vandaan halen. Als M = 0, dan zal de interface het adres bepalen op configuratie uit het Router Advertisement bericht.
   Als O = 1, dan zal de interface alternatieve IP configuratie zoals DNS servers en domain suffixes.

Wat je uit dit verhaal op moet maken is dat automatisch configureren dus alleen werkt met Router advertisements. Je kan een IPv6 client configureren voor DHCP, maar als de routers geen Router advertisements sturen, gebeurd er helemaal niets :)

Name resolution

Voor name resolution hebben we een aantal smaken. Natuurlijk hebben we DNS, waar voor IPv6 adressen AAAA recordtypes zijn gedefinieerd en de reverse records uit het IP6.ARPA domein komen. Op zich weinig nieuws aan de horizon. Het enige wat nog te melden valt is dat een IPv6 client alleen de Unicast Local, ISATAP- en Unicast Global adressen registreert in DNS. Link-Local, Teredo, 6to4 en tijdelijke adressen worden niet geregistreerd.

Wins/Netbios is eindelijk einde verhaal…. Of toch niet J…. Ja toch wel, maar Link-Local MultiCast Name Resolution lijkt toch wel heel erg op Netbios. LLMNR gebruikt MultiCast adressen om de systeemnamen van machines te achterhalen.
Een andere techniek Peer Name Resolution Protocol is een Microsoft protocol dat gebruikt wordt om in Peer-to-Peer netwerken een vorm van name resolution te hebben zonder name servers zoals DNS. De peers onderhouden gezamenlijk een routing tabel, waarin nieuwe namen geregistreerd kunnen worden en oude namen verjaren.

IPv6 in de IPv4 wereld

Daar IPv6 niet backwards compatible is met IPv4, maar een compleet nieuw protocol is, en het internet nog niet helemaal IPv6 ready is, hebben we technieken nodig om IPv6 en IPv4 samen te laten werken. Ik zal er een aantal kort beschrijven:

ISATAP

ISATAP is een techniek waarbij IPv4 hosts een virtueel IPv6 adres krijgen zodat ze via een ISATAP router met elkaar kunnen praten. De ISATAP addressen hebben de volgende syntax: NetworkPrefix:0:5EFE:w.x.y.z, waarbij w.x.y.z het IPv4 adres is. Deze techniek is alleen te gebruiken in intranetomgevingen.

6to4

6to4 is een techniek om IPv6 packets te routeren over een IPv4 netwerk, bijvoorbeeld het internet. Het IPv6 verkeer wordt verpakt in TCP packets, en vereist 6to4 routers om het werk te doen. Aangezien 6to4 adressen routeerbaar moeten zijn op het internet beginnen ze met prefix 2000::/3, maar 6to4 adressen hebben een extra identifier, dus de prefix wordt 2002::/16.

Teredo

Teredo neemt de noodzaak voor 6to4 routers in het perimeter weg om IPv6 op het IPv4 netwerk te ondersteunen. Daar de meeste IPv4 NAT routers niet om kunnen gaan met IPv6 verkeer in IPv4 TCP pakketten, biedt Teredo de mogelijkheid om IPv6 in UDP pakketten te verpakken, waar veel NAT routers wel mee om kunnen gaan. 2001::/32 is de prefix voor Teredo adressen.

PortProxy

PortProxy vertaalt IPv6 adressen naar IPv4 adressen en vice versa. Het lijkt op een IPv6 versie van NAT.

Speciale Addressen

Net als met IPv4 zijn er special purpose adressen. Dit zijn:

Bronnen:
http://technet.microsoft.com/nl-nl/network/bb530961(en-us).aspx
http://www.ietf.org/rfc/rfc4291.txt
http://www.ietf.org/rfc/rfc4293.txt

Ik hoop dat deze post een beetje licht schijnt in de duisternis die IPv6 heet J