6to4. Teredo. IPv6-transitietechnieken. Studenten Net Twente

IPv4

6to4

IPv6

Teredo

IPv6-transitietechnieken

Studenten Net Twente

Sjoerd van den Bedem Maarten Aertsen Lennard Klein Robin Pronk Jelmer Verkleij Jorne Kandziora

1 november 2010

Inhoudsopgave

1 Inleiding 1.1 Doelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 De auteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 De vereniging SNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 5 6

2 IPv6@UT 2.1 Geschiedenis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Huidige IPv6-situatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 9

3 Theorie 3.1 Transitietechnieken . . . . . . 3.1.1 6to4 . . . . . . . . . 3.1.2 Teredo . . . . . . . . 3.2 Theoretische onderbouwing te 3.2.1 Lagere latency . . . . 3.2.2 Detectie . . . . . . .

. . . . . .

11 11 12 13 16 16 21

. . . . . . .

23 23 23 23 25 25 25 26

5 Resultaten 5.1 Detectie niet-native hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Contact met beheerders niet-native hosts . . . . . . . . . . . . . . . . . . . . . . . .

27 27 28

6 Afronding 6.1 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 30 31

A Bijlages A.1 Monitoring scripts . A.1.1 README . A.2 Daily Tunnel Report A.3 pmacctd.conf . . . .

32 32 32 34 40

4 Implementatie 4.1 Algemeen . . . . . 4.1.1 Routes . . 4.1.2 Firewalling 4.1.3 Forwarding 4.2 Monitoring . . . . 4.3 6to4-relay router . 4.4 Teredo . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . behalen doelen . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . aanzetten in de kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . 1

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . .

Dankwoord Graag willen we iedereen die heeft bijgedragen aan dit project bedanken voor zijn inzet. Met naam willen we de reviewers Pieter-Tjerk de Boer (universitair docent Universiteit Twente), Roel Hoek (netwerkbeheerder Universiteit Twente), Jeroen van Ingen Schenau (netwerkbeheerder Universiteit Twente), Bas Niesink (SNT) en Herwin Weststrate (SNT) bedanken voor hun tijd, moeite en advies. Naast de bijdrages tijdens het project zijn we ook zeer dankbaar voor de ondersteuning die de vereniging Studenten Net Twente (SNT), waaruit dit project is voortgekomen, geniet. Voor de ondersteuning met faciliteiten en materieel willen we het ICT-Servicecentrum en in het bijzonder Gert Meijerink (afdelingshoofd Infrastructuur Universiteit Twente) en Jan Markslag (teamleider netwerkbeheerders Universiteit Twente) bedanken. Als er weer een nieuw idee door het clubje gekke studenten dat SNT soms is naar voren wordt gebracht, is er beleidsruimte, stimulering en ondersteuning van deze projecten. — Sjoerd van den Bedem Maarten Aertsen Lennard Klein Robin Pronk Jelmer Verkleij Jorne Kandziora 1 november 2010

2

Voorwoord Voor u ligt het verslag over het implementeren van IPv6-tunneldiensten en het monitoren van het gebruik daarvan op de Universiteit Twente (UT). Dankzij dit project is de IPv6-connectiviteit op de UT verbeterd, en kunnen netwerkgebruikers die onnodig van de tunnel gebruik maken en dus een onnodig slechte IPv6-verbinding hebben, worden opgespoord en geholpen. Het werk is gedaan door studenten van Studenten Net Twente (SNT): een club die enerzijds het netwerk van de studentenhuisvesting op de UT onderhoudt en anderzijds ook graag experimenteert met nieuwe technieken. Zodoende hebben ze zowel contact met de netwerkbeheerders van de UT, als met mij en mijn collega’s van de leerstoel Ontwerp en Analyse van Communicatie-Systemen (DACS) van de faculteit EWI. Als docent verheugt dit project mij zeer: je kunt in de colleges nog zo vaak de noodzaak van IPv6 verkondigen, maar uiteindelijk moeten mensen er werk van maken. Deze studenten hebben dat uit eigen interesse gedaan, en daarmee een bijdrage geleverd aan de overstap op IPv6. dr.ir. Pieter-Tjerk de Boer universitair docent bij de leerstoel Ontwerp en Analyse van Communicatie-Systemen van de faculteit EWI (Elektrotechniek, Wiskunde en Informatica)

3

Hoofdstuk 1

Inleiding IPv6 is niet sexy. Het is hard maar in de ogen van de meeste technische studenten is IPv6 saai. De niet geheel wetenschappenlijk verantwoorde vergelijking met twee Google-zoekopdrachten geeft hetzelfde beeld. De zoekterm "Is ipv6 sexy? Yes!"levert 52.800 hits op terwijl de tegenhanger "Is ipv6 sexy? No!"121.000 hits oplevert. Dat IPv6 niet sexy wordt gevonden is eigenlijk ook niet zo gek. De fabrikanten van deze wereld verpakken hun technische gadgets in omslagen met mooie plaatjes, gemaakt door professionele designers. IPv6 heeft nog niet eens een gestandardiseerd logo, de RFC’s beschrijven alleen plaintext de saaie technische details. Misschien duurt de acceptatie van IPv6 daarom wel zo lang, zo zonder hip logo en 3D User-Experience om gebruikers over de streep te trekken. De sexyness van IPv6 zal misschien de komende tijd niet toenemen, de IPv6-awareness moet dat wel. Om als ICT-vereniging ons steentje aan deze awareness bij te dragen hebben we besloten aan de IPv6-awards mee te doen. Onze motivatie gaat dan ook verder dan de drang naar het winnen van een prijs. Alle deelnemers hopen kennis en ervaring op te doen, als student niet onbelangrijk voor de toekomst. Het opdoen van die kennis en ervaring is iets dat klein begint met het kweken van inzicht en begrip over de noodzaak van verandering. Je vergaart kennis over het onderwerp en komt te weten wat je kunt doen. Je verzamelt een groep mensen die je doel delen en zich willen inzetten. Je brengt je eigen organisatie in kaart en gaandeweg raken mensen op dreef. En dat allemaal voordat eventueel opgedaan enthousiasme overgedragen worden aan nieuwelingen, voor ons de volgende generatie studenten. Dit project is voor ons een mooie stap in de richting, niet alleen voor onze organisatie op de Universiteit Twente, maar met het geboden SURFnet-podium ook ver daarbuiten. Elk nieuws wat we met dit project kunnen genereren zal bijdragen aan meer bekendheid van IPv6transities. Het zal bijdragen aan de boodschap dat iedereen, zeker ook studenten, hier een rol in kunnen spelen. Daarom is dit de uitkomst van dit project, het verslag dat je nu leest, niet enkel voor de jury. We willen het in de toekomst uitbrengen als Wikibook om de IPv6-boodschap te verspreiden. Om ons steentje bij te dragen aan een kleurrijker IPv6-landschap is de voorkant van het verslag opgevrolijkt met de nodige kleuren. Waar plaatjes verduidelijkend werken hebben we deze zoveel mogelijk toegevoegd. Mocht er toch nog een grijze pagina zijn die nog een kleurtje/plaatje kan gebruiken voor uitleg, horen we het graag ter verbetering voor het Wikibook.

1.1

Doelen

Het doel van dit project is het verbeteren van de IPv6-connectiviteit van gebruikers op en buiten de campus door het verbeteren van infrastructuur voor transitietechnieken. De transitietechnieken stellen hosts op netwerken zonder IPv6 in staat om te verbinden met IPv6-hosts. De uitrol van IPv6 loopt wereldwijd helaas nog niet zo snel en soepel als velen zouden hopen. Het 4

Studenten Net Twente - IPv6-transitietechnieken einddoel van enkel native IPv6 connecties is met de huidige penetratiegraad van minder dan 0.1% voor native IPv6 in Nederland1 nog ver weg. De transitietechnieken zullen nog een lange tijd gebruikt worden. Een van de bezwaren tegen transitietechnieken is de manier waarop deze technieken een IP genereren voor een IPv4-host. Om de IPv4-host op IPv6 aan te sluiten krijgt deze een adres uit globale address pools van de transitietechnieken. Hierdoor kunnen globale adressen door middel van tunneling in lokale netwerken opduiken. Er overheersen twee visies ten opzichte van transitietechnieken: volledig negeren of volledig tegenwerken (bijvoorbeeld met de inzet van een firewall). Wij zijn van mening dat geen van beide visies de juiste weg is. De transitieperiode zal aanwezig zijn, daar is niets aan te doen. IPv4-gebruikers zullen in deze periode toch zo goed mogelijk geholpen moeten worden. Voor netwerkbeheerders betekent dit dat ook transitietechnieken zo optimaal mogelijk zullen moeten werken. Door de services nodig voor transitietechnieken op te nemen in de netwerkinfrastructuur kan de kwaliteit van de verbindingen toenemen. De internetverbindingen die gebruik maken van transitietechnieken zullen effectiever tot stand gebracht kunnen worden, waardoor latencies lager uitvallen. De kwaliteitsverbetering resulteert in snellere en stabielere verbindingen. Dit geldt voor zowel transitieverbindingen van binnen naar buiten een netwerk, als voor verbindingen van buiten naar binnen een netwerk. Naast kwaliteitsverbetering levert opname van transitietechnieken in de eigen netwerkinfrastructuur de mogelijkheid op om gebruikers hiervan te detecteren. Na detectie kan met gebruikers gekeken worden of er eventuele problemen spelen of dat er onbewust geen native IPv6 wordt gebruikt. Dezelfde detectie kan ook uitgebreid worden met logging om gebruikers te achterhalen bij abusegevallen. Ondanks het gebruik van addressen buiten de native-IPv6-space van de Universiteit kan een gebruiker van transitietechnieken met behulp van de netwerkinfrastructuur getraceerd worden naar een lokaal systeem. Hiermee kan voor een deel aan de traceerbaarheids-eis van SURFnet voldaan worden in combinatie met de eigen IPv4-administratie.

1.2

De auteurs

De auteurs zijn allen student aan de Universiteit Twente (UT) en actief lid van Studenten Net Twente (SNT). Hieronder een kort overzicht, met contactgegevens, studie en een voorbeeld van lopend of eerder afgerond project. De auteurs zijn gezamenlijk te bereiken op [email protected].

Sjoerd van den Bedem ([email protected]) student bachelor Technische Informatica vernieuwingsslag SLA’s met ruim 100 partijen 1

