Verslag van een lezing. IPv6: the new IP generation

Transcriptie

1 Verslag van een lezing IPv6: the new IP generation Gemaakt door Martijn Klasing, studentnummer , in opdracht van de heer Rombout Meijer, voor het vak HKSYMP, van de deeltijdstudie Informatica aan de Hogeschool Utrecht, op 9 november 2005

2 Inhoud 1. Over de lezing Over het practicum Netwerk topologie Terminologie De software, gebruikt tijdens het practicum Ethereal Netsh Telnet Tracert Ping IPv6 versus IPv IPv4-header IPv6-header IPv6 Extension Headers Hop-by-Hop Options Header Destination Options Header Routing Header Fragment Header Authentication Header Encapsulating Security Payload Header Destination options Header De mogelijke waarden van het Next Header veld De notatie van IPv6-adressen De compacte schrijfwijze van de IPv6-adressen Het aangeven van de Network Prefix IPv6-adressen De hiërarchie van de IPv6-adressen Het Unicast adres De speciale Unicast adressen Het Loopback adres Het Unspecified adres Het Multicast adres Het Link-layer Multicast adres De Well-known Groups Het Anycast adres Het Link-local adres De globale distributie van Internet adressen De communicatie paradigma s Unicast Multicast Anycast De adres resolutie Het Neighbor Discovery protocol Router Sollicitation Router Advertisement Neighbor Sollicitation Neighbor Advertisement De Network Prefix informatie Routing Het pad tussen de bron en de bestemming De werking van Tracert Het Time Exceeded bericht Fragmentatie De Path Maximum Transfer Unit Een te groot pakket Het fragmenteren van een pakket...25

3 11. De overgang van IPv4 naar IPv De tijdsplanning van de overgang De visie van de IETF De beschikbare mechanismen De Domain Name Service Proxying Tunneling De Tunneling concepten Automatische Host-to-Host tunnel Automatische Router-to-Host tunnel Geconfigureerde Router-to-Router tunnel Geconfigureerde Host-to-Router tunnel...28 Noten...29 De gebruikte afkortingen...30 De geraadpleegde bronnen...31 Lijst van Request for Comment...32 Informatieve links...34

4 1. Over de lezing Dit verslag behandelt een lezing, die op 3 oktober 2005 werd gehouden in de ruimte D-305a van het gebouw Oudenoord 370 van de Hogeschool Utrecht, met als titel IPv6: the new IP generation. De lezing vond plaats van 16u30 tot 20u00. Met een dinerpauze van 18u00 tot 18u30. Tijdens de dinerpauze werd een catering aangeboden in de kantine van het gebouw aan de Oudenoord 330. De lezing werd gehouden door de heer Luís Santos en de heer Mário Antunes. De heer Santos is professor aan het Instituto Politécnico de Coimbra (ISEC), in Portugal. De heer Antunes is professor aan het Instituto Politécnico de Leira (ESTG), in Portugal. Tijdens de lezing werd gebruik gemaakt van de Engelse taal. De lezing bestond uit twee gedeelten. Een deel van de lezing bestond uit een theoretische behandeling van het onderwerp, waarbij de heren Santos en Antunes, aan de hand van de getoonde sheets, om beurten uitleg gaven. En een deel van de lezing bestond uit een practicum, waarbij de deelnemers aan de lezing de behandelde onderwerpen in de praktijk konden brengen, door gebruik te maken van een aantal computernetwerk opstellingen.

5 2. Over het practicum In dit hoofdstuk komt ten eerste de topologie van de, tijdens het practicum, gebruikte netwerken aan de orde. Vervolgens komen de bij IPv6-netwerken gebruikte termen aan de orde. En als laatste wordt de, tijdens het practicum, gebruikte software programma s belicht Netwerk topologie In de volgende figuur is een netwerk weergegeven, waarmee tijdens de Hands-on geoefend wordt. figuur 1 De topologie bestaat uit twee netwerken: het Lan-A en het Lan-B. Op ieder netwerk huist een computer: de node A en de node B. Een derde computer, node R, heeft twee interfaces. Elk interface is aangesloten op één van de netwerken. Bovendien kan de node R dienen als router tussen de twee netwerken Terminologie In de volgende figuur wordt een voorbeeld van een computernetwerk weergegeven. figuur 2 De fysieke verbinding van een netwerk heet een link. De netwerkonderdelen die zijn aangesloten op een netwerk heten nodes. De interfaces van de netwerkonderdelen die een gezamenlijk netwerk delen heten neighbors De software, gebruikt tijdens het practicum Bij de Hands-on wordt gebruik gemaakt van de volgende software programma s. Ethereal, Netsh, Telnet, Traceroute en Ping. In de volgende paragraven wordt het gebruik van de programma s in het kort belicht.

6 Ethereal Bij de datacommunicatie van computers in een netwerk worden datacommunicatie pakketten tussen de computers uitgewisseld. Het softwareprogramma Ethereal (1) heeft als doel het opvangen van de pakketten en het tonen ervan aan een gebruiker. Hiermee kan een gebruiker de inhoud van de pakketten analyseren. (2) Netsh Om computers te laten werken in een computernetwerk zal een computer, samen met zijn interface met het netwerk, ingesteld moeten worden. Voor het instellen van de computer en de (3) (4) interface wordt gebruik gemaakt van het softwareprogramma Netsh Telnet Telnet is een programma waarmee een node kan inloggen op een andere node via een link Tracert Met een Tracert commando kan een route naar een opgegeven bestemming worden geanalyseerd. In IPv6 wordt de Hop-counter gebruikt door het programma Tracert. In de paragraaf 9.2 wordt de werking van Tracert nader verklaard Ping Met een Ping commando wordt aan een opgegeven bestemming een Echo-request gevraagd. De bestemming reageert hierop met een Echo-reply bericht. Op deze manier kan de mogelijkheid van datacommunicatie met een bestemming worden gecontroleerd. (5) Met het Ping commando wordt tevens de Roundtrip delay tussen bron en bestemming vastgesteld. De Roundtrip delay is de tijd die nodig is voor het versturen van een bericht en het ontvangen van het Echo-reply bericht.

