IPv6 Case Study Leidraad voor de invoering van IPv6 in organisaties
februari 2011, versie 1.0 François Kooman
Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding 3.0 Nederland licentie (http://creativecommons.org/licenses/by/3.0/nl/). 2/18
Inhoudsopgave 1. Introductie.......................................................................................................................................... 4 2. Configuratie van eindgebruikerssystemen.......................................................................................... 5 2.1. IPv4-configuratie......................................................................................................................... 5 2.2. IPv6-configuratie......................................................................................................................... 5 3. IPv6-configuratie................................................................................................................................ 6 3.1. Statisch configureren.................................................................................................................. 6 3.2. Dynamisch configureren met SLAAC........................................................................................... 6 3.3. Dynamisch configureren met DHCPv6........................................................................................ 6 3.4. Nummerplan............................................................................................................................... 6 4. DNS-configuratie voor IPv6................................................................................................................. 7 4.1. Statisch configureren.................................................................................................................. 7 4.2. Dynamische configureren met RDNSS........................................................................................ 7 4.3. Dynamisch configureren met DHCPv6........................................................................................ 7 5. RA, RDNSS, DHCPv6?.......................................................................................................................... 8 6. NAT64................................................................................................................................................. 9 7. Beveiliging van IPv6-netwerken........................................................................................................ 10 7.1. Neighbor Discovery.................................................................................................................. 10 7.2. DHCPv6.................................................................................................................................... 11 7.3. Servers en eindgebruikerssystemen......................................................................................... 11 8. Identificeren Individuele Eindgebruikers........................................................................................... 12 8.1. IPv4.......................................................................................................................................... 12 8.2. IPv6.......................................................................................................................................... 12 9. Testconfiguratie................................................................................................................................ 13 9.1. Linux ........................................................................................................................................ 13 9.1.1. SLAAC en RA..................................................................................................................... 13 9.1.2. DHCPv6............................................................................................................................. 13 9.2. Cisco IOS.................................................................................................................................. 14 9.2.1. SLAAC en RA..................................................................................................................... 14 9.2.2. DHCPv6............................................................................................................................. 14 9.3. Problemen................................................................................................................................ 14 9.3.1. ACL issues met IPv6-verbindingen.................................................................................... 14 9.3.2. Beperkte beschikbaarheid over IPv6................................................................................. 15 10. Conclusie........................................................................................................................................ 16 11. Bijlage A - NDPMon......................................................................................................................... 17
3/18
1.
Introductie
Dit document beschrijft het implementeren van IPv6 in een bestaand netwerk van een organisatie, meestal een LAN, waarin zich eindgebruikerssystemen bevinden. Het doel van dit document is het beschrijven hoe een netwerk met zowel IPv4 als IPv6 connectiviteit (dual-stack1) opgezet kan worden. Dit document gaat vooral in op praktische zaken: 1. Noodzakelijke aanpassingen in het netwerk; 2. Status van IPv6-ondersteuning in veelgebruikte besturingssystemen. Het document zal zich in de uitleg beperken tot een enkel netwerk (of één (V)LAN) en niet ingaan op bijvoorbeeld BGP configuratie of nummerplannen. Als model is genomen het VLAN op het SURFnet kantoor in Utrecht met daarin de systemen van de medewerkers. Hierin bevinden zich veel verschillende apparaten die goed gebruikt kunnen worden om hun compatibiliteit met IPv6 (dual-stack) netwerken te testen. Eveneens zullen voorbeeldconfiguraties beschreven worden voor diverse netwerkapparatuur. Er wordt vanuit gegaan dat IPv6 al beschikbaar is op de router die verbonden is aan het (V) LAN met eindgebruikerssystemen. Dit kan dan zijn ofwel via een native IPv6-verbinding zoals bijvoorbeeld door SURFnet2 geleverd, ofwel via een 6in4 tunnel die te krijgen zijn bij bijvoorbeeld SixXS3.
1
2 3
Onder dual-stack wordt hier verstaan het inrichten van een netwerk zodat de IPv6-connectiviteit onafhankelijk werkt van IPv4-connectiviteit (en andersom), maar zowel IPv4 als IPv6 tegelijk (volledig) actief zijn en automatisch op eindgebruikerssystemen geconfigureerd kunnen worden zonder (handmatig) ingrijpen van de gebruiker. Native IPv6 is te verkrijgen door instellingen bij SURFnet als onderdeel van de dienst “SURFinternet”. Meer informatie hierover is beschikbaar bij de account adviseur van de instelling. Zie http://www.sixxs.net.
4/18
2.
Configuratie van eindgebruikerssystemen
2.1.
IPv4-configuratie
In IPv4-netwerken zijn er voor het configureren van IP-adressen twee methoden: 1. Statisch configureren; 2. Dynamisch configureren met DHCP4. Voor DNS-resolvers zijn er eveneens (dezelfde) twee opties: 1. Statisch configureren; 2. Dynamisch configureren met DHCP. De eerste optie wordt eigenlijk alleen gebruikt voor “vaste” elementen in het netwerk zoals routers en servers. De tweede optie wordt vooral gebruikt voor eindgebruikerssystemen.
2.2.
IPv6-configuratie
Voor IPv6-netwerken is er voor het configureren van IP-adressen een extra methode: 1. Statisch configureren; 2. Dynamisch configureren met stateless address auto configuration (SLAAC); 3. Dynamisch configureren met DHCPv6. Voor DNS-resolvers zijn er eveneens drie opties: 1. Statisch configureren; 2. Dynamisch configureren met RDNSS; 3. Dynamisch configureren met DHCPv6. Deze methoden kunnen door elkaar gebruikt worden. Het is bijvoorbeeld mogelijk om via SLAAC de IP-adressen te (laten) configureren en via de DHCPv6 server de DNS-resolvers door te geven. In het volgende hoofdstuk worden de verschillende methoden voor IPv6configuratie besproken.
4
In dit document staat DHCP voor DHCPv4, DHCPv6 wordt altijd expliciet zo genoemd.
5/18
3. 3.1.
IPv6-configuratie Statisch configureren
Statische configuratie wordt veelal gebruikt bij “vaste” elementen in het netwerk zoals routers en servers. Dit verschilt niet van IPv4-netwerken. De prefix van een netwerk is standaard /64 binnen een (V)LAN 5. Het is technisch mogelijk om kleinere netwerken te gebruiken, maar dan is het niet langer mogelijk SLAAC te gebruiken voor eindgebruikerssystemen.
3.2.
Dynamisch configureren met SLAAC
Stateless address autoconfiguration (SLAAC) is beschreven in RFC 4862. Om een globaal uniek adres te krijgen speelt de router een belangrijke rol. Deze router kondigt via een “router advertisement” (RA) een prefix aan op het netwerk. Hierin zal de host dan zelf een adres kiezen waarbij wordt gezorgd dat deze uniek is binnen de prefix. Voor IPv4 is een prefix bijvoorbeeld 192.168.1.0/24 waarin zich 28 (= 256) adressen bevinden. Bij IPv6 is deze prefix 64 bits voor (V)LANs, bijvoorbeeld 2001:610:508:109::/64. Hierin bevinden zich dus 264 (= heel veel) adressen. Bij de keuze van een adres in de IPv6-prefix wordt uitgegaan van het MAC-adres van de netwerkadapter. Omdat dit MAC-adres (per definitie) globaal uniek is, is dit meestal een goede keuze. Dit is echter privacygevoelig omdat hiermee het MAC-adres van de netwerkadapter permanent opgenomen wordt in het IPv6-adres. Daarom wordt bijvoorbeeld in Windows (Vista en nieuwer) standaard gebruik gemaakt van privacy uitbreiding zoals beschreven in RFC 4941. Hiermee is het IPv6-adres van de host niet altijd hetzelfde en ook niet te correleren met het MAC-adres. In Mac OS X en Linux 6 is het mogelijk deze privacy uitbreiding handmatig te activeren.
3.3.
Dynamisch configureren met DHCPv6
Hier wordt gebruik gemaakt van DHCPv6 zoals beschreven in RFC 3315. Dit houdt in dat, zoals bij DHCP voor IPv4-adressen, de DHCPv6-server een adres uitdeelt in een vooraf in de server gespecificeerde reeks. In de RA van de router moet de flag “Managed address configuration” gezet worden zodat de host weet dat DHCPv6 gebruikt wordt voor de adresconfiguratie (zie RFC 2461). Opgemerkt moet worden dat niet zoals bij DHCP het adres van de router via DHCPv6 doorgeven kan worden. De router(s) moeten altijd een RA uitsturen.
3.4.
Nummerplan
Om een netwerk goed in te richten, als er bijvoorbeeld een /48 prefix beschikbaar is heeft SURFnet een ander document beschikbaar gemaakt: “IPv6-nummerplan opstellen ” 7. Hierin wordt een methode voorgesteld om de prefix logisch op te delen in /64 prefixen.
5 6 7
De minimale prefix is /64 voor een LAN (zie RFC 4291). Voor een “abonnee” (bijvoorbeeld een instelling) wordt in principe een /48 (2^16 /64 netwerken) of een /56 (2^8 /64 netwerken) prefix gebruikt. Met Linux wordt eigenlijk GNU/Linux bedoeld, de Linux kernel en de bijhorende user-space applicaties die onderdeel uitmaken van een distributie zoals bijvoorbeeld Red Hat Enterprise Linux, Ubuntu of Debian. Beschikbaar op de SURFnet website: http://www.surfnet.nl/Documents/handleiding_IPv6_nummerplan_v10.pdf.
6/18
4. 4.1.
DNS-configuratie voor IPv6 Statisch configureren
Statische configuratie wordt veelal gebruikt bij “vaste” elementen in het netwerk zoals routers en servers. Dit verschilt niet van IPv4-netwerken.
4.2.
Dynamische configureren met RDNSS
Recursive DNS Server (RDNSS) zoals beschreven in RFC 6106 (IPv6 Router Advertisement Options for DNS Configuration) is een methode om adressen van DNS-resolvers bekend te maken bij hosts. De adressen van de resolver(s) worden opgenomen in de RA.
4.3.
Dynamisch configureren met DHCPv6
Hier wordt gebruik gemaakt van DHCPv6 zoals beschreven in RFC 3315. Net als bij DHCP kunnen ook via DHCPv6 de DNS-resolver(s), en indien gewenst andere configuratie, doorgegeven worden aan de hosts. In de RA van de router moet de flag “Other stateful configuration” gezet worden, zodat de host weet dat DHCPv6 gebruikt dient te worden voor het ophalen van de DNS-resolver(s) en eventueel andere informatie (zie RFC 2461).
7/18
5.
RA, RDNSS, DHCPv6?
Met deze verschillende mogelijkheden voor (automatische) configuratie van adressen en DNS-resolvers is het de vraag welke gekozen moet worden. Verschillende besturingssystemen en (mobiele) devices ondersteunen slechts een (niet overlappend) deel van al deze mogelijke methoden. Het zal dus een “mix and match” worden van alles hierboven beschreven. Router advertisements zijn altijd nodig in elke situatie. RDNSS wordt slechts ondersteund door een enkel besturingssysteem, evenals DHCPv6, maar dan weer een andere set. Besturingssysteem
Versie
SLAAC
RDNSS
DHCPv6
Handmatig8
Dual-stack
Microsoft Windows9
7
Ja
Nee
Ja
Ja
Ja
Apple Mac OS X
10.6.5
Ja
Nee
Nee
Ja
Nee
Apple iOS10
4.2.1
Ja
Nee
Ja
Nee
Ja
Google Android11
2.2
Ja
Nee
Nee
Nee
Nee
Linux (Ubuntu)12
10.04.1
Ja
Ja13
Nee
Ja
Nee
Linux (Fedora)
14
Ja
Ja
Ja
Ja
Ja14
Cisco IOS
15.x
Ja
Nee
Ja
Ja
Ja
Tabel 1: Ondersteuning automatische configuratie IPv6 in besturingssystemen Dit laat zien dat DHCPv6 onmisbaar is15. RDNSS heeft momenteel beperkt nut omdat alleen Fedora (en Ubuntu na installatie van een optioneel softwarepakket) dit ondersteunt. Echter zal RDNSS in de toekomst wel eens belangrijk kunnen worden en het gebruik van DHCPv6 volledig overbodig maken, zeker als er overgeschakeld wordt op secure neighbor discovery (zie sectie 7.1). Ook valt op dat Mac OS X, Google Android en Ubuntu buiten de boot vallen als er DNSresolvers automatisch geconfigureerd moeten worden of IPv6 adressen via de DHCPv6 server uitgedeeld zouden worden. Deze systemen kunnen wel via IPv6-verbinding zoeken met diensten, maar zullen altijd de DNS-resolver die via de DHCP server voor de IPv4-verbinding geconfigureerd werd nodig hebben als er geen handmatige configuratie mag plaatsvinden.
8 9 10
11 12 13 14
15
Hier is gekeken of het mogelijk is om het besturingssysteem handmatig te configureren voor een dual-stack netwerk. Op het moment dat IPv4 (handmatig) wordt uitgeschakeld ibij de netwerkconfiguratie treedt er een bug op waardoor het IPv6-adres van de geconfigureerde DNS-resolvers gecorrumpeerd wordt: http://www.tunnelbroker.net/forums/index.php?topic=878.0. Tests met een iPhone 3GS en iOS 4.2.1 op een IPv6-only access point laten zien dat de iPhone kan werken zonder IPv4-configuratie. Echter traden er tijdens het browsen soms problemen op waarbij een melding over het niet kunnen vinden van de server optrad. Opnieuw proberen zorgde er voor dat het openen van de website wel werkte. Issue voor IPv6-ondersteuning in Google Android: http://code.google.com/p/android/issues/detail?id=3389. Dit is (nog) niet opgelost in Android 2.3 (Gingerbread). Ondersteuning van RDNSS en DHCPv6 wordt voorzien voor Ubuntu 11.04 (beschikbaar in april 2011). Vereist het installeren van het pakket rdnssd. De standaard firewall blokkeert DHCPv6 antwoorden (Zie: https://bugzilla.redhat.com/show_bug.cgi?id=656334 en http://www.redhat.com/archives/anaconda-devel-list/2010-November/msg00172.html). Verder moet de IPv6verbinding op “Automatic” gezet worden in NetworkManager om DNS-resolvers door te krijgen via RDNSS dan wel DHCPv6. Als tussenoplossing zou SLAAC gebruikt kunnen worden voor de IPv6-adresconfiguratie en DHCPv4 voor het doorgeven van (IPv4) DNS-resolvers. Connectiviteit is dan wel beschikbaar via IPv6, maar is het geen “volledige” dual-stack oplossing.
8/18
6.
NAT64
Vooruitblikkend naar IPv6-only netwerken is het vrijwel zeker noodzakelijk verbinding te behouden met het IPv4-only internet. Dit is mogelijk door middel van bijvoorbeeld een NAT64-gateway. Dit als opvolger van de inmiddels achterhaald geachte NAT-PT oplossing als beschreven in RFC 2766 en teruggetrokken in RFC 4966. Het idee achter NAT64 is dat een DNS-server verzoeken voor namen waar geen AAAA-record beschikbaar is het IPv4-adres codeert in een nieuwe AAAA-record zodat nu alle DNSantwoorden een IPv6-adres bevatten. Dit IPv6 adres bevat het gecodeerde IPv4 adres in de laatste 32 bits. SURFnet heeft een NAT64-gateway die bereikbaar is via 2001:610:2001::61016. Door dit IP-adres op te nemen in de DNS-configuratie met behulp van RDNSS of DHCPv6 zullen alle systemen die deze configuratie doorkrijgen, of waarbij dit handmatig wordt ingesteld, voortaan diensten die niet (native) via IPv6 bereikbaar zijn via deze gateway proberen te bereiken. Hieronder een voorbeeld van twee websites. In het geval van www.surfdiensten.nl was er geen AAAA-record beschikbaar en wordt er een toegevoegd door de gateway. In het geval van www.surfnet.nl was er al wel een AAAA-record, die met rust gelaten wordt door de NAT64-gateway. $ host www.surfdiensten.nl www.surfdiensten.nl has address 194.171.53.6 $ host www.surfdiensten.nl 2001:610:2001::610 Using domain server: Name: 2001:610:2001::610 Address: 2001:610:2001::610#53 Aliases: www.surfdiensten.nl has address 194.171.53.6 www.surfdiensten.nl has IPv6 address 2001:610:2001:610::c2ab:3506 $ host www.surfnet.nl www.surfnet.nl has address 194.171.26.203 www.surfnet.nl has IPv6 address 2001:610:1:80e1:194:171:26:203 $ host www.surfnet.nl 2001:610:2001::610 Using domain server: Name: 2001:610:2001::610 Address: 2001:610:2001::610#53 Aliases: www.surfnet.nl has address 194.171.26.203 www.surfnet.nl has IPv6 address 2001:610:1:80e1:194:171:26:203
Een speciale manier van routeren zal er voor zorgen dat alle IPv4-adressen via deze speciale IPv6-adressen bereikbaar zijn. Een implementatie voor Linux en OpenBSD is te vinden in het Ecdysis project17. Een NAT64 gateway geeft wel problemen met sommige software, met name software die IPv4 adressen doorgeeft in de IP-pakketen zelf, bijvoorbeeld “active mode”-FTP. Veel P2P software, Skype, SIP-telefonie en bijna alle online multiplayer games als ze niet via de browser gespeeld worden vallen hieronder. Zie hiervoor ook het document waarin wordt ingegaan op tests tijdens een IETF-conferentie met een IPv6-only netwerk18.
16 Deze NAT64-gateway is alleen te gebruiken vanaf SURFnet-kantoor. 17 Zie http://ecdysis.viagenie.ca/. 18 Zie http://tools.ietf.org/html/draft-arkko-ipv6-only-experience-00.
9/18
7.
Beveiliging van IPv6-netwerken
Net als bij IPv4-netwerken zijn er lokale aanvallen mogelijk op het (V)LAN en aanvallen vanaf buiten (WAN). We zullen het hier alleen over het LAN hebben omdat de WAN situatie voor IPv6 weinig verschilt met IPv4. Op het LAN is er echter het nodige anders. Bij IPv4-netwerken moet vooral gelet moet worden op ARP-cache spoofing en rogue DHCPservers. Bij IPv6-netwerken is de situatie iets complexer.
7.1.
Neighbor Discovery
Bij IPv6 is neighbor discovery (ND) de vervanging van ARP. Er zijn verschillende typen NDpakketten, bijvoorbeeld: router advertisements (RA) en duplicate address detection (DAD). Tijdens het ontwerp van het ND-systeem is er geen rekening gehouden met het onveilige LAN, hier werden geen aanvallen op voorzien. Zie voor meer informatie section 11 “Security Considerations“ van RFC 4861 en ook RFC 3756 “IPv6 Neighbor Discovery (ND) Trust Models and Threats“. De belangrijkste aanval is waarschijnlijk de MITM-aanval 19 om verkeer om te leiden. Dit kan gedaan worden met rogue router advertisements zoals beschreven in “IPv6 Router Advertisement Guard” 20. en “Rogue IPv6 Router Advertisement Problem Statement” 21. De conclusie en oplossing volgens deze RFC: “While a number of the mitigations described above have their appeal, the simplest solutions probably lie in switch-based ACLs and RA-Guard style approaches. Where managed switches are not available, use of the Router Preference option and (more so in managed desktop environments) host firewalls may be appropriate. In the longer term wider experience of SeND will be beneficial, while the use of RA snooping will remain useful either to complement SeND (where a switch running RA Guard can potentially be a SeND proxy) or to assist in scenarios for which SeND is not deployed.” SeND is beschreven in RFC 3971, er wordt gebruik gemaakt van public key cryptography om Neighbor Discovery te beveiligen, en PKI voor Router Discovery. Helaas zijn er nog geen werkende implementaties beschikbaar voor eindstations. Cisco daarentegen heeft wel een implementatie voor hun apparatuur. Kortgezegd werkt het deel van SeND om een adres te genereren, een Cryptographically Generated Address (CGA) uit RFC 3972, als volgt: ieder station genereert een public/private keypair en gebruikt deze om via een (secure) hashing algoritme een IP-adres te genereren in de (al dan niet) geadverteerde netwerk prefix. Je kunt dus niet zelf een IP-adres kiezen (en dus niet (bewust) het IP-adres van een ander station overnemen). De uitspraak die je nu kunt doen is dat als iemand een IP-adres adverteert hij de bijhorende public/private key heeft. Om nu router advertisements te verifiëren zal er een PKI-infrastructuur moeten zijn waarbij de IPadressen van routers voorzien zijn van een (geldig) certificaat zodat alleen vertrouwde routers zich voor kunnen doen als router. Mogelijk valt dit in de toekomst te koppelen aan RPKI router certification22 (PKI voor BGP) of DNSSEC. Tools om te experimenteren met onder andere neighbor discovery en rogue router advertisements zijn te vinden in bijvoorbeeld de THC-IPV6-ATTACK-TOOLKIT 23. Om ND te monitoren is bijvoorbeeld de tool NDPMon 24 beschikbaar. Zie bijlage A voor meer informatie hierover en een testconfiguratie. 19 Man-In-The-Middle aanval: in deze aanval wordt verkeer (tijdelijk) omgeleid via een door de aanvaller gecontroleerd systeem om (ongemerkt) de communicatie te kunnen afluisteren, aanpassen of tegenhouden. 20 Zie http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard/. 21 Zie http://datatracker.ietf.org/doc/draft-ietf-v6ops-rogue-ra/. 22 Zie http://www.ripe.net/certification/. 23 Zie http://freeworld.thc.org/thc-ipv6/ en de presentatie tijdens Chaos Computer Club 27C3 conferentie op http://www.youtube.com/watch?v=c7hq2q4jQYw (2010-12-27). 24 Zie http://NDPMon.sourceforge.net/.
10/18
7.2.
DHCPv6
In zowel IPv4 als IPv6-netwerken werkt DHCP(v6) via UDP. In het geval van IPv4 via broadcast, en bij IPv6 via multicast. Dit is voor IPv4 beschreven in RFC 2131, voor IPv6 in RFC 3315. Een probleem van DHCP(v6) is dat het mogelijk is een rogue DHCP(v6)-server op zetten. Dit kan iedere systeem binnen hetzelfde (fysieke) LAN zijn. Als deze rogue server eerder reageert op DHCP(v6)-verzoeken kan dit er mogelijk voor zorgen dat eindgebruikers een verkeerde configuratie doorkrijgen. Dit kan ook onopzettelijk gebeuren door bijvoorbeeld “Internet Connection Sharing” te activeren op een eindgebruikerssysteem. Om dit op te lossen is het mogelijk DHCP(v6)-antwoorden te blokkeren en deze alleen toe te staan vanaf de “echte” DHCP(v6)-server. Dit kan op switches die een layer-3 filter hebben. Zie bijvoorbeeld “IPv6 First Hop Security—Protecting Your IPv6 Access Network” van Cisco 25. Op draadloze netwerken zal (op de controller) moeten worden ingesteld dat eindgebruikerssystemen onderling niet mogen communiceren (ook wel access point isolation genoemd). Om rogue DHCP(v6)-servers te kunnen detecteren, indien blokkeren niet kan, is er voor DHCP de tool dhcp_probe26 die gebruikt kan worden om rogue DHCP-servers te detecteren. Zover bekend bestaat deze tool (nog) niet voor DHCPv6-servers, maar lijkt niet lastig om te maken.
7.3.
Servers en eindgebruikerssystemen
Ook voor de servers en eindgebruikerssystemen op het netwerk moet rekening gehouden worden met IPv6. Indien er gebruik gemaakt wordt van firewalls (packet-filters) voor IPv4 op deze systemen moeten deze ook overweg kunnen met en geconfigureerd zijn voor IPv6. Als dit vergeten wordt zouden diensten die afgeschermd moeten zijn toch beschikbaar worden via IPv6. Op Linux systemen zal er naast iptables ook ip6tables gebruikt moeten worden. In Windows zal de (standaard) Windows firewall ook IPv6 blokkeren, maar sommige third-party firewalls, vaak geïntegreerd in beveiligingspakketten in combinatie met virusscanners, zullen dat niet doen en IPv6 negeren en ongefilterd doorlaten.
25 Zie http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_c11-602135.html. 26 Zie http://www.net.princeton.edu/software/dhcp_probe/.
11/18
8.
Identificeren Individuele Eindgebruikers
Een van de eisen op het SURFnet-netwerk is dat de eindgebruikers en systemen getraceerd moeten kunnen worden [REF] om in geval van problemen de bron te kunnen vinden. Het gaat hier dan vaak om systemen die besmet zijn met een worm en andere systemen op het internet aanvalt of spam verstuurt.
8.1.
IPv4
Een mogelijke aanpak is het “whitelisten” van netwerkapparaten die verbinding mogen maken gebaseerd op het MAC-adres van het apparaat. Hiervoor moet de eindgebruiker eerst zijn apparaat laten registeren waarbij (bijvoorbeeld) de naam van de gebruiker gekoppeld wordt aan het MAC-adres om ten alle tijden terug te vinden wie verantwoordelijk is voor dit systeem. Dit werkt eigenlijk alleen voor systemen die een bedrade verbinding hebben en op een vaste plek staan en altijd dezelfde poort op de switch gebruiken. Als er studenten zijn die allerlei apparatuur van thuis meenemen zoals laptops, netbooks, tablets, dit is erg omslachtig. Als gebruik gemaakt wordt van 802.1X op het (draadloze) netwerk is het koppelen van de gebruiker aan MAC-adres (en IP-adres) eenvoudiger. Veel draadloze accesspoints kunnen wel log-informatie naar de RADIUS-server sturen met daarin de IPv4-adressen uitgedeeld via DHCP.
8.2.
IPv6
Accesspointcontrollers die we bekeken hebben, en met 802.1X werken, registeren het IPv6 adres nog niet in de RADIUS-server. Dit komt onder andere doordat er geen DHCPv6 gebruikt wordt om de adressen uit te delen en omdat de accesspointcontrollers nog niet kunnen omgaan met IPv6. Echter, als het IPv4-adres en het MAC-adres wel gekoppeld zijn aan de gebruiker kan met de data die verkregen kan worden met het luisteren naar het Neighbor Discovery (ND) verkeer wel een tabel gemaakt worden die MAC-adres koppelt aan IPv6-adres. Hiermee is dan alle informatie aanwezig om een IPv6-adres te koppelen aan een gebruiker. Deze ND informatie kan onder andere verkregen worden met NDPMon zoals beschreven in Bijlage A.
12/18
9.
Testconfiguratie
Om tot een zo goed mogelijke IPv6-netwerkconfiguratie te komen die voldoet aan de eisen van “dual-stack” zoals eerder genoemd is gekozen voor adresconfiguratie met behulp van SLAAC, maar DNS-resolver informatie via DHCPv6. Dit zorgt er voor dat zowel de dual-stack eis gehaald wordt als dat zoveel mogelijk systemen werken met deze configuratie. Om te experimenteren met IPv6-netwerken als eerder beschreven is het mogelijk dit te doen op een bestaande router, of door een nieuwe in te richten gebaseerd op bijvoorbeeld Linux. Hieronder wordt zowel een configuratie voor Linux als Cisco gegeven.
9.1.
Linux
9.1.1.
SLAAC en RA
Hieronder staat de configuratie van de router software radvd dat beschikbaar is voor veel Linux distributies. In Mac OS X, FreeBSD, NetBSD en OpenBSD wordt gebruik gemaakt van rtadvd met weer een iets andere configuratie. Hoewel SURFnet zelf gebruik maakt van een hardware router, geeft onderstaande configuratie wel aan welke “flags” gezet moeten worden. Deze flags worden ook beschreven in RFC 2462. De configuratie voor radvd ziet er als volgt uit: interface eth0 { AdvSendAdvert on; AdvManagedFlag off; # no DHCPv6 for address configuration AdvOtherConfigFlag on; # DHCPv6 server present (for e.g. DNS-resolvers) prefix 2001:610:508:109::/64 # Advertised prefix { AdvOnLink on; AdvAutonomous on; # use SLAAC on hosts }; };
Zie voor meer informatie over de configuratie de handleiding van radvd.conf(5). Cisco heeft op zijn website ook een configuratiepagina voor een soortgelijke configuratie onder het kopje “Example: Configuring the Stateless DHCPv6 Function“ 27. 9.1.2.
DHCPv6
Om de DNS-resolvers door te geven is deze eenvoudige DHCPv6-configuratie noodzakelijk. Deze is geschreven voor ISC DHCP-server versie 4 en later (vanaf versie 4 is er IPv6ondersteuning). Hier worden dus alleen de resolvers doorgegeven, maar geen IPv6-adressen uitgedeeld, iets wat bij een “managed” configuratie wel het geval zou zijn. default-lease-time 3600; max-lease-time 7200; subnet6 2001:610:508:109::/64 { option dhcp6.name-servers 2001:610:2001::610; } 27 Zie: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html.
13/18
Het voorbeeld hierboven gebruikt het adres van de NAT64-gateway zoals besproken in hoofdstuk 6.
9.2.
Cisco IOS
In dit onderdeel wordt dezelfde configuratie gebruikt als boven voor Linux met radvd en ISC DHCP versie 4 of hoger. De voorbeeldconfiguratie hieronder is voor een Cisco 1921 met 2 gigabit ethernet interfaces. 9.2.1.
SLAAC en RA
Om SLAAC en RA te configureren is het noodzakelijk een IPv6-adres op de “LAN” interface te configureren. Dit zorgt er automatisch voor dat de Cisco router advertisements gaat zenden. Er wordt verondersteld dat dat LAN-interface GigaBitEthernet0/1 is. rtr>enable Password: rtr#configure terminal Enter configuration commands, one per line. End with CNTL/Z. rtr(config)#ipv6 unicast-routing rtr(config)#interface GigabitEthernet0/1 rtr(config-if)#ipv6 address 2001:610:fff0::1/64 rtr(config-if)#^Z rtr#
9.2.2.
DHCPv6
Om vervolgens DHCPv6 aan te zetten kunnen DNS-gegevens worden ingesteld en de DHCPv6 service op de betreffende interface worden geconfigureerd 28. rtr>enable Password: rtr#configure terminal Enter configuration commands, one per line. End with CNTL/Z. rtr(config)#ipv6 dhcp pool dhcp-pool rtr(config-dhcpv6)#dns-server 2001:610:2001::610 rtr(config-dhcpv6)#exit rtr(config)#interface GigabitEthernet0/1 rtr(config-if)#ipv6 dhcp server dhcp-pool rtr(config-if)#ipv6 nd other-config-flag rtr(config-if)#^Z rtr#
9.3.
Problemen
In dit hoofdstuk komen een aantal problemen aan bod die we zijn tegengekomen in het proces om het netwerk IPv6 “dual-stack” geschikt te maken. Sommigen komen aan het licht door bijvoorbeeld IPv4 in het eindgebruikerssysteem uit te zetten om te zien wat er nog werkt. Dit is natuurlijk geen complete opsomming van de te verwachten problemen. Problemen specifiek voor besturingssystemen werden eerder al beschreven in hoofdstuk 5. 9.3.1.
ACL issues met IPv6-verbindingen
Bij het testen van een mailserver met een hostname die zowel een A als AAAA-record had, bleek dat de ACL voor IPv6 niet goed geconfigureerd was. Een poging tot verbinden via IPv6 werd direct geweigerd. Eindgebruikers werden (zonder dit te merken) doorgestuurd naar het IPv4-adres van de server waarvoor de ACL wel correct was. Dit zorgde ervoor dat de server niet bereikbaar was over met IPv6-only verbinding, maar dit niet opviel in dual-stack mode.
28 Meer informatie over DHCPv6 kan gevonden worden op de Cisco website: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html.
14/18
9.3.2.
Beperkte beschikbaarheid over IPv6
Bij het testen van een website die promotie maakte met het feit dat deze IPv6-ready was bleek er wel een AAAA-record te zijn voor www.domein.nl, maar was men vergeten ook een AAAA-record voor images.domein.nl te maken waardoor de site wel werkte op een IPv6-only verbinding, maar er kaal uitzag.
15/18
10. Conclusie Om een “dual-stack” IPv6-netwerk uit te rollen in een organisatie en zoveel mogelijk platformen te ondersteunen is het noodzakelijk zowel stateless address autoconfiguration (SLAAC) als DHCPv6 te gebruiken waarbij de DHCPv6 gebruikt wordt om DNS-resolvers door te geven aan de eindgebruikerssystemen. Hieronder een lijst van besturingssystemen en de mate waarin ze echt “dual-stack” geschikt zijn. Als er “Ja” in de kolom “Dual-stack” staat betekent dit dat de internetverbinding blijft werken als de IPv4-verbinding (volledig) wegvalt. Als er “Nee” staat betekent dit dat nog steeds een IPv4-verbinding noodzakelijk is om met IPv6 diensten te kunnen communiceren. Hier is niet in beschouwing genomen dat het mogelijk is handmatig het systeem toch te laten werken, we gingen uit van een situatie waar de eindgebruiker niets hoeft te doen. Besturingssysteem
Versie
Dual-stack
Microsoft Windows
7
Ja
Apple Mac OS X
10.6.5
Nee
Apple iOS
4.2.1
Ja
Google Android
2.2
Nee
Linux (Ubuntu)
10.04.1
Nee
Linux (Fedora)
14
Ja
Cisco IOS
15.x
Ja
Op dit moment is het SURFnet netwerk een echt dual-stack netwerk. Als besloten wordt IPv4 uit te schakelen zullen de besturingssystemen die dual-stack zijn hiermee goed om kunnen gaan en netjes blijven werken. De lijst van dual-stack besturingssystemen is helaas nog beperkt.
16/18
11. Bijlage A - NDPMon “NDPMon is very similar to ArpWatch concerning reported activities and erroneous configurations, but it also provides new features, specific to the Neighbor Discovery protocol, for which it detects attacks, which could harm the network. Different kinds of activities can be detected” Zoals eerder genoemd is het van belang om alle aanvallen op een (lokaal) IPv6-netwerk die niet voorkomen kunnen worden te kunnen detecteren om zo tenminste te proberen de bron van de problemen te achterhalen. Dit kan lastig zijn als er geen layer-3 switch gebruikt wordt of er gebruik gemaakt wordt van draadloze netwerken waar accesspoint isolation niet geactiveerd kan worden. NDPMon kan gebruikt worden om bij te houden welke systemen zich aanmelden op het (IPv6netwerk) en welk MAC-adres en IPv6-adres daar dan bij hoort. Hieronder een voorbeeldconfiguratie van NDPMon. Hierin wordt de lokale router geconfigureerd en de prefix die hoort bij dit netwerk. Als er een andere machine in het netwerk zich voordoet als router zal dat opgemerkt worden door NDPMon en zal er (optioneel) een alert verzonden worden naar de beheerders.
17/18
1 <syslog_facility>LOG_LOCAL1 root@localhost <sendmail>1 <syslog>1 <exec_pipe_program>/usr/share/NDPMon/alerts_to_xml.py <sendmail>1 <syslog>1 <exec_pipe_program>/usr/share/NDPMon/alerts_to_xml.py <use_reverse_hostlookups>0 <mac>68:7f:74:9b:35:fc fe80:0:0:0:40e7:b9ff:feea:e1fa <param_curhoplimit>64 <param_flags_reserved>64 <param_router_lifetime>1800 <param_reachable_timer>0 <param_retrans_timer>0 <param_mtu>1500 <params_volatile>1 <prefixes> <prefix> 2001:610:508:109:0:0:0:0 <mask>64 <param_flags_reserved>192 <param_valid_time>86400 <param_preferred_time>14400 2001:610:508:109:0:0:0:1
18/18