Maarten Aertsen ([email protected]) student bachelor Telematica hernieuwde focus op IPv6 binnen SNT

Bron: http://www.pam2010.ethz.ch/papers/full-length/15.pdf

5

Studenten Net Twente - IPv6-transitietechnieken

Lennard Klein ([email protected]) student bachelor Technische Informatica ontwerp en implementatie softwaredistributiecluster

Robin Pronk ([email protected]) student bachelor Telematica ontwerp en overgang naar SAN

Jelmer Verkleij ([email protected]) student bachelor Technische Informatica overname NNTP-infrastructuur UT

Jorne Kandziora ([email protected]) student bachelor Technische Informatica herziening diensten servermonitoring

1.3

De vereniging SNT

Alle auteurs zijn actief lid van Studenten Net Twente (SNT). SNT is een studentenvereniging geliëerd aan de Universiteit Twente (UT). SNT heeft 8500 leden waarvoor zij de belangen vertegenwoordigt op het gebied van netwerk en internet op de universiteit. Daarnaast initiëert, stimuleert en ondersteunt SNT activiteiten en diensten op het campusnetwerk van de UT. De actieve kern van 50 leden heeft een zeer brede interesse, zolang er link is met netwerken. Hieronder vallen het hosten van softwaremirrors, opzetten van een computer-registratie-systeem voor de universiteit, het schrijven van opensourcesoftware en het onderhouden van servers en hun services, zoals IRC en NNTP. Door de continue nieuwsgierigheid naar nieuwe technieken en mogelijkheden wordt veel geëxperimenteerd. Op de lange termijn blijken de projecten vaak dusdanig succesvol dat ze zich ontwikkelen tot volwassen diensten. Voorbeelden hiervan zijn het hebben van een eigen Abuse-dienst voor klachten over studentensystemen (waarbij studenten dus klachten over andere studenten afhandelen), het afhandelen van e-mail voor verenigingen en campusbewoners (in het afgelopen jaar gemiddeld 2,5 miljoen emails per maand), het beheer van de IPv6-DNS-zones voor de universiteit en het beheren en hosten van de op een na drukste Firefox-mirror (tot aan 18% van alle downloads) ter wereld. Op IPv6-gebied is de grootste activiteit het hostingplatform voor 150 studentenverenigingen dat afgelopen jaar als experiment op IPv6 is overgestapt. Hierbij zijn alle verenigingen die gebruik maken geruisloos overgeschakeld naar web- en storageservers die over native IPv6 beschikken. Hierbij is 6

Studenten Net Twente - IPv6-transitietechnieken voor storage 50% van de connecties en voor de webservers 6% over IPv6. Storage is hierbij enkel benaderbaar over het lokale campusnetwerk waar native IPv6 aanwezig is, de webservers zijn globaal benaderbaar. Veel projecten zijn mede mogelijk door de steun van het ICT-Servicecentrum van de universiteit. Deze stelt onder andere bandbreedte en beleidsruimte beschikbaar om nieuwe projecten te kunnen ontwikkelen en de huidige te vergroten. Samen met het ICT-Servicecentrum probeert SNT een zo goed mogelijk dienstenpakket te onderhouden. Voorbeelden van deze samenwerking zijn het overstappen op nieuwe VPN-software door de UT na positieve ervaring bij gebruik door SNT, maar ook het experimenteren met nieuwe mogelijkheden op het gebied van IPv6. Er wordt op het moment gekeken naar de haalbaarheid van het structureel vanuit de universiteit routeren van IPv6-subnets naar eindgebruikers om zelf te kunnen subnetten, in de gedachte van de RFC’s. Enkele studenten, waaronder drie auteurs, maken hier op dit moment gebruik van. Na zo’n kleinschalige test kan er worden gekeken naar vervolgstappen, waar de gehele populatie voordeel bij kan hebben.

7

Hoofdstuk 2

IPv6@UT 2.1

Geschiedenis

De Universiteit Twente is van oorsprong een technische onderwijsinstelling en biedt nog steeds vele technische studies aan. Daardoor probeert de Universiteit Twente natuurlijk ook op ICT-gebied vooruitstrevend te zijn en is IPv6 al snel meegenomen in de infrastructuur. Vaak zijn studenten, veelal van SNT, de drijvende kracht achter de ontwikkelingen geweest. De volgende punten geven een beknopt overzicht van de ontwikkelingen op gebied van IPv6 op de Universiteit Twente: 2000 IP-nummerplan Er wordt begonnen met een simpele indeling van de toegekende IPv6-adresruimte. 2001 IPv6-router Cisco 7513 Een Cisco 7513 wordt ingezet voor IPv6-routering. 2002 Brand datacentrum UT Veel apparatuur wordt door brand vernietigd en daarmee ook de IPv6-infrastructuur. 2003 IPv6-router Cisco 7200 Een aparte Cisco 7200 wordt ingezet voor enkel IPv6-routering naast de bestaande Cisco 6500 core-router voor IPv4. 2003 IRC-server krijgt native IPv6 De machine irc.snt.utwente.nl krijgt een native IPv6-verbinding en IPv6-software. 2004 Software-mirror krijgt native IPv6 De machine ftp.snt.utwente.nl krijgt een native IPv6-verbinding en IPv6-software. 2005 IPv6-routering over SN6 met BGP Met de komst van SURFnet6 wordt IPv6-routering met behulp van BGP ondersteund. 2007 IPv6-routering Cisco 6500 Naast IPv4-routering gaat de Cisco 6500 router ook IPv6-routeren. Dit is mogelijk geworden door een hardware-upgrade in 2006. 2008 Netflow v9, NfSen Met de komst van een nieuwe netflow versie komt IPv6-ondersteuning zodat het IPv6-verkeer beter geanalyseerd kan worden. 8

Studenten Net Twente - IPv6-transitietechnieken 2009 Google AAAA experiment De UT doet als een van de eersten mee aan een experiment van Google waardoor vele Googlediensten een AAAA-record krijgen. Hierdoor zullen veel campusgebruikers automatisch de Google diensten over IPv6 gebruiken. 2010 Experimenten Tunnelservices Door het toenemende gebruik van IPv6-transitietechnieken worden experimenten op het gebied van IPv6-tunnels gedaan om de impact in te schatten voor eindgebruikers.

2.2

Huidige IPv6-situatie

De Universiteit Twente is een echte campusuniversiteit. Onderdeel hiervan is een campusbreed netwerk dat bestaat uit een aantal onderdelen. De meest belangrijke onderdelen zijn: UTNet Dit is het volledige netwerk van de Universiteit Twente. Alle onderwijsgebouwen, datacentra, studentenwoningen op de campus en overige universiteitsgebouwen zijn hierin omvat. Campusnet De ongeveer 2000 studentenwoningen op de campus zijn verbonden met het zogenaamde campusnet. Hiermee biedt de universiteit een snelle internetverbinding voor haar studenten. Draadloos netwerk Op bijna de gehele campus is een draadloos netwerk beschikbaar. Hiermee wordt eduroam aangeboden. VPN Voor thuisgebruikers buiten de campus is er de mogelijkheid om een VPN-verbinding op te zetten. Hiermee krijgt men thuis een verbinding via de universiteit. Op alle delen van het netwerk is IPv4-connectiviteit beschikbaar. De gebruiker krijgt een globaal IP (130.89.0.0/16) toegekend en kan via de SURFnet-verbinding het internet bereiken. Op dit moment bieden vrijwel alle bedrade aansluitingen native IPv6-connectiviteit. Met router advertisements worden adressen automatisch geconfigureerd en de routes ingesteld. Aangezien multicast op het draadloze netwerk problemen veroorzaakt worden er geen router advertisements op het draadloze netwerk gedaan. Daarmee is er geen native IPv6-connectiviteit beschikbaar op het draadloze netwerk. Ook de VPNdienst biedt enkel IPv4-connectiviteit. In het geval native IPv6 niet beschikbaar is bestaan er diverse technieken om alsnog IPv6-connectiviteit te bewerkstelligen. Deze technieken worden op de UT vooral op het draadloze netwerk gebruikt. In hoofdstuk 3 Theorie zal hier verder op ingegaan worden. Momenteel verzorgt SNT de DNS-zone voor het subdomein ipv6.utwente.nl om AAAA-records aan UTNet- en campusnet-systemen toe te kennen. Daarnaast verzorgt SNT de reverse-zone voor de volledige IPv6-range. Op basis van het MAC-adres wordt automatisch het IPv6-adres gekoppeld. Het totale verkeer van de UT over de SURFnet-verbinding bestaat voor 1% uit IPv6-verkeer. Dit is flink hoger dan op veel andere netwerken, zoals bijvoorbeeld 0,1% op AMS-IX. Zie hiervoor ook figuur 2.2 Huidige IPv6-situatie en 2.2 Huidige IPv6-situatie.

9


Figuur 2.1: Totaal IPv4- en IPv6-verkeer

Figuur 2.2: Totaal IPv6-verkeer SNT probeert altijd vooruitstrevend bezig te zijn op netwerkgebied en daaronder valt IPv6. Er wordt naar gestreefd om alle diensten die aangeboden worden naast IPv4 ook over IPv6 aan te bieden. Om gebruikers hiervan gebruik te laten maken wordt er naast een regulier IPv4-specifiek A-record ook een AAAA-record voor IPv6 aan de dienst toegewezen.

10

Hoofdstuk 3

Theorie Native IPv6 is nog niet op elke locatie beschikbaar. Om toch IPv6-hosts te kunnen bereiken zijn er transitietechnieken waarmee een IPv4-client een IPv6-host kan bereiken. De meest gebruikte technieken hiervoor zijn 6to4 en Teredo. De methode die gekozen wordt om toch IPv6-connectiviteit te bereiken verschilt per besturingssysteem, bijvoorbeeld Microsoft Windows selecteert de techniek op basis van onderstaand diagram.

IPv6-connectiviteit onder Windows Vista & Windows 7

IPv6-connectiviteit gevraagd

Native beschikbaar?

Nee

6to4 Mogelijk?

Ja

Ja

Nee

Teredo Mogelijk?

Nee

Geen IPv6verbinding

Ja

Succesvol IPv6 verbonden