7 3. IPv6 versus IPv4 In het formaat van de IPv4-header en de IPv6-header komen de verschillen tussen de twee protocollen goed naar voren. Daarom wordt in de eerste twee paragraven van dit hoofdstuk het formaat van de IPv4-header en het formaat van de IPv6-header gegeven. Hierop volgen de Extension Headers, die in het IPv6 protocol zijn gedefinieerd De IPv4 Header Een IPv4 Header heeft het volgende formaat Ver IHL TOS Total Length Identification Fla Frag Offs TTL Prot Hdr Checksum Source Address Destination Address Options + Padding figuur 3 De velden van de IPv4 Header hebben de volgend betekenis Ver (4 bit) Version = 4 IHL (4 bit) Internet Header Length, de lengte van de Header in 32-bit woorden TOS (8 bit) Type Of Service, specificatie van de betrouwbaarheid, de voorkeur, de vertraging en de doorvoer van het pakket Total Length (16 bit) Lengte van het totale pakket in octetten Identification (16 bit) Fla (3 bit) Frag Offs (13 bit) TTL (8 bit) Prot (8 bit) Unieke identificatie van het pakket Flags, hiervan zijn twee bits gedefinieerd, het More bit en het Don t Fragment bit, More = 1, meer fragmenten Don t Fragment = 1, geen fragmentatie toegestaan Fragment Offset, volgnummer van het fragment Time-to-Live, levensduur van het pakket in seconde Protocol, het gebruikte protocol in de hoger gelegen laag 6 = TCP 17 = UDP Hdr Checksum (16 bit) Source Address (32 bit) Destination Address (32 bit) Bestemming adres van het pakket Options + padding Door de bron opgegeven opties Header Checksum, fout detectie van de Header Bron adres van het pakket

8 3.2. De IPv6 Header Een IPv6 Header heeft het volgende formaat Ver T Class Flow Label Payload Length Next Hdr Hop Lim Source Address Destination Address figuur 4 De velden van de IPv6 Header hebben de volgende betekenis. Ver (4 bit) Version = 6 T Class (8 bit) Flow Label (20 bit) Payload Length (16 bit) Next Header (8 bit) Hop Limit (8 bit) Source Addres (128 bit) Destination Address (128 bit) 3.3. De IPv6 Extension Headers Traffic Class, specificatie voor Differentiated Services Specificatie van de eisen aan de aflevering van pakketten, voorbeeld: een Real-Time service wordt hiermee gespecificeerd Lengte van het pakket Het type van de Header die volgt op de IPv6 Header Het aantal Links dat het pakket gebruikt tijdens het transport, dit is vergelijkbaar met het Time-to-Live veld in IPv4 Bron adres van het pakket Bestemming adres van het pakket Het IPv6 definieert verschillende Extension Headers en de volgorde waarin de headers in een pakket kunnen voorkomen. De soorten Extension Headers en de volgorde van het voorkomen is in de volgende opsomming gegeven. 1) Hop-by-Hop Options Header 2) Destination Options Header, voor bestemmingen die opgesomd zijn in de Routing Header 3) Routing Header 4) Fragment Header 5) Authentication Header 6) Encapsulating Security Payload Header 7) Destination options Header, voor de finale bestemming van het pakket In de volgende paragraven wordt het formaat van de headers gegeven.

9 De Hop-by-Hop Options Header Het formaat van de Hop-by-Hop Options Header is in de volgende figuur gegeven Nxt Hdr Hdr Len Type Length Options figuur 5 De velden van de Hop-by-Hop Options Header hebben de volgende betekenis. Nxt Hdr (8 bit) Next Header, identificeert het volgend type header Hdr Len (8 bit) Type (8 bit) Length (8 bit) Options De Destination Options Header Header Length, de lengte van de header in 64 bit eenheden Options Type, het type van het opties veld, de vijf minst significante bits identificeren het optie type, de twee volgende bits hebben de volgende betekenis voor een node 00 sla de optie over 01 negeer het pakket 10 negeer het pakket en stuur een ICMP Parameter Problem bericht naar de bron 11 negeer het pakket en stuur een ICMP Parameter Problem bericht naar de bron, alleen als het adres van de bestemming geen multicast adres is De lengte van het opties veld in octetten De specificatie van de opties met een variabele lengte Het formaat van de Destination Options Header is in de volgende figuur gegeven Nxt Hdr Hdr Len Type Length Options figuur 6 Zoals te zien is heeft de Destinations Options hetzelfde formaat als de Hop-by-Hop Options Header. Een Destinations Options Header op deze plaats in het pakket heeft betekenis voor de nodes die genoemd zijn in de Routing Header De Routing Header Er zijn twee soorten Routing Headers, het algemene soort en het specifieke soort. Van het specifieke soort, is tot nu toe alleen het type 0 gedefinieerd Het formaat van de algemene Router Header is in de volgende figuur gegeven Nxt Hdr Hdr Len Rou Type Seg Left Type-specific Data figuur 7 De velden in de Routing Header hebben de volgende betekenis. Nxt Hdr (8 bit) Next Header, identificeert het volgend type header Hdr Len (8 bit) Header Length, de lengte van de header in 64 bit eenheden

10 Rou Type (8 bit) Routing Type, identificeert een bepaalde Routing Header variant, een router die de variant niet herkent, moet het pakket negeren Seg Left (8 bit) Segments Left, het aantal tussen liggende routers tot aan de bestemming van het pakket Het formaat van de specifieke Routing Header, type 0, is in de volgende figuur gegeven Nxt Hdr Hdr Len Rou Type Seg Left Reserved Address Address Address n figuur 8 De eerste vier velden van deze header hebben dezelfde betekenis als de velden van de voorgaande header. Bij het toepassen van deze Routing Header wordt de finale bestemming van het pakket gegeven in het veld dat is aangegeven met Address n. De lijst met adressen wordt tijdens het transport van het pakket aangepast De Fragment Header Het formaat van de Fragment Header is in de volgende figuur gegeven Nxt Hdr Res Fragment Offs Res M Identification figuur 9 De velden van de Fragment Header hebben de volgende betekenis. Nxt Hdr (8 bit) Next Header, identificeert het volgend type header Res (8 bit) Reserved, gereserveerd voor toekomstig gebruik Fragment Offs (13 bit) Plaats van het pakket in het originele pakket, in 64 bit eenheden, de lengte van de fragmenten moeten dus veelvouden zijn van 64 bit, behalve het laatste fragment Res (2 bit) Reserved, gereserveerd voor toekomstig gebruik M (1 bit) More bit, 1 = meer fragmenten, 0 = laatste fragment Identification (32 bit) Identificatie van het originele pakket, dit maakt assemblage van de fragmenten mogelijk