Figuur 3.1: Keuze voor IPv6-techniek onder Windows Vista & Windows 7 Bij alle transitietechnieken is de kwaliteit van de verbinding minder vergeleken met native. Er worden relays gebruikt die in IPv4 verpakte IPv6-pakketten uitpakken en verder sturen, evenzo worden IPv6-pakketten voor IPv4-hosts ingepakt in IPv4-pakketten en weer via IPv4 verder verstuurd. Deze relays voegen extra hops toe aan het netwerkpad. Naast de extra hops, die latency toevoegen, is traceability door netwerkbeheerders een probleem. Wat ook meespeelt is dat er geen enkele invloed is op de stabiliteit van de relays, aangezien deze meestal niet in eigen beheer zijn. De gegenereerde IPv6-IP’s komen uit globale address-pools en niet meer van lokale subnets. Het is dus zaak om zoveel mogelijk clients op native IPv6 te krijgen waardoor de transitietechnieken niet meer nodig zijn. Om gebruikers van transitietechnieken hiervan bewust te maken, zullen deze gebruikers eerst gedetecteerd en geïdentificeerd moeten worden. In eerste instantie zal uitleg gegeven worden over hoe 6to4 en Teredo werken, daarna komt het verlagen van de latency voor deze technieken aan de orde en tot slot worden methoden besproken om het gebruik ervan te kunnen detecteren.

3.1

Transitietechnieken

Zowel 6to4 als Teredo maken gebruik van tunneling. Tunneling komt neer op het encapsuleren van verkeer tussen een begin- en eindpunt, waarbij de tussengelegen hops geen notie hebben van de inhoud. 11

Studenten Net Twente - IPv6-transitietechnieken 3.1.1

6to4

In deze sectie wordt een korte samenvatting gegeven van de IPv6-transitietechniek 6to4. Er wordt ingegaan op de gebruikte adressen (de eenvoudigste manier om gebruik te herkennen) en er wordt ingegaan op de werking ervan. Het grootste voordeel van 6to4 is dat de eigen provider geen IPv6-infrastructuur aan hoeft te bieden om te kunnen verbinden met IPv6-hosts. Daar tegenover staat wel dat er ook geen actieve of passieve tegenwerking moet zijn. Onder actieve tegenwerking wordt onder ander het blokkeren van protocol type 41 (IPv6-in-IPv4) verstaan, of het null-routen van de 6to4 anycast prefix. Met passieve tegenwerking wordt het gebruik van Network Address Translation (NAT) bedoeld, zoals vaak te vinden bij thuisgebruikers. De meeste van deze apparaten gooien verkeer met niet veel voorkomende protocol types weg. Zelfs als een dergelijk apparaat niet op deze wijze filtert wordt het gebruik van 6to4 ergens beperkt. Omdat 6to4 een relatief eenvoudige transitiemethode is die, vergeleken met andere methoden, relatief weinig nadelen met zich meebrengt, heeft deze methode de voorkeur als het gaat om alternatieve IPv6-connectiviteit. Dit is terug te zien in verschillende marktproducten1 . 3.1.1.1

Adres

Elk IPv6-adres dat begint met de prefix 2002::/16 is een zogenaamd 6to4-adres. De structuur van dit adres is als volgt: +------+-------------------------------------------------+ |Prefix| | +------+-------------------------------------------------+ ^^^^^^^^ De eerste 16 bits van een 6to4-adres zijn gevuld met hexadecimaal 2002. +------+-------------+-----------------------------------+ |Prefix| Client IPv4 | | +------+-------------+-----------------------------------+ ^^^^^^^^^^^^^^^^^^^^^^ Gevolgd door 32 bits gevuld met het IPv4-adres van de client. Enkel IPv4-adressen met een globale scope zijn hier toegestaan. Dit adres wordt gebruikt door 6to4-relays om de client terug te vinden. De laatste 16 bits van de 64 bits tellende client-prefix kunnen worden gekozen door de 6to4-client om meerdere subnets te definiëren. Zoals bij elk IPv6-adres worden de laatste 64 bits gebruikt voor identificatie van hosts. 6to4 gebruikt het normale autoconfiguration-mechanisme om clients te voorzien van adressen. 3.1.1.2

Werking

Het volgende stappenschema illustreert het gebruik van 6to4 door een eindgebruiker. We gaan hier niet in op de connection-setup. 192.88.99.1 is het anycast adres dat wordt gebruikt door 6to4 relays. De magie van 6to4 zit hem, bovenop het vrij eenvoudige encapsuleren van IPv6-verkeer in IPv4, in twee zaken: 1

Bijvoorbeeld de keuze van Microsoft bij implementatie in Windows en van Apple in de Time Capsule.

12

Studenten Net Twente - IPv6-transitietechnieken Wie 1 Eindgebruiker

Van Naar IPv4-adres gebruiker 192.88.99.1

Wat Pakt IPv6-verkeer in en stuurt ingepakt over IPv4 IPv6-adres doel Pakt IPv4-verkeer uit en stuurt inhoud (IPv6-verkeer) door 6to4-adres gebruiker Ontvangt IPv6-verkeer van gebruiker en reageert zoals normaal over IPv6 IPv4-adres gebruiker Pakt IPv6-verkeer in en stuurt ingepakt over IPv4

2 6to4-relay

6to4-adres gebruiker

3 Doel

IPv6-adres doel

4 6to4-relay

192.88.99.1

Elke regel stelt een pakket voor dat verstuurd wordt door de host ’Van’ naar de host ’Naar’. ’Wat’ geeft aan wat de inhoud van het pakket is. Tabel 3.1: Stappenschema 6to4client

• De 6to4-relays in de verschillende stappen in het schema zijn niet noodzakelijkerwijs dezelfde: er wordt gebruik gemaakt van anycast, waarmee telkens de dichtstbijzijnde 6to4- relay wordt bereikt. • Elke 6to4-relay weet raad met de traffic die hij krijgt, omdat in het 6to4-adres het IPv4-adres van de client zit geëncodeerd. 3.1.2

Teredo

In deze sectie wordt een korte samenvatting gegeven van de IPv6-transitietechniek Teredo. Er wordt ingegaan op de gebruikte adressen (de eenvoudigste manier om gebruik te herkennen) en er wordt ingegaan op de werking. Eerder in dit hoofdstuk werd ingegaan op de rol van 6to4 bij het ontbreken van native IPv6ondersteuning door een provider. Er werden een aantal randvoorwaarden geschetst die gebruik van 6to4 mogelijk maakte. Dit roept de vraag op of het nog steeds mogelijk is om IPv6-connnectiviteit bij de thuis gebruiker te brengen als de provider en/of de apparatuur thuis niet aan de voorwaarden voldoen. Hier komt Teredo in beeld. Het grote voordeel van Teredo is dat het te gebruiken is op het moment dat een provider actief protocol type 41 filtert, of de 6to4-anycast prefix null-routeert. Ook met de passieve tegenwerking van NAT (zoals eerder genoemd in de sectie over 6to4) is rekening gehouden in het ontwerp van Teredo. Door gebruik te maken van tunneling in UDP is er geen probleem met de meeste consumentenapparatuur die filtert op onbekende protocollen. En om het welbekende NAT-probleem, het niet bereikbaar zijn voor externe hosts zonder expliciete port-forwarding, te omzeilen wordt er gebruik gemaakt van een mechanisme om verkeer over een opengehouden poort via een relay te ontvangen. Door al deze extra foefjes is Teredo als protocol complexer dan 6to4. Dit brengt extra nadelen met zich mee. IPv6-connectiviteit met behulp van Teredo wordt daarom vooral gebruik als laatste fallback. Pas als native IPv6-connectiviteit niet beschikbaar is en het opzetten van 6to4 ook niet mogelijk is, wordt Teredo geprobeerd. De reden hiervoor is dat Teredo, nog meer dan 6to4, een kwalitatief mindere verbinding oplevert. Dat is nog altijd beter dan geen verbinding, er dus wel degelijk bestaansrecht. Teredo is ontwikkeld en als eerste geïmplementeerd door Microsoft. Het is terug te vinden vanaf Windows Vista en wordt voornamelijk gebruikt op het moment dat er een geforceerde verbinding wordt

13

Studenten Net Twente - IPv6-transitietechnieken gemaakt naar een IPv6-host (bijvoorbeeld door het invoeren van een IPv6-literal in een browser) en er geen beschikking is over betere alternatieven. 3.1.2.1

Adres

Teredo-verkeer is te herkennen aan de de prefix 2001::/32. In deze sectie wordt stap voor stap toegelicht hoe een Teredo-adres is opgebouwd. +-------------+------------------------------------------+ | Prefix | | +-------------+------------------------------------------+ ^^^^^^^^^^^^^^^ De eerste 32 bits van een Teredo-adres bestaan uit hexadecimaal 2001 0000. +-------------+-------------+----------------------------+ | Prefix | Server IPv4 | | +-------------+-------------+----------------------------+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Daarna volgen 32 bits met het IPv4-adres van de Teredo server. De volgende 16 bits bevatten zogenaamde flags. Hier wordt in dit document niet op ingegaan. +-------------+-------------+-------+------+-------------+ | Prefix | Server IPv4 | | Port | Client IPv4 | +-------------+-------------+-------+------+-------------+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ De laatste 48 bits bestaan uit een 16-bits portnummer en 32-bits voor het IPv4-adres van de client. De waarden in de poorten IP-velden worden geïnverteerd alvorens ze in het adres worden meegenomen. Dit maakt het lezen van IPv4-adressen uit een Teredo-IPv6-adres lastiger. Daarnaast krijgt een client bij Teredo, in tegenstelling tot bij 6to4, niet een adresblok, maar een enkel adres. Je zult op een netwerk dus niet snel router advertisments tegenkomen binnen de Teredo-prefix. 3.1.2.2

Werking

Teredo bevat ten opzichte van 6to4 een extra entiteit. Er is niet alleen sprake van een relay, die geencapsuleerd verkeer uitpakt, er is ook nog een zogenaamde server, die de optimale relay voor een bepaald doel kiest. In deze sectie wordt allereerst de interactie met de server beschreven, waarbij een relay wordt gevonden. Daarna wordt de communicatie met het doel, via deze relay, beschreven. Bij het vinden van een geschikte relay voor communicatie met het doel wordt gebruikgemaakt van een Teredo-server. De server is statische ingesteld in de client. Bij Windows-machines zijn dit bijvoorbeeld Teredo-servers van Microsoft. Het ’IPv4-adres server’ in het voorbeeld hieronder is dus een van te voren ingesteld adres. In ons voorbeeld gaan we niet in op de connection-setup met de server waarbij de client zijn adres krijgt. Dit valt buiten de scope van dit document. De relay die wordt gebruikt in stap 4 krijgt al het verkeer met bestemmingen in het Teredo-adresblok naar zich toe gerouteerd. Omdat het hier gaat om anycast bereiken we die relay die zich het dichtst bij het doel bevindt. De relay stuurt het ICMP6 ECHO REPLY pakket terug naar de gebruiker, verpakt het in UDP over IPv4 en geeft daarmee zijn eigen locatie door (het IP-pakket bereikt immers de client, 14

Studenten Net Twente - IPv6-transitietechnieken Wie 1 Eindgebruiker 2 Server 3 Doel

4 Relay

Van IPv4-adres gebruiker

Naar IPv4-adres Server

Wat ICMP6 ECHO-pakket ingepakt in UDP Teredo-adres gebruiker IPv6-adres doel Pakt UDP-verkeer uit en stuurt inhoud (IPv6-verkeer) door IPv6-adres doel Teredo-adres gebruiker Ontvangt ICMP6 ECHOpakket van gebruiker en reageert zoals normaal over IPv6 IPv4-adres relay IPv4-adres gebruiker Pakt ICMP6 ECHO REPLY in en stuurt ingepakt over UDP

Elke regel stelt een pakket voor dat verstuurd wordt door de host ’Van’ naar de host ’Naar’. ’Wat’ geeft aan wat de inhoud van het pakket is. Tabel 3.2: Stappenschema Teredo connectie-setup

die het source-adres kan zien). De client heeft hiermee de dichtstbijzijnde Teredo-relay bij zijn doel gevonden. Het volgende stappenschema illustreert het gebruik van de gevonden Teredo-relay door een eindgebruiker om te communiceren met het doel. Wie 1 Eindgebruiker 2 Relay

3 Doel

4 Relay

Van IPv4-adres gebruiker

Naar IPv4-adres relay

Wat Pakt IPv6-verkeer in en stuurt ingepakt over UDP Teredo-adres gebruiker IPv6-adres doel Pakt UDP-verkeer uit en stuurt inhoud (IPv6-verkeer) door IPv6-adres doel Teredo-adres gebruiker Ontvangt IPv6-verkeer van gebruiker en reageert zoals normaal over IPv6 IPv4-adres relay IPv4-adres gebruiker Pakt IPv6-verkeer in en stuurt ingepakt over UDP

Teredo bevat ten opzichte van 6to4 nog een aantal extra slimmigheden: • Verkeer wordt niet direct in IPv4 verpakt, maar in UDP en daarna in IPv4. • Per connectie wordt de optimale relay gevonden, wat latency verlaagt. • De gebruikte Teredo-relay is voor de duur van de connectie met een bepaald doel gelijk. • Elke Teredo-relay weet raad met de traffic die hij krijgt, omdat het Teredo-adres zowel het IPv4adres als het openstaande poortnummer van de client bevat. Op deze manier is een host achter NAT toch bereikbaar.

15


3.2

Theoretische onderbouwing te behalen doelen

Met de IPv6-tunnelservices willen we een lagere latency voor en detectie van hosts die transitietechnieken gebruiken bewerkstelligen. Om te voorkomen dat de theoretische besprekingen te veel over randzaken gaan, gaan we uit van een symmetrisch datapad tussen source en destination van een verbinding. Verkeer van de source naar de destination gaat dus over hetzelfde pad als het return-verkeer van destination naar source. Naast een symmetrisch datapad wordt ook aangenomen dat extra hops in een pad latency veroorzaken. Anders dan zuiver theoretisch heeft een pad tussen twee hops altijd een doorlooptijd groter dan 0µs. Een connectie tussen twee native IPv6-hosts zal doorgaans over het kortste pad gaan. Elke hop extra die nodig is voor een transitie van IPv4 of IPv6 veroorzaakt dan een omweg. Omdat de kortste route meestal enkel over core-routers gaat, die geen transities uitvoeren, zal zelden de transitie op een van de hops op de kortste route plaatsvinden. Bij transities zal dus vertraging optreden. 3.2.1

Lagere latency

Gebruikers die geen native IPv6 gebruiken maar toch IPv6-hosts willen bereiken kunnen gebruik maken van transitietechnieken. Hierbij wordt vanaf de IPv4-host (A) contact gezocht met een ”vertaler” (relay) om IPv6-host (B) te bereiken. Deze relay die IPv4 omzet in IPv6 en vice-versa ligt zelden op het optimale pad tussen A en B wat gebruikt zou kunnen worden als A native IPv6 had gebruikt. Pakketten van A naar B en terug moeten de omweg door de ”vertaler” maken. Hoe dichter de ”vertaler” bij het optimale pad tussen A en B ligt hoe minder de pakketten om hoeven te reizen. 3.2.1.1

Latency-verbetering 6to4-hosts vanaf het internet naar de campus

Een 6to4-client op het internet (host A) maakt gebruik van een 6to4-relay om te verbinden met IPv6hosts op het campusnet (host B). Op de terugweg van B naar A wordt ook gebruik gemaakt van een 6to4-relay. Het complete pad bestaat uit de paden A → ”relay van A” → B → ”relay van B” → A. Dit complete pad is optimaal als de relay voor A zich op de snelste route van A naar B bevindt en de relay voor B zich op de snelste route van B naar A bevindt. Omdat we geen invloed hebben op de keuze van de ”relay van A” concentreren we ons op het verbeteren van de positionering van de relay van B op het pad van B naar A. De 6to4-relay die door B wordt gebruikt bij het zenden van verkeer naar A is de 6to4-relay die het dichtst bij B ligt. Door de relay van B zo dicht mogelijk bij B te plaatsen proberen we het optimale pad zo dicht mogelijk te benaderen. Dit kan, omdat we directe invloed hebben op de eerste router van host B.

16


6to4-latencyvoordeel

Legenda

Client A

Internet connection Normal route

Client netwerk

6to4 relay router

Universiteit Twente

UTNet

Host B

6to4 relay router

Figuur 3.2: Standaard 6to4-connectiviteit

17


6to4-latencyvoordeel

Legenda

Client A

Internetconnectie Verbeterde route

Client netwerk

6to4 relay router

Universiteit Twente

UTNet

6to4 relay router

Host B

6to4 relay router

Figuur 3.3: Verbeterde 6to4-connectiviteit door middel van een lokale relay

18

Studenten Net Twente - IPv6-transitietechnieken 3.2.1.2

Latency-verbetering Teredo-clients door relay binnen eigen netwerk

Een Teredo-client op het internet (host A) maakt gebruik van een Teredo-relay om te verbinden met een IPv6-host op de campus (host B). De terugweg van B naar A maakt gebruik van diezelfde Teredorelay. Het complete pad bestaat dus uit de paden A → Teredo-relay → B → Teredo-relay → A. Dit complete pad is optimaal als de Teredo-relay zich zowel op de snelste route van A naar B als op de snelste route van B naar A bevindt. We concentreren ons op het verbeteren van de positionering van de Teredo-relay. De Teredo-relay die zowel door source als destination wordt gebruikt bij het zenden van traffic, is de Teredo-relay die het dichtst bij de destination ligt. Door de Teredo-relay zo dicht mogelijk bij B aan te bieden vergroten we de kans dat deze op het optimale pad ligt.

Teredo-latencyvoordeel

Legenda Internetconnectie Normale route

Client A

Client netwerk Teredo server

Universiteit Twente

UTNet

Host B

Teredo relay

Figuur 3.4: Ongewenste situatie voor Teredo

19



Legenda Internetconnectie Verbeterde route

Client A

Client netwerk

Teredo server

Universiteit Twente

UTNet

Teredo relay

Host B Teredo relay

Figuur 3.5: Gewenste situatie voor Teredo

20


Detectie

In ons campusnetwerk heeft elke host de beschikking over native IPv6-connectiviteit. Geen enkele host zou dus een transitietechniek hoeven te gebruiken. Daar native IPv6 de best mogelijke verbinding geeft willen we gebruikers vertellen dat ze hun verbinding kunnen verbeteren. Om inzicht te krijgen welke hosts transitietechonologieën gebruiken willen we deze automatisch kunnen detecteren. 3.2.2.1

Detectie van 6to4-hosts op de campus

6to4-clients zetten verbindingen op via relays zoals uitgelegd in 3.2.1.1 Latency-verbetering 6to4-hosts vanaf het internet naar de campus. Op deze relays kunnen de connecties die opgezet worden gelogd worden voor analyse. Om te kunnen beschikken over logging zonder afhankelijk te zijn van externe partijen zullen we zelf een relay moeten beheren. Zoals eerder vermeld kiezen de source en destination ieder een eigen relay. Zelf zullen we een relay beheren die voor elke 6to4-connectie van of naar de campus door hosts op de campus gebruikt zal worden. Voor campus-hosts is onze relay immers de dichtstbijzijnde en zal dus door zowel campus-6to4-clients als campus-IPv6-servers die communiceren met 6to4-clients gebruikt worden. We zijn geïnteresseerd in de detectie van lokale 6to4-clients. De clients genereren IPv4-verkeer naar onze relay voor alle connecties. We kunnen de clients dus detecteren door bij te houden wie er via IPv4 connect. Alle IPv6-servers op de campus gebruiken de 6to4-relay voor return-verkeer naar 6to4-clients. Het IPv6-verkeer levert ons dus niet meer informatie over lokale 6to4-clients op. Na de identificatie van campus-6to4-clients kan er verdere communicatie met gebruikers plaatsvinden middels de Servicedesk. Door middel van de computeradministratie van de instelling kan uit het IP de gebruiker achterhaald worden via het MAC-adres. 3.2.2.2

Detectie van Teredo-hosts op de campus die communiceren met IPv6-hosts op de campus