11 De Authentication Header Het formaat van de Authentication Header is in de volgende figuur gegeven Nxt Hdr Payl Len Reserved Security Parameters Index Sequence Number Authentication Data figuur 10 De velden van de Authentication Header hebben de volgende betekenis. Nxt Hdr (8 bit) Next Header, identificeert het volgend type header Payl Len (8 bit) Payload Length, de lengte van de Authentication Header in 32 bit woorden Reserved (16 bit) Gereserveerd voor toekomstig gebruik Security Parameters Index (32 bit) Identificatie van de Security Association Sequence Number (32 bit) Authentication Data De Encapsulating Security Payload Header Het volgnummer van het pakket Een veld dat de Integrity Check Value bevat, het veld is variabel in lengte, de lengte moet echter een veelvoud van 32-bit woorden zijn Het formaat van de Encapsulating Security Payload Header is in de volgende figuur gegeven Security Parameters Index Sequence Number Payload Data Padding Pad Len Nxt Hdr Authentication Data figuur 11 De velden van de Encapsulating Security Payload Header hebben de volgende betekenis. Security Parameters Index (32 bit) Identificatie van de Security Association Sequence Number (32 bit) Het volgnummer van het pakket Payload Data Het ingekapseld pakket, dit is dus de data van de hoger liggende protocol laag, bijvoorbeeld het TCP Padding (0-255 byte) Als het encryptie algoritme een veelvoud van octetten verlangt, kan een conflict ontstaan met de eis die aan het pakket wordt gesteld. In zo n geval kan de padding de data aanvullen om aan de pakket eis te voldoen Pad Len (8 bit) Nxt Hdr (8 bit) Pad Length, het aantal bytes in het Padding veld Identificatie van de header in de Payload Data, bijvoorbeeld een TCP-Header

12 Authentication Data Een veld dat de Integrity Check Value bevat, het veld is variabel in lengte, de lengte moet echter een veelvoud van 32-bit woorden zijn De Destination Options Header De Destination Options Header heeft hetzelfde formaat als de Hop-by-Hop Options Header. Een Destinations Options header op deze plaats in het pakket heeft alleen betekenis voor de finale bestemming van het pakket De mogelijke waarden van het Next Header veld Het volgende overzicht laat de mogelijke waarden zien van het Next Header veld in de Extension Header. 0 Hop-by-Hop Options Header 43 Routing Header 44 Fragment Header 50 Encapsulating Security Payload Header 51 Authentication Header 59 No Next Header 60 Destination Options Header 62 Mobility Header

13 4. De notatie van IPv6 adressen Voor het noteren van IPv6-adressen gelden een aantal afspraken. Ten eerste om de adressen zo compact mogelijk te kunnen weergeven. En ten tweede om in een adres onderscheid te kunnen maken tussen het netwerk deel van het adres en het deel van het adres dat de node aangeeft De compacte schrijfwijze van IPv6 adressen Een IPv6-adres bestaat uit 128 bits. Een byte is een verzameling van 8 bits. Een IPv6-adres bestaat dus uit 128 / 8 = 16 byte. Vier bits kunnen weergegeven worden door één hexadecimaal getal. Een IPv6-adres kan dus weergegeven worden door 16 * 2 = 32 hexadecimale getallen. De hexadecimale getallen worden gegroepeerd in groepjes van vier getallen en gescheiden door een dubbele punt. Het volgende voorbeeld laat een IPv6-adres zien in een hexadecimale notatie. FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 Stel dat het volgende adres genoteerd moet worden. 1080:0000:0000:0000:0008:0800:200C:417A De drie groepjes van vier nullen worden in dit geval weggelaten en als volgt aangegeven. 1080::0008:0800:200C:417A De meest significante getallen die nul zijn worden niet weergegeven. Het bovenstaande voorbeeld wordt dan als volgt genoteerd. 1080::8:800:200C:417A 4.2. Het aangeven van de Network Prefix Het volgende voorbeeld laat een IPv6-adres zien waarbij de eerste 60 bits een netwerk aangegeven. De overige bits, = 68, geven het adres van de node aan. FEDC:BA98:7654:3210:FEDC:BA98:7654:3210/60 Het netwerk adres is dus: FEDC:BA98:7654:321. Het adres van de node is in dit geval: 0:FEDC:BA98:7654:3210.

14 5. IPv6 adressen 5.1. De hiërarchie van IPv6 adressen De hiërarchie van IPv6 adressen komt naar voren in de volgende tabel. De kolommen in de tabel verdelen de adressen naar de soorten adressen. De rijen van de tabel verdelen de adressen naar de reikwijdte, in het Engels de scope. Afhankelijk van de prefix van een adres heeft het adres een zeker bereik. Unicast/Anycast Multicast Everything else FF00::/8 Global 2000::/3 FE0E::/16 Organization FE08::/16 Site-local FEC0::/10 FE05::/16 Admin-local FE04::/16 Link-local FE80::/10 FE02::/16 Interface-local FE01::/16 tabel Het Unicast adres Het formaat van een Unicast adres (6) is in de volgende figuur gegeven. figuur 12 De velden in het Unicast adres hebben de volgende waarden. Global routing prefix adres van een ISP Subnet ID adres van een subnet binnen een site Interface ID gemodificeerd EUI-64 adres Speciale Unicast adressen Er zijn twee speciale adressen in de groep van Unicast adressen, deze zijn: het Loopback adres en het Unspecified adres Het Loopback adres Het Loopback adres heeft het volgende formaat. 0:0:0:0:0:0:0:1 = ::1 Het Loopback adres is een logische verbinding in de interface van een computer. Twee applicaties, draaiend op één computer kunnen met het Loopback adres communiceren. Het Loopback adres kan gebruikt worden om de werking van datacommunicatie van een computer te testen tot en met het interface.