Teredo-clients zetten verbindingen op via relays zoals uitgelegd in 3.2.1.2 Latency-verbetering Teredoclients door relay binnen eigen netwerk. Op deze relays kunnen de connecties die opgezet worden gelogd worden voor analyse. Om te kunnen beschikken over logging zonder afhankelijk te zijn van externe partijen zullen we zelf een relay moeten beheren. Zoals eerder vermeld wordt een relay gekozen op basis van de destination. Zelf zullen we maar één van de vele relays wereldwijd beheren: de relay die gekozen wordt om met Teredo naar een campus-IPv6-host te verbinden. Onze Teredo-relay is immers de dichtsbijzijnde Teredo-relay bij de destination, de IPv6-host. Hoewel we graag alle Teredo-clients op de campus detecteren kunnen we slechts een klein deel van het Teredo-verkeer op onze Teredo-relay zien. Teredo-verkeer met een bestemming buiten de campus wordt door andere relays dan de onze afgehandeld. Enkel het verkeer van Teredo-clients met een bestemming binnen de campus verloopt via de door ons beheerde relay. Dit intra-campus verkeer is het gedeelte dat we willen monitoren om de Teredo-clients te identificeren. Er gaan een aantal stappen vooraf voordat de Teredo-relay Teredo-clients detecteert. Een overzicht van de stappen voor een Teredo-connectie en wanneer de relay de client detecteert staat in figuur 3.6. Het intra-campus verkeer neemt steeds verder toe naarmate steeds meer instellingsdiensten ook op IPv6 wordt aangeboden. De gebruikersgroep zal dan ook steeds verder toenemen in de toekomst. Na de identificatie van Teredo-hosts op de campus kan er verdere communicatie met gebruikers plaatsvinden middels de Servicedesk. Door middel van de computeradministratie van de instelling kan uit het IP de gebruiker achterhaald worden via het MAC-adres. 21


Lokale Teredo-clientdetectie

Legenda Internetconnectie IPv4-connectie IPv6-connectie

Client netwerk

2

Teredo client

1 2

1

Teredo server

Universiteit Twente

UTNet Host A (teredo)

Host B

2 1 6

5

3

4 Teredo relay

1 2 3 4

Transport IPv4 IPv6 IPv6 IPv4

5 IPv4 6 IPv6

Teredo relay

Beschrijving A stuurt ping naar de server met als eindbestemming B Server stuurt ping naar B door B stuurt antwoord naar Teredo-adres A (Teredo-adresblok komt uit bij relay) Teredo-relay encapsuleert antwoord B en stuurt deze door naar A A weet nu de relay om B te bereiken A communiceert met B via relay (de relay weet nu dat A een Teredo-client is) B communiceert met A via relay Figuur 3.6: Lokale Teredo-client-detectie

22

Hoofdstuk 4

Implementatie 4.1

Algemeen

Alle benodigde software kan op één machine draaien. Voor dit project is gekozen voor een machine met Debian Linux. Van Debian is bekend dat alle benodigde software aanwezig is. Tevens is dit een vertrouwde omgeving voor de projectleden. In principe moeten andere besturingssystemen zonder grote problemen dezelfde diensten kunnen draaien. Deze beschrijving van onze implementatie gaat echter uit van Debian Linux. Voor het netwerk wordt uitgegaan van een core-router die al het uitgaande verkeer verwerkt. Deze kan IPv4- en IPv6-routes routeren naar de relay-machine. 4.1.1

Routes

Omdat we zelf multicast-verkeer willen verwerken zijn er een aantal IPv4- en IPv6-routes nodig die naar de machine verwijzen. In onderstaande tabel een overzicht hiervan, met daarin voor elke route aangegeven voor welk onderdeel het nodig is. Route Technologie Detectie Optimalisatie latency 192.88.99.1/24 6to4 Ja Ja 2002::/16 6to4 Nee Ja 2001::/32 Teredo Ja Ja Deze routes moeten op de core-routers naar de relay gerouteerd worden. De relay verstuurt pakketten na hun IP-transitie weer terug over de core-routers naar hun eindbestemming. 4.1.2

Firewalling

Indien de diensten enkel voor het eigen netwerk bedoeld zijn kunnen deze met een aantal firewallregels worden afgeschermd voor de buitenwereld. Hieronder staat beschreven hoe een firewall-regel kan zorgen dat alleen het eigen netwerk (in dit geval connecties van en naar het netwerk van de Universiteit Twente) gebruik kan maken van de diensten. 4.1.2.1

6to4

Bij 6to4 kunnen twee verkeersstromen aangepakt worden: • Het in IPv4 ingepakte IPv6-verkeer dat binnenkomt vanaf de ’lokale’ clients en het native IPv6net op moet

23

Studenten Net Twente - IPv6-transitietechnieken • Het verkeer dat van lokale IPv6-machines komt wat ingepakt moet worden voor externe clients. In iptables (de Linux firewall) notatie zien de regels voor de eerste stroom er als volgt uit: /sbin/iptables -t filter -A INPUT --protocol IPv6 --in-interface eth0 --source 130.89.0.0/16 --jump ACCEPT /sbin/iptables -t filter -A INPUT --protocol IPv6 --jump DROP

Hierbij kan ook een destination-adres (meestal 192.88.99.1 en het lokale ip-adres) opgegeven worden indien nodig. Dit kan relevant zijn indien bijvoorbeeld ook statische IPv6-in-IPv4-tunnels op de machine aanwezig zijn. Voor de tweede stroom gelden de regels: /sbin/ip6tables -t filter -A FORWARD --in-interface 6to4 --source 2002:8259:0000::/32 --jump ACCEPT /sbin/ip6tables -t filter -A FORWARD --in-interface eth0 --source 2001:610:1908::/48 --out-interface 6to4 --jump ACCEPT /sbin/ip6tables -t filter -A FORWARD --policy DROP

• Regel 1 Door de opbouw van 6to4-addressen (zie 3.1.1.1 Adres) begint het source-netwerk met 2002 met de IPv4-range in hex-notatie.1 • Regel 2 Het lokale IPv6-netwerk is opgegeven als source. • Bovenstaande regels gaan er van uit dat de machine geen ander IPv6-verkeer forwardt. 4.1.2.2

Teredo

Het filteren van Teredo is een stuk lastiger dan 6to4. Vanwege de opbouw van het pakket en de werking van de technologie in het algemeen is hier de beste mogelijkheid om te kijken naar de pakketten door de Teredo relay mogen gaan. Voor het opzetten van de connectie komen ICMP-echo pakketten langs die bij 6to4 al via bovenstaande firewall-rules afgevangen worden. Voor native zal ICMP ook nog afgevangen moeten worden op de Teredo interface. /sbin/ip6tables /sbin/ip6tables /sbin/ip6tables /sbin/ip6tables /sbin/ip6tables

-t -t -t -t -t

filter filter filter filter filter

-A -A -A -A -A

FORWARD FORWARD FORWARD FORWARD FORWARD

--in-interface --in-interface --in-interface --in-interface --policy DROP

teredo --destination 2001:610:1908::/48 --jump ACCEPT teredo --destination 2002:8259:0000::/32 --jump ACCEPT teredo --jump ACCEPT eth0 --source 2001:610:1908::/48 --out-interface teredo --jump ACCEPT

• Regel 3 Deze regel zonder destination-filter is toegevoegd om te voorkomen dat verkeer van een Teredo-source naar een lokale Teredo-destination gefilterd wordt. Er kan op deze regel matching worden gezet kijkt naar de geïnverteerde laatste 32 bits van een Teredo-client 2 . De uitleg voor deze gecompliceerde matching gaat echter te ver voor dit document. • 6to4-verkeer wordt al geaccepteerd in de iptables-regels voor de tweede verkeersstroom van 6to4. 1 Het omrekenen van het decimale IPv4-adres naar hex-notatie kan op http://www.IPv6calculator.net/. Het netmask kan met de vuistregel ’IPv4-CIDR-grootte + 16’ verkregen worden (130.89.160.0/20 wordt dus 2002:8259:A000::/36). 2 Zie voor meer informatie http://msdn.microsoft.com/en-us/library/cc136764(VS.85).aspx.

24


Forwarding aanzetten in de kernel

In de Linux-kernel moet forwarding voor IPv6 aangezet worden. Zowel voor de Teredo als 6to4 service moet dit gedaan worden. Al het IPv6-gerelateerde IPv4-verkeer is voor de host zelf bestemd, IPv4forwarding hoeft dus niet aangezet te worden. Let wel op, dat de Linux-kernel met het aanzetten van IPv6-forwarding IPv6 autoconfiguration uitzet. Mogelijk moet zelf een IPv6-adres geconfigureerd worden om het verkeer naartoe te routeren. Dit kan het link-local-adres zijn. sysctl -w net.ipv6.conf.default.forwarding=1 sysctl -w net.ipv6.conf.all.forwarding=1 Om deze wijzigingen permanent te maken, zodat de instellingen ook bij een systeemherstart behouden blijven, is over het algemeen het volgende in /etc/sysctl.conf plaatsen afdoende: net.ipv6.conf.default.forwarding=1 net.ipv6.conf.all.forwarding=1

4.2

Monitoring

Voor het verkijgen van een lijst met hosts die gebruik maken van onze relay gebruiken we het programma pmacct3 . pmacct is een collectie monitoring tools om IPv4- en IPv6-verkeer inzichtelijk te maken. We maken slechts gebruik van een klein deel van de mogelijkheden van dit pakket. pmacctd luistert (vergelijkbaar met tcpdump) direct op de interface en houdt in zijn geheugen bij welke IP-adressen het heeft gezien. Vervolgens lezen periodieke scripts deze data uit voor verdere verwerking. De verdere verwerking vindt plaats via twee paden. Voor het creeëren van grafieken zijn Muninplugins geschreven. Hiermee verwerven we kwantitatief inzicht. Voor kwalitatief inzicht wordt iedere dag een mail verstuurd met de gedetecteerde IP’s en een vermelding wanneer deze voor het eerst zijn waargenomen (een zogenaamd Daily Tunnel Report). De configuratie van pmacct is the vinden in bijlage A.3 pmacctd.conf, de monitoringscripts staan in A.1 Monitoring scripts. Een voorbeeld van een Daily Tunnel Report is te vinden in A.2 Daily Tunnel Report.

4.3

6to4-relay router

Voor 6to4 moet verkeer voor 192.88.99.1 geaccepteerd worden, wat de kernel alleen doet als het IPadres ergens op een interface geconfigureerd is. Het is gebruikelijk vanaf de routerende netwerk-core het verkeer direct naar de machine te routeren. Hierdoor hoeft 192.88.99.1 niet actief te zijn op een specifieke interface of ervoor op ARP-requests te antwoorden. Wel zal het op bijvoorbeeld een loopback-interface aanwezig moeten zijn. Het aanbrengen van het adres op de loopback-interface kan als volgt in /etc/network/interfaces: auto lo iface lo inet loopback up ip addr add 192.88.99.1/32 dev lo down ip addr del 192.88.99.1/32 dev lo 3

http://www.pmacct.net/

25

Studenten Net Twente - IPv6-transitietechnieken Voor het niet reageren op ARP-requests op de overige interfaces kan het volgende in /etc/sysctl.conf geplaatst worden. Dit is geen vereiste, maar kan voor specifieke netwerk-setups nodig zijn. net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.default.arp_announce = 2 Voor het aanmaken van de interface die het daadwerkelijke omzetten van IPv4 ↔ IPv6 doet plaatsen we het volgende in /etc/network/interfaces: auto 6to4relay iface 6to4relay inet6 v4tunnel address 2002:8259:9590::1 netmask 16 local 192.88.99.1 endpoint any up ip route add 2002::/16 dev $IFACE down ip route del 2002::/16 dev $IFACE up ip addr add 2002:c058:6301::c058:6301/128 dev $IFACE down ip addr del 2002:c058:6301::c058:6301/128 dev $IFACE up ip addr add 2002:c058:6301::1/128 dev $IFACE down ip addr del 2002:c058:6301::1/128 dev $IFACE up ip addr add 2002:c058:6301::/128 dev $IFACE down ip addr del 2002:c058:6301::/128 dev $IFACE De addressen beginnend met 2002:c058:6301 zijn de IPv6-varianten van het IPv4-6to4-anycast adres 192.88.99.1. Een exacte specificatie welke adressen gebruikt worden is niet bekend. Sommige adressen komen voor in RFCs maar lijken niet gebruikt te worden, anderen zijn gezien op live-clients als relay-adres. Tot slot moet de opmerking gemaakt worden dat de relay-router uitgaande pakketten zal sturen met als IPv4-source-adres 192.88.99.1. Deze pakketten moeten aan de edge van het netwerk dus niet gefilterd worden.

4.4

Teredo

Teredo maakt voor het IPv4-verkeer gebruik van willekeurige UDP-poorten. Deze moeten dus niet gefirewalled zijn. De installatie van een Teredo-relay is vrij eenvoudig dankzij het Miredo-project4 : aptitude install miredo Hierna moet /etc/miredo.conf aangepast worden zodat de enige regel luidt: ”RelayType cone”. Daarna voldoet een Miredo herstart om de Teredo-relay live te hebben: /etc/init.d/miredo restart

4

http://www.remlab.net/miredo/

26

Hoofdstuk 5

Resultaten 5.1

Detectie niet-native hosts

Na het opzetten van een 6to4- en Teredo-relay is de detectie van start gegaan. Detectie van 6to4 heeft al duidelijke resultaten opgeleverd die hieronder getoond en besproken worden. Vanwege de beperkte tijd en de vele mogelijke valkuilen is er geen latency-benchmark en -test uitgevoerd. Helaas is voor Teredo nog geen route door het ICT-Servicecentrum (Universiteit Twente) ingesteld die Teredo-subnets naar onze relay stuurt. Dit zal later ingesteld worden. Om toch Teredo-verkeer binnen te krijgen routeert het release-cluster van SNT (onder andere de nummer 2 Firefox-mirror van de wereld) al het Teredo-verkeer handmatig over de eigen Teredo-relay. Hierdoor zien we wel niet-campus hosts die gedetecteerd worden, maar helaas geen intra-campus verkeer. De dagelijkse output van de detecties met een lijst van individuele hosts is te zien in bijlage A.2 Daily Tunnel Report.

Figuur 5.1: 6to4 connecties per week

Het verloop van de week is duidelijk terug te zien in de grafieken. De doordeweekse dagen vertonen flinke pieken (vooral in de WLAN-range) vanwege de grote hoeveelheid studenten die midden op de dag op de campus aanwezig is. In het weekend zijn kleinere pieken te zien daar er dan bijna enkel campusbewoners aanwezig zijn op de campus. De VPN-groep is elke dag vrijwel stabiel (ook in het weekend) omdat deze niet locatie-afhankelijk is. De twee grootste groepen in de resultaten zijn WLAN en VPN. Beide groepen zijn op dit moment om technische redenen qua IPv6-mogelijkheden helaas beperkt tot transitietechnologieën. Deze sys27


Figuur 5.2: 6to4 connecties op een rustige zondag temen maken legitiem gebruik van 6to4 en hebben niet onze voornaamste interesse. Campusnet en Overig hebben echter wel de native mogelijkheid en kunnen gewezen worden op native IPv6. Binnen de range Campusnet is elke dag een vaste groep hosts in de resultaten terug te vinden. Middels de eigen IP → MAC → gebruiker administratie van de UT kunnen deze opgespoord en aangesproken worden. Dit beleid kan door de Servicedesk actief uitgevoerd worden voor zowel mobiel.utwente.nl hosts als statische adressen daar er administratie van beide bestaat. De vaste (statische) adressen binnen deze range is een groep van enkele tientallen. De gedetecteerde mobiele adressen lopen in de honderden. Een over de campus bewegende host kan meerdere detecties op mobiel.utwente.nl veroorzaken. Verdere analyse met de UT administratie van registraties zal hier uitsluitsel over moeten geven. De Overige range is binnen onze huidige resultaten vrij divers. Natuurlijk zouden we deze groep verder kunnen opsplitsen, maar binnen de grafieken zou dit geen verder overzicht opleveren, omdat het in totaal toch om redelijk kleine aantallen gaat. Deze range valt op te delen in de volgende categorieën: • Mobiele adressen op andere locaties (bijv. het watersportcomplex buiten de campus) • ADSL abonnees en andere exotische aansluitingen op de Campus • Machines van faculteiten/diensten van de universiteit Voor mobiele adressen op andere locaties, ADSL abonnees en vergelijkbare aansluitingen kan de eigenaar worden achterhaald op dezelfde manier als bij ’normale’ mobiele adressen. Bij machines die behoren tot onderdelen van de universiteit (faculteiten, instituten en diensten) kan de beheerder van de betreffende instantie op de hoogte worden gesteld van deze machines; het is verder aan deze beheerder om de nodige vervolgstappen te nemen.

5.2

Contact met beheerders niet-native hosts

Om te bezien of beheerders op de campus bewust 6to4 gebruiken, en zo ja wat de motivatie hierachter is, zijn een aantal beheerders gebeld. De beheerders zijn hierbij achterhaald via de instellingsadministratie: IP → MAC → gebruiker → telefoonnummer. Het ging hierbij enkel om een steekproef om een snel beeld te vormen of 6to4 bewust wordt gebruikt.

28

Studenten Net Twente - IPv6-transitietechnieken De 10 gebelde beheerders gaven aan dat alle hosts Windows 7 gebruikten. Dit kan toeval zijn, maar het is apart dat Windows 7 met een marktaandeel van ongeveer 20% wereldwijd 1 alle hosts uit deze steekproef levert. Van deze Windows 7-hosts had de helft IPv6 als protocol uitgevinkt staan. Verder onderzoek is gewenst om de redenen hiervoor te achterhalen. Geen van de beheerders was zich bewust van het gebruik van 6to4. Wel gaf de helft aan in het vervolg te denken aan native IPv6-gebruik als er specifiek gebruik van IPv6-diensten wordt gemaakt. Het wordt niet duidelijk of er voldoende know-how bij de individuele beheerders aanwezig is om dit daadwerkelijk uit te voeren. Naast de detectie van laptops en pc’s van studenten zijn er ook verschillende workstations van medewerkers en twee routing servers van het ICT-Servicecentrum van de UT gedetecteerd. De workstations bleken uitgerust met VMware systemen voor testdoeleinden en de routing-servers zijn UT VPN-gateways die zich in een segment zonder native IPv6 bevinden.

1

Bron: http://arstechnica.com/microsoft/news/2010/08/windows-7-overtakes-windows-vista.ars

29

Hoofdstuk 6

Afronding 6.1

Conclusie

De hoofddoelen van dit project waren het verbeteren van latency bij gebruik van transitietechnieken en detectie van 6to4- en Teredo-verkeer. Het implementeren van de relays die verder onderzoek mogelijk maken is duidelijk gelukt. Zowel de 6to4- als de Teredo-relay draaien nog altijd zonder problemen. Tijdens korte tests is geconstateerd dat, in ieder geval op de testmomenten, helemaal geen teredoconnectivity mogelijk was naar UTNet. Met de realisatie van de relay is deze er wel, dus dat is pure winst. Van de verbetering van de latency zijn geen harde meetgegevens omdat gekozen is in de gegeven tijdspanne voorkeur te geven aan detectie. Toch mag op basis van de theorie aangenomen worden dat de kwaliteit slechts in één richting kan zijn gegaan, zie figuur 6.1 Conclusie. Ondanks het ontbreken van meetbare resultaten zijn wij van mening dat het leveren van lokale relays een verbetering voor de netwerkinfrastructuur is. 6to4-latencyvoordeel

Legenda

Client A


Legenda

Internetconnectie

Internetconnectie

Normale route

Normale route

Verbeterde route

Verbeterde route

Client netwerk

Overeenkomende route

Client A

Overeenkomende route

Client netwerk

Teredo server 6to4 relay router

Universiteit Twente

Universiteit Twente

UTNet

6to4 relay router

UTNet

Host B

Teredo relay

Host B

6to4 relay router

Teredo relay

Figuur 6.1: Verbeteringen door betere plaatsing relay De detectie van hosts mag als succes gezien worden. De detectie van 6to4-clients is overweldigend. Door de scripting op de monitoring worden de probleemgevallen er nu duidelijker uitgevist. De detectie voor Teredo is nog niet volledig klaar door het ontbreken van de routering van de Teredo adressen. De testdata afkomstig van het SNT-release-cluster toont echter al aan dat de detectie zelf al werkt en dat het slechts wachten op de routering is alvorens de detectie volledig kan gaan draaien. Naast de beschreven doelen van latency-verbetering en detectie is er nog een groot onbeschreven doel in dit project, het leren. Door diep in de materie te duiken heeft eenieder die meewerkte weer 30

Studenten Net Twente - IPv6-transitietechnieken nieuwe technieken geleerd.

6.2

Future work