15 Het Unspecified adres Het Unspecified adres heeft het volgende formaat. 0:0:0:0:0:0:0:0 = :: Een Unspecified adres kan als adres door een bron gebruikt worden, als het bronadres niet ter zake doet 5.3. Het Multicast adres Het formaat van een Multicast adres (7) is in de volgende figuur gegeven. figuur 13 De velden in het Multicast adres hebben de volgende waarden. 00PT 4 bit vlag, waarbij de letters P en T de volgende waarden kunnen hebben P = 0, adres niet gebaseerd op een prefix P = 1, adres wel gebaseerd op een prefix T = 0, adres dat permanent is toegewezen door IANA T = 1, adres dat niet permanent is toegewezen door IANA Scope De reikwijdte van het adres, het scope veld kan de volgende waarden hebben 0 = Reserved 8 = Organization-local scope 1 = Node-local scope 9 = Unassigned 2 = Link-local scope A = Unassigned 3 = Unassigned B = Unassigned 4 = Unassigned C = Unassigned 5 = Site-local scope D = Unassigned 6 = Unassigned E = Global scope 7 = Unassigned F = Reserved Group ID Multicast group ID Het Link-layer Multicast adres Op het niveau van de Link-Layer heeft een Multicast adres (8) het volgende formaat. figuur 14

16 Well-kwown Groups Binnen het IPv6 wordt ervan uitgegaan dat routers en nodes beschikken over de volgende adressen. Met deze adressen zijn binnen een netwerk nodes en routers, ongeacht hun specifieke adres, te bereiken. De volgende tabel geeft een overzicht van de Well-known Group adressen. Nodes Routers Site-local FF05::2 Link-local FF02::1 FF02::2 Interface-local FF01::1 FF01::1 tabel Het Anycast adres Een Anycast adres is een speciaal Multicast adres (9). Binnen IPv6 zijn er op dit moment een tweetal Anycast adressen gespecificeerd. Deze zijn: het Subnet-router Anycast adres en het Anycast adres met een Mobile IPv6 Home-agent Anycast ID. Het Subnet-router Anycast adres heeft het volgende formaat. figuur 15 Het Anycast adres met een Mobile IPv6 Home-agent Anycast ID heeft het volgende formaat Het Link-local adres figuur 16 Elk interface krijgt van het besturend Operating System automatisch een permanent Linklocal adres (10). Een Link-local adres wordt deels gevormd door het MAC-adres van het interface. Hiermee is ARP in IPv6 overbodig. Dankzij de opbouw van het Link-local adres zijn de principes van: Plug & Play, Neighbor Discovery en Routing te verwezelijken. In de volgende figuur is de opbouw van het Link-local adres te zien.

17 figuur 17 De prefix van een Link-local adres is FE80::/10, het interface ID wordt gevormd door de 24 meest significante bits van het MAC adres, gevolgd door de waarde FE en afgesloten met de 24 minst significante bits van het MAC adres.

18 6. De globale distributie van Internet adressen Onder auscipiciën van het IANA zijn diverse organisaties verantwoordelijk voor de uitgifte van unieke Internet adressen. In IPv6 is aan een adres te zien waar het bijbehorende netwerk zich globaal bevindt. Dit maakt routing in IPv6 ten opzichte van routing in IPv4 een stuk eenvoudiger. Het volgende overzicht geeft de verdeling van adressen over de verschillende werelddelen en de organisaties die verantwoordelijk zijn voor de uitgifte van publiek toegankelijke adressen. Iana Arin Lacnic RipeNCC Apnic Afrinic Internet Assigned Numbers Authority URL: American Registry for Inernet Numbers, URL: Regio: Noord-Amerika Address Range: 2001:0400::/ :1800::/23 Latin American and Caribbean Internet Address Registry, URL: Regio: Latijns Amerika en de Carraïben Address Range: 2001:1200::/ :1300::/23 Réseaux IP Européens Network Coordination Centre, URL: Regio: Europa, het Midden-Oosten, Centraal-Azië en Afrika Address Range: 2001:0600::/ :0800::/ :0A00::/ :1400::/ :0600::/23 Asia Pacific Network Information Centre, URL: Regio: Azië en de Pacifische regio Address Range: 2001:0200::/ :0C00::/ :0E00::/23 African Internet Numbers Registry IP Addresses, URL: Regio: Afrika

19 7. Communicatie paradigma s Het IPv6 maakt gebruik van drie soorten communicatie modellen. De verschillende communicatie modellen komen tot uitdrukking in het IPv6-adres. De drie soorten adressen zijn: het Unicast-, het Multicast- en het Anycast-adres Unicast Voor een Peer-to-Peer verbinding tussen twee computers wordt gebruik gemaakt van Unicasting. In de volgende figuur is een Unicast verbinding weergegeven Multicast figuur 18 Voor een verbinding tussen een computer en meerdere computers wordt gebruik gemaakt van Multicasting. In de volgende figuur is een Multicast verbinding weergegeven.

20 figuur 19 In IPv6 is het principe van Broadcasting, dat in IPv4 vaak wordt toegepast, niet geoorloofd Anycast Voor een verbinding tussen een computer en een computer: dat een gevraagde dienst levert en dat het meest dichtbij gelegen is wordt gebruik gemaakt van Anycasting. In de volgende figuur is een Anycast verbinding weergegeven. figuur 20 Het Anycast communicatie model maakt een concept mogelijk dat bekend staat onder het Plug & Play concept, of ook wel het Well-known (nearest) IP concept genoemd.

21 8. Adres resolutie In IPv6 vindt geen ARP plaats, omdat het principe van Broadcasting niet wordt toegestaan. In plaats van ARP wordt het Neighbor Discovery protocol toegepast. Er wordt onderscheid gemaakt in het ontdekken van een node en in het ontdekken van een router. Het bericht dat de Network Prefix verstuurt wordt in de laatste paragraaf van dit hoofdstuk gegeven Het Neighbor Discovery protocol Stel dat een pakket verstuurd moet worden naar een node waarvan het IP adres bekend is. Voordat het pakket verstuurd kan worden zal eerst het Link-Layer adres van de bestemming achterhaald moeten worden. Voor het achterhalen van het Link Layer adres wordt in IPv6 het Neighbor Discovery (11) protocol gebruikt. De volgende figuur laat het stapsgewijze verloop van het Neighbor Discovery protocol zien. Het verloop geldt zowel voor het ontdekken van een node als voor het ontdekken van een router. figuur 21 Hier volgt een omschrijving van de stappen bij Neighbor Discovery. 1) Een datagram is klaar voor verzending, 2) Het Link-Layer van de bestemming wordt in de cache gezocht, 3) Het Link-Layer adres van de bestemming bevindt zich niet in de cache, 4) De bron stuurt een Neighbor Sollicitation over het netwerk, 5) De bestemming herkent het Link-Layer adres en slaat het Link-Layer adres van de bron op in de cache, 6) De bestemming stuurt een Neighbor Advertisement over het netwerk naar de bron, 7) Het Link-Layer adres wordt in de cache opgeslagen, 8) Het Link-Layer adres van de bestemming wordt in het datagram opgenomen. In de volgende paragraven worden de berichten die bij Neighbor Discovery gebruikt worden belicht Router Sollicitation Bij een Router Sollicitation (12) wordt een ICMPv6 bericht gebruikt, met het volgende formaat Type Code Checksum Reserved Options figuur 22 De velden in het ICMP-bericht hebben de volgende waarden. Type (8 bit) 133 Code (8 bit) 0

22 Checksum (16 bit) Reserved (32 bit) Options checksum van het ICMP-bericht gereserveerd voor toekomstig gebruik Link-Layer adres van de bron Router Advertisement Bij een Router Advertisement (13) wordt een ICMPv6 bericht gebruikt, met het volgende formaat Type Code Checksum Hop Lim. M O Res. Router Lifetime Reachable Time Retrans Timer Options figuur 23 De velden in het ICMP-bericht hebben de volgende waarden. Type (8 bit) 134 Code (8 bit) 0 Checksum (16 bit) checksum van het ICMP-bericht Hop Lim. (8 bit) Current Hop Limit, de waarde die de Hop-count moet krijgen in het uitgaande pakket M (1 bit) 1 = stateful address autoconfiguration protocol O (1 bit) 1 = stateful non-address autoconfiguration protocol Res. (6 bit) Reserved = 0 Router Lifetime (16 bit) 0 = no default router, de waarde in seconden, en maximaal 18.2 uur Reachable Time (32 bit) de waarde, in milliseconde, waarbinnen de Neighbor bereikbaar is Retrans Timer (32 bit) de waarde, in milliseconde, van de retransmissie van Neighbor Sollicitation berichten Options De mogelijke opties zijn: Link-Layer adres van de bestemming, MTU, Prefix informatie

23 Neighbor Sollicitation Bij een Neighbor Sollicitation (14) wordt een ICMPv6 bericht gebruikt, met het volgende formaat Type Code Checksum Reserved Target Adress Options figuur 24 De velden in het ICMP-bericht hebben de volgende waarden. Type (8 bit) 135 Code (8 bit) 0 Checksum (16 bit) checksum van het ICMP-bericht Reserved (32 bit) gereserved voor toekomstig gebruik Target Address (128 bit) het adres van de bestemming Options Neighbor Advertisement Bij een Neighbor Advertisement (15) wordt en ICMPv6 bericht gebruikt, met het volgende formaat Type Code Checksum R S O Reserved Target Adress Options figuur 25 De velden in het ICMP-bericht hebben de volgende waarden. Type (8 bit) 136 Code (8 bit) 0 Checksum (16 bit) checksum van het ICMP-bericht R (1 bit) Router Flag, geeft de router onbereikbaarheid aan S (1 bit) Sollicited flag, geeft de node onbereikbaarheid aan O (1 bit) Override Flag, geeft het verversen van de cache aan Reserved (29 bit) gereserveerd voor toekomstig gebruik Target Address (128 bit) het adres van de bestemming Options

24 8.2. De Network Prefix informatie Een ICMPv6 bericht dat wordt gebruikt voor het geven van Network Prefix informatie heeft het volgende formaat Type Length Pref Len L A Valid Lifetime Preferred Lifetime Reserved Prefix figuur 26 De velden in het ICMP-bericht hebben de volgende betekenis. Type (8 bit) 3 Length (8 bit) de lengte van het ICMP-bericht Pref Len (8 bit) Prefix Length, de lengte van de Prefix L (1 bit) L = 1, het netwerk is On Link A (1 bit) A = 1, het bericht is een Autonomous Address Configuration Valid Lifetime (32 bit) Prefered Lifetime (32 bit) Reserved (32 bit) gereserveerd = 0 Prefix de Network Prefix de geldige levensduur voor de verkregen Prefix een suggestie voor de levensduur van de verkregen Prefix