Voor de toekomst zijn nog een aantal mogelijke uitbreidingen op het project mogelijk. • Het document na verdere reviews publiceren als Wikibook om iedereen de mogelijkheid te geven bij te dragen aan de kennis. • De routering van Teredo moet nog door de universiteit aangemaakt worden. • De koppeling tussen IP → MAC → gebruiker kan meegenomen worden in de automatische rapportages. Hiermee zou de Servicedesk makkelijk gebruikers kunnen aanspreken. • Het aanspreken van gebruikers op hun gebruik van transitietechnieken kan beleid worden. Hiervoor zullen dan procedures ingericht moeten worden om structureel gebruikers te informeren. • Bij het aanspreken van gebruikers kan meer inzicht verkregen worden onder welke omstandigheden transitietechnieken gebruikt worden. Zo kan meer praktijkkennis gebundeld worden. • De detectiedata kan gebruikt worden voor meer historisch inzicht in een bepaalde gebruiker. Wordt er slechts sporadisch een transitietechniek gebruikt of permanent? Door de data te ontsluiten via frontends kan er meer achtergrond gegeven worden. • De detectiedata kan gebruikt worden als uitbreiding op bestaande NAT-detectie-methoden op het eigen netwerk van de onderwijsinstelling. Gebruikers achter IPv4 NATs creëren bij connectie naar IPv6-hosts tunnels die gedetecteerd worden. • Feedback van andere instellingen kan toegepast worden op de eigen implementatie vergezeld met een geüpdate Wikibook.

31

Bĳlage A

Bijlages A.1

Monitoring scripts

Voor het verwerken van alle informatie in grafieken met behulp van munin en het genereren van daily reports per mail zijn er enkele scripts geschreven. De volledige suite van scripts is te downloaden vanaf http://tilde.snt.utwente.nl/~bedem/mail_munin_scripts.zip. Enkel de README is in deze bijlage opgenomen om een idee te geven van de werking van de scripts zonder te ver in detail te treden. Deze README is in het Engels geschreven omdat de collectie onderdeel wordt van een Engelstalige tutorial voor het genereren van IP-statistieken. A.1.1 A.1.1.1

README Included files

• Configuration files – ranges.conf • Database script – tunnel_db.pl • General python methods – namedranges.py – printreports.py • Munin scripts – munin-ranges.py – munin-six2four.py – munin-teredo.py – munin-totals.py • Mailer scripts – dailymailer.py – hourlymailer.py 32

Studenten Net Twente - IPv6-transitietechnieken A.1.1.2

Setup

The scripts are written in Python and Perl. The Python scripts require the sqlite3 module. The database script needs to be configured as a simple cron job, run every five minutes. For example: */5 * * * * /var/v6tunnel/tunnel_db.pl A.1.1.3

Munin

Do NOT copy the Munin files to /usr/share/munin/plugins or /etc/munin/plugins! These require the ranges.conf file that comes with this collection of files (also used by dailymailer.py and hourlymailer.py). Use a set of symlinks to get it working. Copy-paste list: ln ln ln ln

-s -s -s -s

/var/v6tunnel/munin-totals.py /etc/munin/plugins/v6tunnel-totals /var/v6tunnel/munin-ranges.py /etc/munin/plugins/v6tunnel-ranges /var/v6tunnel/munin-six2four.py /etc/munin/plugins/v6tunnel-six2four /var/v6tunnel/munin-teredo.py /etc/munin/plugins/v6tunnel-teredo

The Munin plugins will generate graphs showing the amount of 6to4 and Teredo tunnellers sighted over a period of five minutes. This does not take repeating offenders into account, so a running session will affect the graph over a period of time. The graph-specific properties: totals Shows two lines, one with the 6to4 total, another with the Teredo total ranges Shows two lines for each range specified in ranges.conf (one 6to4, one Teredo) plus two lines for the remaining (undefined) addresses six2four A stacked graph showing the contributions from each separate range to the 6to4 total teredo A stacked graph showing the contributions from each separate range to the Teredo total You will be able to find the graphs in the Tunnels category. A.1.1.4

Mail reports

The dailymailer.py script generates a daily report for all IPs that were spotted the previous day. IPs that were spotted before the previous day will be listed separately (in separate lists for 2 days ago, 3 days ago etc). The hourlymailer.py script generates an hourly report for all IPs that were spotted the previous hour and haven’t been spotted before on the same day. Sightings on previous days are not mentioned in this report. The reports are intended to be mailed with cron jobs. For example: 5 0 * * * /var/v6tunnel/dailymailer.py | mail -s "Daily tunnelling report" [email protected] 0 * * * * /var/v6tunnel/hourlymailer.py | mail -s "Hourly tunnelling report" [email protected]

(Note that both scripts use the same database file and might lock one another out when both run. Since the hourly script takes significantly less time to complete, it’s best to let the daily script run several minutes later than the hourly one, instead of the other way around.) You can use these reports to get an idea of the amount of incorrect tunnelling happening each day and see which ranges are most affected. The hourly mails can be used to be notified quickly after a machine has been sighted, so that you can contact the person responsible as soon as possible. 33

Studenten Net Twente - IPv6-transitietechnieken A.1.1.5

Range definitions

Defining a range in the ranges.conf file will name this range, and define whether or not to show that range in the reports. For example: 12.34.0.0/16

yes

Named Range

This line will group all addresses within the above CIDR range under the title Named Range. If you want to remove a certain range from the reports completely you can use the following form of definition: 12.34.56.0/24

no

Intended tunnels

Note that you cannot leave out the range name, even when the range has a no-show flag. The no-show flag only affects the reports, the range will still show up in the Munin graphs for statistical purposes. The totals in the reports will still include the hidden ranges. It is possible to give two ranges the same name, which can be handy if a certain pool is spread across multiple ranges. In the Munin graphs, all ranges with similar names will be shown under one single name, with one value. The reports will handle them as one range where possible, but when there’s IP addresses sighted which are ’in between’ two of your defined ranges, this will ’split’ your range in the reports. If all of your ranges with a certain name are sequential, they will always look like one single range in the reports. The names will not affect the order in which the ranges appear. Both in the reports and in the Munin graphs, they will show up in numerical order (i.e. sorted by the contained IPs).

A.2

Daily Tunnel Report

Hieronder een voorbeeld van een Daily Tunnel Report zoals deze dagelijks wordt gemaild. Hierin staan alle IP’s genoemd die die dag gedetecteerd zijn en wanneer deze IP’s voor het eerst gedetecteerd zijn. Meldingen als "(36 hosts in hidden ranges)"komen voort uit de configuratie van de monitoring scripts. Door het ontbreken van native IPv6 is het gebruik van transitietechnologieën in sommige ranges legitiem en kan dus worden verborgen. Privacy overwegingen In ICT-omgevingen moet altijd goed nagedacht welke privacyaspecten gemoeid zijn met informatiesystemen. Een publicatie met loggegevens is hierbij een gevoelig onderwerp. De publicatie van onderstaande Daily Tunnel Report is integraal vanaf de productieomgeving over genomen. Hierdoor worden specifieke hosts met hun reverse-DNS genoemd die onze relay hebben gebruikt. Deze gegevens geven een tijdsframe (24 uur) waarin specifieke hosts gebruik maakten van 6to4, danwel Teredo. Naar welke hosts zij verbonden wordt niet vermeld. Doordat er geen verbinding is te reconstrueren is er naar onze mening geen sprake van privacy-schending met deze publicatie. This is the report of incorrect IPv6-tunnel hosts on Sunday 24 October. =========================== 6to4 (total 588) =========================== These hosts were newly detected today (total 41): [Start of range] Campusnet

34


130.89.169.130 130.89.170.139 130.89.171.114 130.89.172.18

-

stud169130.mobiel.utwente.nl stud170139.mobiel.utwente.nl stud171114.mobiel.utwente.nl stud172018.mobiel.utwente.nl

[End of range] 130.89.243.185

- quest243185.mobiel.utwente.nl

(36 hosts in hidden ranges) ------------------These hosts were first sighted 1 days ago (total 12): [Start of range] Campusnet 130.89.170.166 130.89.171.12 130.89.171.224 130.89.172.91 130.89.190.136

-

stud170166.mobiel.utwente.nl stud171012.mobiel.utwente.nl stud171224.mobiel.utwente.nl stud172091.mobiel.utwente.nl gobo.iapc.utwente.nl

[End of range] (7 hosts in hidden ranges) ------------------These hosts were first sighted 2 days ago (total 9): [Start of range] Campusnet 130.89.171.51 130.89.171.154

- stud171051.mobiel.utwente.nl - stud171154.mobiel.utwente.nl

[End of range] 130.89.206.158

- carre206158.mobiel.utwente.nl

(6 hosts in hidden ranges) ------------------These hosts were first sighted 3 days ago (total 5): [Start of range] Campusnet 130.89.170.189

- stud170189.mobiel.utwente.nl

[End of range] (4 hosts in hidden ranges) ------------------These hosts were first sighted 4 days ago (total 3): (3 hosts in hidden ranges) ------------------These hosts were first sighted 5 days ago (total 5): (5 hosts in hidden ranges) ------------------These hosts were first sighted 6 days ago (total 10): (10 hosts in hidden ranges) ------------------These hosts were first sighted 7 days ago (total 4): (4 hosts in hidden ranges) -------------------

35


These hosts were first sighted 8 days ago (total 1): (1 hosts in hidden ranges) ------------------These hosts were first sighted 9 days ago (total 3): [Start of range] Campusnet 130.89.172.110


[End of range] (2 hosts in hidden ranges) ------------------These hosts were first sighted 10 days ago (total 13): (13 hosts in hidden ranges) ------------------These hosts were first sighted 11 days ago (total 19): 130.89.147.11

- adsl147011.mobiel.utwente.nl

(18 hosts in hidden ranges) ------------------These hosts were first sighted 12 days ago (total 20): (20 hosts in hidden ranges) ------------------These hosts were first sighted 13 days ago (total 16): 130.89.72.202

- icts-hor-003.tnw.utwente.nl

(15 hosts in hidden ranges) ------------------These hosts were first sighted 14 days ago (total 12): (12 hosts in hidden ranges) ------------------These hosts were first sighted 15 days ago (total 12): 130.89.147.121


[Start of range] Campusnet 130.89.171.231


[End of range] (10 hosts in hidden ranges) ------------------These hosts were first sighted 16 days ago (total 14): (14 hosts in hidden ranges) ------------------These hosts were first sighted 17 days ago (total 32): (32 hosts in hidden ranges) -------------------

36


These hosts were first sighted 18 days ago (total 25): 130.89.253.247

- euros253247.mobiel.utwente.nl

(24 hosts in hidden ranges) ------------------These hosts were first sighted 19 days ago (total 55): 130.89.81.30

- cpm31113.tnw.utwente.nl