25 9. Routing 9.1. Het pad tussen de bron en de bestemming Een node dat data gaat verzenden is verantwoordelijk voor het kiezen van de juiste pakketgrootte, om het transport mogelijk te maken. In het volgende hoofdstuk wordt hier verder op ingegaan. De consequentie van de verantwoordelijkheid is dat de node het pad moet kennen naar de bestemming. Voor het ontdekken van het pad wordt een werkwijze gevolgd die analoog is aan werkwijze van het commando Tracert. De volgende figuur brengt de werkwijze in beeld De werking van Tracert figuur 27 Een node stelt een bericht samen met als inhoud een Echo-request. (destination port = 7, van de TCP/UDP-header) In de IP-header wordt aan de Hop-limit de waarde 1 gegeven. Als het bericht de eerste router bereikt wordt de Hop-limit met één verlaagt. De Hop-limit is nu nul en de eerste router zal het bericht niet verder routeren. Wel stuurt de router een ICMPv6-bericht naar de bron. In reactie op het ICMPv6-bericht stelt de bron een volgend bericht samen. De Hop-limit krijgt in dit bericht de waarde 2. Het bericht passeert nu de eerste router en arriveert bij de tweede router. De tweede router verlaagt de Hop-limit met één. De Hop-limit is weer nul en het bericht zal niet verder gerouteerd worden. De tweede router stuurt hierop een ICMPv6-bericht naar de bron. Zolang de bron ICMP-berichten ontvangt stelt deze een bericht samen, waarbij de Hop-limit telkens met één verhoogd wordt. Uiteindelijk komt het bericht bij de bestemming die reageert op het echo-request. De bestemming reageert hierop met een Echo-reply. Het resultaat van deze werkwijze is dat de bron het pad kent naar de bestemming.

26 9.3. Het Time Exceeded bericht Het formaat van het ICMPv6-bericht (16) dat een router stuurt naar een bron, heeft het volgende formaat Type Code Checksum Unused Data figuur 28 De velden in het ICMP-bericht hebben de volgende waarden. Type (8 bit) 3 Code (8 bit) 0 = Hop-limit overschrijding, 1 = defragmentatie timer overschreden Checksum (16 bit) checksum van het ICMP-bericht Unused (32 bit) vereiste pakketgrootte van de Next-hop link Data zoveel van het ontvangen pakket dat de MTU toestaat De router die een Hop-limit met een waarde nul ontvangt stuurt dus een ICMPv6-bericht met een waarde nul in het veld Code.

27 10. Fragmentatie Een link in een datanetwerk heeft, afhankelijk van de gebruikte technologie, een maximale grootte van een pakket dat het kan transporteren. Dit wordt de Maximum Transfer Unit (MTU) genoemd. In IPv6 wordt een minimale MTU voorgeschreven van 1280 octetten. Er wordt onderscheid gemaakt tussen een link-mtu en een true-mtu. Een link MTU is de maximale pakketgrootte dat over een individuele link getransporteerd kan worden. Een true- MTU is de maximale pakketgrootte dat over een End-to-End verbinding vervoerd kan worden. Een true-mtu is dus gelijk aan de MTU van de link dat de kleinste pakketgrootte kan transporteren Path Maximum Transfer Unit Nadat een node een pad heeft vastgesteld, voor het verzenden van pakketten naar een bestemming, zal de node de maximale pakketgrootte dat over het pad vervoert kan worden moeten vaststellen. (17) De volgende figuur geeft hiervan een voorbeeld Een te groot pakket figuur 29 Het kan gebeuren dat, bij het vaststellen van een true-mtu, een pakket te groot blijkt te zijn. Een router ontvangt een pakket dat te groot is voor transport over een uitgaande link. In dit geval stuurt de router een ICMP-bericht naar de bron. De bron zal het pakket moeten verkleinen in een poging te voldoen aan de link-mtu. (18) De volgende figuur laat het formaat van het ICMP-bericht zien Type Code Checksum MTU Data figuur 30 De velden in het ICMP-bericht hebben de volgende waarden. Type (8 bit) 2 Code (8 bit) 0 Checksum (16 bit) checksum van het ICMP-bericht MTU (32 bit) vereiste pakketgrootte van de Next-hop link Data zoveel van het te grootte pakket dat de MTU toestaat

28 10.3. Het fragmenteren van een pakket Nadat is gebleken dat een pakket te groot is zal de bron het pakket moeten opdelen in pakketten met een kleinere grootte. Dit wordt fragmenteren genoemd. De volgende figuur laat het fragmenteren van een pakket zien /.../ Unfragmentable First Second Last Part Fragment Fragment Fragment /.../ Het oorspronkelijke pakket Unfragmentable Fragment First Part Header Fragment Unfragmentable Fragment Second Part Header Fragment Unfragmentable Fragment Last Part Header Fragment Het gefragmenteerde pakket figuur 31 De Fragment Header is één van de Extension Headers. Het formaat van de Fragment Header is in de paragraaf gegeven. De waarde van het Next Header veld inde Fragment Header wordt als volgt ingevuld. (19) Het Next Header veld wijst naar de Header van het hoger liggend protocol in de ingekapselde data. Bijvoorbeeld, geldt voor TCP in dat geval de waarde 6. De laatste Header van het Unfragmentable Part krijgt in het Next Header veld de waarde 44, zoals in de paragraaf 3.4 is gegeven.

29 11. De overgang van IPv4 naar IPv De tijdsplanning van de overgang Bij het in gebruik nemen van de eerste generatie computernetwerken ontstond destijds een scala aan netwerkprotocollen. Op 1 jan 1983 werd het IP aanvaard als standaard protocol. Voor het in gebruik nemen van IPv6 is, door de grootschaligheid van het huidige Internet, geen scherpe overgangsdatum mogelijk. Verwacht wordt dat de overgang zal verlopen volgens de volgende tijdslijn IPv4 beslaat het gehele Internet IPv6 heeft een klein aandeel in het Internet IPv6 heeft een groot aandeel in het Internet IPv6 beslaat het gehele Internet De visie van het IETF De diverse werkgroepen van het IETF hanteren de volgende tijdsplanning bij het invoeren van IPv6. Voor 2002 wordt aan de transitie gewerkt. (ngtrans (20) ) Na 2002 komt het IPv6 operationeel. (v6ops (21) ) De beschikbare mechanismen Voor de overgang van IPv4 naar IPv6 zijn drie mechanismen voorhanden, deze zijn: Domain Name Service (DNS), Proxying en Tunneling. De drie mechanismen komen in de volgende paragraven aan de orde Domain Name service De voornaamste voorzieningen in de DNS (22) ten behoeve van IPv6-adressen zijn: Een nieuw record type, met als type waarde 28, in de DNS om IPv6 adressen te herbergen, het nieuwe record type wordt een AAAA-record genoemd; Een nieuw domein om IPv6 adressen te herbergen, De root van het domein wordt het IP6.INT-domein genoemd; Een herdefinitie van het zoekproces naar IP adressen, de herdefinitie betekent dat een zoekproces zowel de IPv4- als de IPv6-adressen moet leveren Proxying Bij de overgang van IPv4 naar IPv6 kan een netwerk bestaan uit gedeelten waarin de twee protocollen naast elkaar bestaan. Om de verschillen in de gebruikte protocollen te verhullen voor de nodes kan het proxy principe (23) gebruikt worden. De volgende figuur brengt in beeld. figuur 32

30 Stel dat de node A een Telnet verbinding wil opzetten met de node B. De proxy server zal de Telnet dienst van de node B voor zijn rekening nemen. De verbinding wordt opgezet met het commando: telnet <IP-adres proxy server> 3000 Vanuit port 3000 zal de proxy server de datacommunicatie verzorgen naar port 23 (telnet) van de node B Tunneling Het principe van Tuneling voorziet in de mogelijkheid om IPv6 pakketten te vervoeren over IPv4 netwerken. Een IPv6 pakket wordt ingekapseld in een IPv4 pakket en als zodanig verstuurt. De ontvanger zal het pakket zal het pakket ontkapselen en daarmee het IPv6 pakket ontvangen. Zowel de bron als de ontvanger maken hierbij gebruik van een dual stack. Het principe van een dual stack is in de hier naast staande figuur weergeven De Tunneling concepten Het algemen principe van Tunneling is in de volgende figuur weergegeven. Een IPv6 pakket wordt, bij de bron, ingekapseld in een IPv4 pakket en vervolgens getransporteerd over een IPv4 netwerk. Bij de bestemming wordt het pakket ontdaan van het IPv4 kapsel. Het protocol veld van de IPv4 Header heeft in dit geval de waarde 41. Bij Tunneling wordt onderscheid gemaakt in het fysieke interface en een pseudo interface. Het fysieke interface wordt geadresseerd met een IPv4 adres. Het pseudo interface wordt geadresseerd met een IPv6 adres, dat een relatie heeft met het IPv4 adres. Stel dat een fysieke interface het volgende adres heeft Het adres van het pseudo interface is dan. ::[ ]/96 figuur 34 Er worden verschillende concepten van Tunneling (24) toegepast. De volgende paragraven geven hiervan een overzicht.

31 Automatische Host-to-Host tunnel De volgende figuur geeft het principe van een automatische Host-to-Host tunnel weer. figuur 35 De adressen van IPv6 pakketten die door middel van Tunneling worden getransporteerd, worden 6to4-adressen genoemd. Stel dat de fysieke interface van de bestemming het volgende IPv4 adres heeft Het globale IPv6 adres heeft dan het volgende formaat. 2002:[ ]::[ ]/ Automatische Router-to-Host tunnel De volgende figuur geeft het principe van een automatische Router-to-Host tunnel weer. figuur Geconfigureerde Router-to-Router tunnel De volgende figuur geeft het principe van een geconfigureerde Router-to-Router tunnel weer. figuur Geconfigureerde Host-to-Router tunnel De volgende figuur geeft het principe van een geconfigureerde Host-to-Router tunnel weer. figuur 38