[Start of range] Campusnet 130.89.166.195 130.89.167.66

- stlk.student.utwente.nl - orodreth1.student.utwente.nl

[End of range] (52 hosts in hidden ranges) ------------------These hosts were first sighted 20 days ago (total 68): 130.89.74.122

- wb074122.mobiel.utwente.nl

(67 hosts in hidden ranges) ------------------These hosts were first sighted 21 days ago (total 20): [Start of range] Campusnet 130.89.161.125 130.89.164.82 130.89.167.70 130.89.173.185

-

wade2003.student.utwente.nl wouteresse.student.utwente.nl grolstop.student.utwente.nl stud173185.mobiel.utwente.nl

[End of range] (16 hosts in hidden ranges) ------------------These hosts were first sighted 22 days ago (total 9): [Start of range] Campusnet 130.89.166.235 130.89.167.229

- pyros.student.utwente.nl - septillion.student.utwente.nl

[End of range] (7 hosts in hidden ranges) ------------------These hosts were first sighted 23 days ago (total 38): 130.89.147.171


[Start of range] Campusnet 130.89.163.106 130.89.165.22 130.89.167.179 130.89.169.202

-

inspirerend.student.utwente.nl flipflop.student.utwente.nl tommyfirewire.student.utwente.nl stud169202.mobiel.utwente.nl

[End of range] 130.89.212.1

- itc212001.mobiel.utwente.nl

(32 hosts in hidden ranges) ------------------These hosts were first sighted 24 days ago (total 85):

37


130.89.12.141

- ewi951.ewi.utwente.nl

[Start of range] Campusnet 130.89.169.219


[End of range] 130.89.195.192 130.89.254.237

- smi192.ewi.utwente.nl - linux060.routing.utwente.nl

(81 hosts in hidden ranges) ------------------These hosts were first sighted 25 days ago (total 57): 130.89.36.53 130.89.145.157 130.89.146.16 130.89.152.31

-

icts-sp-038.itbe.utwente.nl ewi863.ewi.utwente.nl servan-home1.adsl.utwente.nl gwnet99.gw.utwente.nl

[Start of range] Campusnet 130.89.161.64 130.89.162.31 130.89.162.210 130.89.163.200 130.89.168.69 130.89.168.73

-

mosquito.student.utwente.nl nimbus.student.utwente.nl jef-lap.student.utwente.nl shinjitsu.student.utwente.nl dejoeri.student.utwente.nl henryqcy.student.utwente.nl

[End of range] 130.89.254.233

- linux059.routing.utwente.nl

(46 hosts in hidden ranges) =========================== Teredo (total 118) =========================== These hosts were newly detected today (total 91): 27.133.235.163 41.129.0.201 41.129.39.180 41.200.19.94 58.35.104.175 60.52.52.17 61.90.176.108 62.83.189.241 62.212.207.195 69.171.163.88 69.171.164.96 69.171.166.188 69.171.176.196 71.97.158.85 74.137.173.138 79.80.207.165 80.83.238.4 81.18.115.145 81.88.222.70 82.27.23.84 82.113.106.152 82.224.127.191 82.246.68.187 83.27.15.52 83.28.5.182 83.149.3.4 83.149.36.236 84.240.4.6 85.141.156.220 85.185.67.254 87.93.139.68 87.159.8.100 87.244.134.89 88.208.155.116 88.227.198.33

- 163.235.133.27.ap.yournet.ne.jp

-

175.104.35.58.broad.xw.sh.dynamic.163data.com.cn 52.60.in-addr.arpa.tm.net.my 61-90-176-108.static.asianet.co.th 62.83.189.241.dyn.user.ono.com

-

ord-69-171-163-88.evdo.leapwireless.net hou-69-171-164-96.evdo.leapwireless.net sat-69-171-166-188.evdo.leapwireless.net iad-69-171-176-196.evdo.leapwireless.net pool-71-97-158-85.aubnin.dsl-w.verizon.net 74-137-173-138.dhcp.insightbb.com 165.207.80-79.rev.gaoland.net 80.83.238.4.gprs.mrdv.mts.ru

- nat.222-70.maryno.net - client-82-27-23-84.pete.adsl.tesco.net -

pro75-2-82-224-127-191.fbx.proxad.net pob78-2-82-246-68-187.fbx.proxad.net auh52.neoplus.adsl.tpnet.pl bdt182.neoplus.adsl.tpnet.pl ip-83-149-3-4.nwgsm.ru

- lan-84-240-4-6.vln.skynet.lt - ppp85-141-156-220.pppoe.mtu-net.ru -

87-93-139-68.bb.dnainternet.fi p579F0864.dip.t-dialin.net 89-134-244-87.sat.poltava.ua adsl-dyn-88-208-155-116.heliweb.de

38


89.200.225.246 91.17.66.11 91.115.176.102 91.196.150.100 92.116.195.206 93.121.218.200 93.138.88.71 93.182.21.13 94.160.163.177 94.161.155.149 94.162.150.188 95.25.130.98 95.27.197.1 95.33.159.128 95.135.70.174 95.153.181.67 95.221.197.140 96.238.45.113 99.238.118.2 112.201.34.170 113.22.68.156 115.164.108.77 118.5.146.2 126.15.83.44 128.12.26.165 138.199.68.24 151.20.139.13 151.21.78.90 151.21.87.70 151.57.99.115 173.141.21.173 178.76.15.226 178.171.63.74 178.182.192.149 188.46.29.69 189.127.166.5 194.150.65.9 200.86.116.63 200.103.89.194 202.3.77.227 202.115.125.228 212.23.105.72 213.87.87.253 213.87.194.164 217.66.146.60 217.118.79.29 217.118.92.23 220.104.97.170 222.124.198.188 244.235.169.82 244.242.151.79 245.216.142.113 245.217.147.53 247.12.144.61 249.114.28.17 252.31.122.55

- host-89-200-225-246.leon.com.pl - p5B11420B.dip.t-dialin.net - 91-115-176-102.adsl.highway.telekom.at - client-adsl-93-121-218-200.mediaserv.net - 93-138-88-71.adsl.net.t-com.hr - host-93-182-21-13.real.kvidex.net

-

95-25-130-98.broadband.corbina.ru 95-27-197-1.broadband.corbina.ru dyndsl-095-033-159-128.ewe-ip-backbone.de 174-70-135-95.pool.ukrtel.net 95x153x181x67.kubangsm.ru ip-95-221-197-140.bb.netbynet.ru pool-96-238-45-113.prvdri.fios.verizon.net CPE000e08e99bea-CM0012c999e65c.cpe.net.cable.rogers.com 112.201.34.170.pldt.net

- p1002-ipbfp1905tokaisakaetozai.aichi.ocn.ne.jp - softbank126015083044.bbtec.net - ppp-13-139.20-151.libero.it - ppp-90-78.21-151.libero.it - ppp-70-87.21-151.libero.it - 173-141-21-173.pools.spcsdns.net - 178-171-56-74.goodline.info - 178.182.192.149.nat.umts.dynamic.eranet.pl -

serv5.mconline.com.br gprs-inet-65-9.elisa.ee pc-63-116-86-200.cm.vtr.net 200-103-89-194.cbace702.dsl.brasiltelecom.net.br

- sn125228.swufe.edu.cn - 253.gprs.mts.ru - host-60-146-66-217.spbmts.ru - p3170-ipbf5409marunouchi.tokyo.ocn.ne.jp

------------------These hosts were first sighted 1 days ago (total 8): 59.180.194.69 67.166.81.176 69.171.160.116 77.167.218.128 82.216.69.101 110.175.210.204 216.12.9.189 248.27.173.7

-

triband-del-59.180.194.69.bol.net.in c-67-166-81-176.hsd1.or.comcast.net den-69-171-160-116.evdo.leapwireless.net ip4da7da80.direct-adsl.nl ip-101.net-82-216-69.rev.numericable.fr 110-175-210-204.static.tpgi.com.au ha.3g.ntelos.net

------------------These hosts were first sighted 2 days ago (total 4): 89.130.48.174 93.144.31.113 151.65.124.7 195.24.198.206

- net-93-144-31-113.cust.dsl.teletu.it

39


------------------These hosts were first sighted 3 days ago (total 2): 60.242.238.9 74.140.167.160

- 60-242-238-9.static.tpgi.com.au - 74-140-167-160.dhcp.insightbb.com

------------------These hosts were first sighted 4 days ago (total 1): 84.62.171.17

- dslb-084-062-171-017.pools.arcor-ip.net

------------------These hosts were first sighted 10 days ago (total 2): 92.42.55.13 217.118.95.116 ------------------These hosts were first sighted 15 days ago (total 1): 43.244.194.78

- 78.194.244.43.ap.yournet.ne.jp

------------------These hosts were first sighted 16 days ago (total 1): 206.49.165.26 ------------------These hosts were first sighted 19 days ago (total 1): 194.29.137.12

- bratniak.nat.student.pw.edu.pl

------------------These hosts were first sighted 20 days ago (total 1): 193.224.131.42

- fwsm-nat3.sze.hu

------------------These hosts were first sighted 21 days ago (total 2): 81.201.60.169 194.29.137.7

- router-zero.pilsfree.net - babilon.nat.student.pw.edu.pl

------------------These hosts were first sighted 25 days ago (total 1): 193.136.33.133 ------------------These hosts were first sighted 27 days ago (total 3): 83.171.11.34 - gw-world-s1.bt.ktu.lt 193.219.179.198 - ip-198.kauko.lt 222.124.198.130 ===========================

A.3

pmacctd.conf

/etc/pmacct/pmacctd.conf: ! pmacctd configuration ! ! ! daemonize: true pidfile: /var/run/pmacctd.pid 40

Studenten Net Twente - IPv6-transitietechnieken syslog: daemon ! ! interested in in and outbound traffic aggregate[6to4]: src_host aggregate[teredo]: dst_host aggregate_filter[6to4]: dst 192.88.99.1 aggregate_filter[teredo]: dst net 2001::/32 ! on this network pcap_filter: dst 192.88.99.1 or dst net 2001::/32 ! on this interface interface: eth0 plugins: memory[6to4], memory[teredo] imt_path[6to4]: /var/v6tunnel/pmacct.6to4.pipe imt_path[teredo]: /var/v6tunnel/pmacct.teredo.pipe

41

6to4. Teredo. IPv6-transitietechnieken. Studenten Net Twente

Recommend Documents