32 Noten (1) Ethereal is used by network professionals around the world for troubleshooting, analysis, software and protocol development, and education. It has all of the standard features you would expect in a protocol analyzer, and several features not seen in any other product. Its open source license allows talented experts in the networking community to add enhancements. It runs on all popular computing platforms, including Unix, Linux, and Windows. ( (2) Zie de informatieve link, nummer 4. (3) Netsh is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh also provides a scripting feature that allows you to run a group of commands in batch mode against a specified computer. Netsh can also save a configuration script in a text file for archival purposes or to help you configure other servers. ( (4) Zie: de informatieve link, nummer 10. (5) Uit: Datacommunicatie TM7. (6) Zie RFC 3587, IPv6 Global Unicast Address Format. (7) Zie: RFC 3306, 4 Multicast Address Format. (8) Zie: RFC 2464, 7 Address Mapping Multicast. (9) Zie: RFC 2526, Reserved IPv6 Subnet Anycast Addresses. (10) Zie: RFC 2461, 5.3 Creation of Link-Local Addresses; RFC 3513, Appendix A: Creating Modified EUI-64 format Interface IDs. (11) Zie: RFC 2461 Neighbor Discovery for IP Version 6 (IPv6). (12) Zie: RFC 2461, 4.2 Router Sollicitation Message Format. (13) Zie: RFC 2461, 4.2 Router Advertisement Message Format. (14) Zie: RFC 2461, 4.3 Neighbor Advertisement Message Format. (15) Zie: RFC 2461, 4.4 Neighbor Advertisement Message Format. (16) Zie: RFC 2463, 3.3 Time Exceeded Message. (17) Zie: RFC (18) Zie: RFC 2463, 3.2 Packet Too Big Message. (19) Zie: RFC 2460, 4.5 Fragment Header. (20) Een beschrijving van de transitie is te vinden in (21) Een beschrijving van de operatie is te vinden in (22) Zie: RFC 1886, DNS extensions to support IP version 6 en RFC 2874, DNS extensions to support IPv6 address aggregations and renumbering. (23) Zie: RFC 2765, Stateless IP/ICMP translation algorithm (SIIT); RFC 2766, Network adress translation protocol translation (NAT-PT); RFC 3142, An IPv6-to-IPv4 transport relay translator (TRT) (24) Zie: RFC 2529, Transmission of IPv6 over IPv4 domains without explicit tunnels; RFC 2893, Transition mechanisms for IPv6 host and routers; RFC 3053, IPv6 tunnel broker.

33 De gebruikte afkortingen Hier volgt een overzicht van de in dit verslag gebruikte afkortingen. ARP Address Resolution Protocol DNS Domain Name Service EUI Extended Uniform Identifier http Hypertext Transfer Protocol IANA Internet Assigned Numbers Authority ICMP Internet Control Message Protocol ICMPv6 Internet Control Message Protocol, versie 6 ID Identification IETF Internet Engineering Task Force IP Internet Protocol IPv4 Internet Protocol, versie 4 IPv6 Internet Protocol, versie 6 ISP Internet Service Providier Lan Local Access Network MAC Medium Access Connector MTU Maximum Transfer Unit TCP Transport Control Protocol UDP Unspecified Datagram Packet URL Uniform Resource Locator www World Wide Web

34 De geraadpleegde bronnen Bij het maken van dit verslag zijn de volgende bronnen geraadpleegd , Data & Computer Communications, Sixth Edition, William Stallings, Prentice Hall International Editions, Upper Saddle River, New Jersey, USA, , Computer Networks, Second Edition, Andrew S. Tanenbaum, Prentice Hall International Editions, Englewood Cliffs, New Jersey, USA, , Computers en Internetten, Douglas E. Comer, Academic Service, Schoonhoven, , Datacommunicatie TM7, Ing W.J. Roos, A.H. Martens, Educatieve Partners, Houten, Stam Techniek, 1996 IPv6: the new IP generation, de sheets welke beschikbaar zijn gesteld bij de lezing van de heren Antunes en Santos Request For Comment

35 Lijst van Request For Comment Het volgende overzicht laat de Request For Comment (RFC) zien die gerelateerd zijn aan de in dit verslag behandelde onderwerpen. RFC 1886 RFC 1981 RFC 2136 RFC 2292 RFC 2373 RFC 2400 RFC 2401 RFC 2402 RFC 2406 RFC 2460 RFC 2461 RFC 2462 RFC 2463 RFC 2464 RFC 2474 RFC 2475 RFC 2526 RFC 2528 RFC 2529 RFC 2553 RFC 2693 DNS Extensions to support IP version 6, Thomson S., Huitema C., Network Working Group, 1995 Path MTU Discovery for IP version 6, McCann J., Deering S., Mogul J., Network Working Group, 1996 Dynamic Updates in the Domain Name System (DNS UPDATE), Thomson S., Rekhter J., Bound J., Network Working Group, 1997 Advanced Sockets API for IPv6, Stevens W., Thomas M., Network Working Group, 1998 IP Version 6 Addressing Architecture, Hinden R., Deering S., Network Working Group, 1998 Internet Official Protocol Standards, Postel J., Reynolds J., Internet Architecture Board, 1998 Security Architecture for the Internet Protocol, Kent S., Atkinson R., Network Working Group, 1998 IP Authentication Header, Kent S., Atkinson R., Network Working Group, 1998 IP Encapsulating Security Payload (ESP), Kent S., Atkinson R., Network Working Group, 1998 Internet Protocol, Version 6 (IPv6) Specification, Deering S., Hinden R., Network Working Group, 1998 Neighbor Discovery for IP Version 6 (IPv6), Narten T., Nordmark E., Simpson W., Network Working Group, 1998 IPv6 Stateless Address Autoconfiguration, Thomson S., Narten T., Network Working Group, 1998 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, Conta A., Deering S., Network Working Group, 1998 Transmission of IPv6 Packets over Ethernet Networks, Crawford M., Network Working Group, 1998 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Nichols K., Blake S., Baker F., Black D., Network Working Group, 1998 An Architecture for Differentiated Service, Blake S., Black D., Carlson M., Davies E., Wang Z., Weiss W., Network Working Group, 1998 Reserved IPv6 Subnet Anycast Addresses, Johnson D., Deering S., Network Working Group, 1999 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates, Housley R., Polk W., Network Working Group, 1999 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, Carpenter B., Jung C., Network Working Group, 1999 Basic Socket Interface Extensions for IPv6, Gilligan R., Thomson S., Bound J., Stevens W., Network Working Group, 1999 SPKI Certificate Theory, Ellison C., Frantz B., Lampson B., Rivest R., Thomas B., Ylonen T., Network Working Group, 1999

36 RFC 2765 RFC 2766 RFC 2874 RFC 2893 RFC 3041 RFC 3053 RFC 3056 RFC 3068 RFC 3142 RFC 3306 RFC 3387 RFC 3484 RFC 3513 RFC 3587 RFC 3775 Stateless IP/ICMP Translation Algorithm (SIIT), Nordmark E., Network Working Group, 2000 Network Address Translation - Protocol Translation (NAT-PT), Tsirtsis G., Srisuresh P, Network Working Group, 2000 DNS Extensions to Support IPv6 Address Aggregation and Renumbering, Crawford M., Huitema C., Network Working Group, 2000 Transition Mechanisms for IPv6 Hosts and Routers, Gilligan R., Nordmark E., Network Working Group, 2000 Privacy Extensions for Stateless Address Autoconfiguration in IPv6, Narten T., Draves R., Network Working Group 2001 IPv6 Tunnel Broker, Durand A., Fasano P., Guardini I., Lento D., Network Working Group, 2001 Connection of IPv6 Domains via IPv4 Clouds, Carpenter B., Moore K., Network Working Group, 2001 An Anycast Prefix for 6to4 Relay Routers, Huitema C., Network Working Group, 2001 An IPv6-to-IPv4 Transport Relay Translator, Hagino J., Yamamoto K., Network Working Group, 2001 Unicast-Prefix-based IPv6 Multicast Addresses, Haberman B., Thaler D., Network Working Group, 2002 Consideration from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network, Eder M., Chaskar H., Nag S. Network Working Group, 2003 Default Address Selection for Internet Protocol version 6 (IPv6), Draves R., Network Working Group, 2003 Internet Protocol Version 6 (IPv6) Addressing Architecture, Hinden R., Deering S., Network Working Group, 2003 IPv6 Global Unicast Address Format, Hinden R., Deering S., Nordmark E., Network Working Group, 2003 Mobility Support in IPv6, Johnson D., Perkins C., Arkko J., Network Working Group, 2004

37 Informatieve links Bij de onder staande links is verder gaande informatie te vinden over de in dit verslag behandelde onderwerpen url=/technet/prodtechnol/winxppro/proddocs/netsh.asp