Teredo tunnling

Inom datornätverk är Teredo en övergångsteknik som ger full IPv6- anslutning för IPv6-kompatibla värdar som finns på IPv4 - internet men som inte har någon inbyggd anslutning till ett IPv6-nätverk. Till skillnad från liknande protokoll som 6to4 kan den utföra sin funktion även bakom nätverksadressöversättningsenheter (NAT) som hemmaroutrar.

Teredo använder ett plattformsoberoende tunnlingsprotokoll som tillhandahåller IPv6 -anslutning (Internet Protocol version 6) genom att kapsla in IPv6 - datagrampaket i IPv4 User Datagram Protocol (UDP)-paket. Teredo dirigerar dessa datagram på IPv4-internet och genom NAT-enheter. Teredo-noder på andra ställen i IPv6-nätverket (kallade Teredo-reläer ) tar emot paketen, avkapslar dem och skickar dem vidare.

Teredo är en tillfällig åtgärd. På lång sikt bör alla IPv6-värdar använda inbyggd IPv6-anslutning. Teredo bör inaktiveras när inbyggd IPv6-anslutning blir tillgänglig. Christian Huitema utvecklade Teredo på Microsoft och IETF standardiserade den som RFC 4380. Teredo-servern lyssnar på UDP- port 3544 .

Syfte

För 6to4 , det vanligaste IPv6 över IPv4-tunnelprotokollet, kräver tunnelslutpunkten en offentlig IPv4-adress. Men många värdar ansluter för närvarande till IPv4-internet via en eller flera NAT-enheter, vanligtvis på grund av brist på IPv4-adresser . I en sådan situation tilldelas den enda tillgängliga offentliga IPv4-adressen till NAT-enheten, och tunnelslutpunkten 6to4 måste implementeras på själva NAT-enheten. Problemet är att många NAT-enheter som för närvarande används inte kan uppgraderas för att implementera 6to4, av tekniska eller ekonomiska skäl.

Teredo lindrar detta problem genom att kapsla in IPv6-paket i UDP/IPv4-datagram, som de flesta NAT:er kan vidarebefordra korrekt. Således kan IPv6-medvetna värdar bakom NAT:er fungera som Teredo-tunnelslutpunkter även när de inte har en dedikerad offentlig IPv4-adress. I själva verket kan en värd som implementerar Teredo få IPv6-anslutning utan samarbete från den lokala nätverksmiljön.

På lång sikt bör alla IPv6-värdar använda inbyggd IPv6-anslutning. Det tillfälliga Teredo-protokollet innehåller bestämmelser för en solnedgångsprocedur : Teredo-implementering bör ge ett sätt att sluta använda Teredo-anslutning när IPv6 mognar och anslutning blir tillgänglig med en mindre skör mekanism. Från och med IETF89 planerar Microsoft att inaktivera sina Teredo-servrar för Windows-klienter under första halvåret 2014 [ (exakt datum TBD), och uppmuntra inaktivering av offentligt drivna Teredo-reläer.

Översikt

Teredo-protokollet utför flera funktioner:

1. Diagnostiserar UDP over IPv4 (UDPv4)-anslutning och upptäcker vilken typ av NAT som finns (med en förenklad ersättning till STUN -protokollet)
2. Tilldelar en globalt dirigerbar unik IPv6-adress till varje värd som använder den
3. Kapslar in IPv6-paket inuti UDPv4-datagram för överföring över ett IPv4-nätverk (detta inkluderar NAT-traversal )
4. Leder trafik mellan Teredo-värdar och inhemska (eller på annat sätt icke-Teredo) IPv6-värdar

Nodtyper

Teredo definierar flera olika typer av noder:

Teredo-klient

En värd som har IPv4-anslutning till Internet bakom en NAT och använder Teredo-tunnlingsprotokollet för att komma åt IPv6-internet. Teredo-klienter tilldelas en IPv6-adress som börjar med Teredo-prefixet ( 2001::/32) .

Teredo-server

En välkänd värd som används för initial konfiguration av en Teredo-tunnel. En Teredo-server vidarebefordrar aldrig någon trafik för klienten (förutom IPv6-pingar), och har därför blygsamma bandbreddskrav (högst några hundra bitar per sekund per klient), [ vilket innebär att en enda server kan stödja många klienter. Dessutom kan en Teredo-server implementeras på ett helt tillståndslöst sätt, och därmed använda samma mängd minne oavsett hur många klienter den stöder.

Teredo-relä

Den avlägsna änden av en Teredo-tunnel. Ett Teredo-relä måste vidarebefordra all data på uppdrag av Teredo-klienterna som det betjänar, med undantag för direkta Teredo-klienter till Teredo-klientutbyten. Därför kräver ett relä mycket bandbredd och kan bara stödja ett begränsat antal samtidiga klienter. Varje Teredo-relä betjänar en rad IPv6-värdar (t.ex. ett enskilt campus eller företag, en ISP eller ett helt operatörsnätverk, eller till och med hela IPv6-internet ); den vidarebefordrar trafik mellan alla Teredo-klienter och vilken värd som helst inom nämnda intervall.

Teredo-värdspecifikt relä

Ett Teredo-relä vars tjänsteutbud är begränsat till den värd som den körs på. Som sådan har den inga särskilda krav på bandbredd eller routing. En dator med ett värdspecifikt relä använder Teredo för att kommunicera med Teredo-klienter, men håller sig till sin huvudsakliga IPv6-anslutningsleverantör för att nå resten av IPv6-internet.

IPv6-adressering

Varje Teredo-klient tilldelas en offentlig IPv6-adress , som är konstruerad enligt följande (den högre ordningens bit är numrerad 0):

• Bitarna 0 till 31 har Teredo-prefixet (2001::/32).
• Bitarna 32 till 63 bäddar in den primära IPv4-adressen för Teredo-servern som används.
• Bitarna 64 till 79 innehåller vissa flaggor och andra bitar; formatet för dessa 16 bitar, MSB först, är "CRAAAAUG AAAAAAAA". "C"-biten sattes till 1 om Teredo-klienten är placerad bakom en kon NAT , annars 0, men RFC 5991 ändrade den till att alltid vara 0 för att undvika att avslöja detta faktum för främlingar. "R"-biten är för närvarande otilldelad och bör skickas som 0. "U"- och "G"-bitarna är satta till 0 för att emulera "Universal/lokal" och "Grupp/individuell" bitar i MAC- adresser . De 12 "A"-bitarna var 0 i den ursprungliga RFC 4380-specifikationen, men ändrades till slumpmässiga bitar som valts av Teredo-klienten i RFC 5991 för att ge Teredo-noden ytterligare skydd mot IPv6-baserade skanningsattacker.
• Bitarna 80 till 95 innehåller det obfuskerade UDP-portnumret. Detta är portnumret som NAT mappar till Teredo-klienten, med alla bitar inverterade.
• Bitarna 96 till 127 innehåller den obfuskerade IPv4-adressen. Detta är den offentliga IPv4-adressen för NAT:n med alla bitar inverterade.

Teredo IPv6-adresseringstabell

Bits	0 - 31	32 - 63	64 - 79	80 - 95	96 - 127
Längd	32 bitar	32 bitar	16 bitar	16 bitar	32 bitar
Beskrivning	Prefix	Teredo server IPv4	Flaggor	Obfuskerad UDP-port	Obfuscated Client public IPv4

Som ett exempel hänvisar IPv6-adressen 2001:0000:4136:e378:8000:63bf:3fff:fdd2 till en Teredo-klient som:

• Använder Teredo-server på adressen 65.54.227.120 (4136e378 i hexadecimal )
• Ligger bakom en kon NAT och klienten är inte helt kompatibel med RFC 5991 (bit 64 är inställd)
• Är förmodligen (99,98%) inte kompatibel med RFC 5991 (de 12 slumpmässiga bitarna är alla 0, vilket händer mindre än 0,025% av gångerna)
• Använder UDP-mappad port 40000 på sin NAT (i hexadecimal inte 63bf är lika med 9c40, eller decimaltal 40000)
• Har en NAT offentlig IPv4-adress på 192.0.2.45 (inte 3ffffdd2 är lika med c000022d, det vill säga 192.0.2.45)

Teredo IPv6 exempeltabell

Bits	0 - 31	32 - 63	64 - 79	80 - 95	96 - 127
Längd	32 bitar	32 bitar	16 bitar	16 bitar	32 bitar
Beskrivning	Prefix	Teredo server IPv4	Flaggor	Obfuskerad UDP-port	Obfuscated Client public IPv4
Del	2001:0000	4136:e378	8000	63bf	3fff:fdd2
Avkodad		65.54.227.120	kon NAT	40 000	192.0.2.45

Servrar

Teredo-klienter använder Teredo-servrar för att automatiskt upptäcka vilken typ av NAT de ligger bakom (om någon), genom en förenklad STUN-liknande kvalificeringsprocedur . Teredo-klienter upprätthåller också en bindning av sin NAT mot sin Teredo-server genom att skicka ett UDP-paket med jämna mellanrum. Det säkerställer att servern alltid kan kontakta någon av sina klienter – vilket krävs för att NAT-hålslagning ska fungera korrekt.

Om ett Teredo-relä (eller en annan Teredo-klient) måste skicka ett IPv6-paket till en Teredo-klient, skickar det först ett Teredo-bubbelpaket till klientens Teredo-server, vars IP-adress det härleder från Teredo-klientens IPv6-adress. Servern vidarebefordrar sedan bubblan till klienten, så att Teredo-klientens programvara vet att den måste göra hålslagning mot Teredo-reläet.

Teredo-servrar kan också överföra ICMPv6-paket från Teredo-klienter mot IPv6-internet. I praktiken, när en Teredo-klient vill kontakta en inbyggd IPv6-nod, måste den lokalisera motsvarande Teredo-relä, dvs. till vilket offentligt IPv4- och UDP-portnummer som ska skickas inkapslade IPv6-paket. För att göra det skapar klienten en ICMPv6 Echo Request ( ping ) mot IPv6-noden och skickar den genom sin konfigurerade Teredo-server. Teredo-servern dekapslar ping till IPv6-internet, så att ping så småningom ska nå IPv6-noden. IPv6-noden ska sedan svara med ett ICMPv6 Echo Reply, enligt mandat av RFC 2460. Detta svarspaket dirigeras till närmaste Teredo -relä, som - slutligen - försöker kontakta Teredo-klienten.

Att underhålla en Teredo-server kräver lite bandbredd, eftersom de inte är involverade i faktisk överföring och mottagning av IPv6-trafikpaket. Det innebär inte heller någon åtkomst till routingprotokollen för Internet. De enda kraven för en Teredo-server är:

• Möjligheten att sända ICMPv6-paket med en källadress som tillhör Teredo-prefixet
• Två distinkta offentliga IPv4-adresser. Även om det inte är nedskrivet i den officiella specifikationen, förväntar sig Microsoft Windows-klienter att båda adresserna är konsekutiva - den andra IPv4-adressen är för NAT-detektering

Offentliga Teredo-servrar:

• teredo.trex.fi (Finland)

Tidigare offentliga Teredo-servrar:

• teredo.remlab.net / teredo-debian.remlab.net (Tyskland), omdirigerar nu till teredo.trex.fi

Reläer

Ett Teredo-relä kräver potentiellt mycket nätverksbandbredd. Dessutom måste den exportera ( annonsera ) en rutt mot Teredo IPv6-prefixet (2001::/32) till andra IPv6-värdar. På så sätt tar Teredo-reläet emot trafik från IPv6-värdarna som är adresserade till valfri Teredo-klient och vidarebefordrar den över UDP/IPv4. Symmetriskt tar den emot paket från Teredo-klienter adresserade till inbyggda IPv6-värdar över UDP/IPv4 och injicerar dessa i det inbyggda IPv6-nätverket.

I praktiken kan nätverksadministratörer sätta upp ett privat Teredo-relä för sitt företag eller campus. Detta ger en kort väg mellan deras IPv6-nätverk och valfri Teredo-klient. Men att sätta upp ett Teredo-relä i en skala utöver det för ett enda nätverk kräver möjligheten att exportera BGP IPv6-rutter till de andra autonoma systemen (AS).

Till skillnad från 6to4 , där de två halvorna av en anslutning kan använda olika reläer, använder trafiken mellan en inbyggd IPv6-värd och en Teredo-klient samma Teredo-relä, nämligen den som ligger närmast den inbyggda IPv6-värden nätverksmässigt. Teredo-klienten kan inte lokalisera ett relä själv (eftersom den inte kan skicka IPv6-paket själv). Om den behöver initiera en anslutning till en inbyggd IPv6-värd, skickar den det första paketet via Teredo-servern, som skickar ett paket till den inbyggda IPv6-värden med hjälp av klientens Teredo IPv6-adress. Den inbyggda IPv6-värden svarar sedan som vanligt på klientens Teredo IPv6-adress, vilket så småningom får paketet att hitta ett Teredo-relä, vilket initierar en anslutning till klienten (möjligen med hjälp av Teredo-servern för NAT-piercing ) . Teredo-klienten och den inbyggda IPv6-värden använder sedan reläet för kommunikation så länge de behöver. Denna design innebär att varken Teredo-servern eller klienten behöver känna till IPv4-adressen för några Teredo-reläer. De hittar en lämplig automatiskt via den globala IPv6-routningstabellen, eftersom alla Teredo-reläer annonserar nätverket 2001::/32.

Den 30 mars 2006 var italienska ISP ITGate den första AS som började annonsera en rutt mot 2001::/32 på IPv6 Internet, så att RFC 4380-kompatibla Teredo-implementeringar skulle vara fullt användbara. Från och med den 16 februari 2007 fungerar den inte längre.

Under första kvartalet 2009 aktiverade IPv6-stamnätet Hurricane Electric 14 Teredo-reläer i en anycast- implementering och reklam 2001::/32 globalt. Reläerna var belägna i Seattle , Fremont , Los Angeles , Chicago , Dallas , Toronto , New York , Ashburn , Miami , London , Paris , Amsterdam , Frankfurt och Hong Kong .

Det förväntas att stora nätoperatörer kommer att underhålla Teredo-reläer. Precis som med 6to4 är det fortfarande oklart hur väl Teredo-tjänsten kommer att skala upp om en stor del av internetvärdarna börjar använda IPv6 genom Teredo utöver IPv4. Även om Microsoft har drivit en uppsättning Teredo-servrar sedan de släppte den första Teredo-pseudo-tunneln för Windows XP, har de aldrig tillhandahållit en Teredo-relätjänst för IPv6-internet som helhet.

Begränsningar

Teredo är inte kompatibel med alla NAT-enheter. Genom att använda terminologin för RFC 3489 stöder den full kon, begränsade och portbegränsade NAT - enheter, men stöder inte symmetriska NAT:er . Shipworm-specifikationens original som ledde till det slutliga Teredo-protokollet stödde också symmetriska NAT:er, men släppte det på grund av säkerhetsproblem.

Personer vid National Chiao Tung University i Taiwan föreslog senare SymTeredo, som förbättrade det ursprungliga Teredo-protokollet för att stödja symmetriska NAT:er, och Microsoft- och Miredo-implementeringarna implementerar vissa ospecificerade icke-standardiserade tillägg för att förbättra stödet för symmetriska NAT:er. Anslutning mellan en Teredo-klient bakom en symmetrisk NAT och en Teredo-klient bakom en portbegränsad eller symmetrisk NAT verkar dock vara omöjlig.

Faktum är att Teredo antar att när två klienter utbyter inkapslade IPv6-paket, kommer de mappade/externa UDP-portnumren som används att vara desamma som de som användes för att kontakta Teredo-servern (och bygga Teredo IPv6-adressen). Utan detta antagande skulle det inte vara möjligt att upprätta en direkt kommunikation mellan de två klienterna, och ett kostsamt relä skulle behöva användas för att utföra triangeldirigering . En Teredo-implementering försöker upptäcka typen av NAT vid start och kommer att vägra fungera om NAT:n verkar vara symmetrisk. (Denna begränsning kan ibland lösas genom att manuellt konfigurera en regel för portvidarebefordran på NAT-boxen, vilket kräver administrativ åtkomst till enheten).

Teredo kan bara tillhandahålla en enda IPv6-adress per tunnelslutpunkt. Som sådan är det inte möjligt att använda en enda Teredo-tunnel för att ansluta flera värdar, till skillnad från 6to4 och vissa punkt-till-punkt IPv6-tunnlar. Den bandbredd som är tillgänglig för alla Teredo-klienter mot IPv6-internet begränsas av tillgängligheten av Teredo-reläer, som inte skiljer sig från 6to4-reläer i det avseendet.

Alternativ

Huvudartikel: IPv6-övergångsmekanism

6to4 kräver en offentlig IPv4-adress, men ger ett stort 48-bitars IPv6-prefix för varje tunnelslutpunkt och har en lägre inkapslingsoverhead . Punkt-till-punkt- tunnlar kan vara mer tillförlitliga och är mer ansvarsfulla än Teredo, och ger vanligtvis permanenta IPv6-adresser som inte beror på IPv4-adressen för tunnelslutpunkten. Vissa punkt-till-punkt tunnelmäklare stöder också UDP-inkapsling för att korsa NAT:er (till exempel kan AYIYA -protokollet göra detta). Å andra sidan kräver punkt-till-punkt-tunnlar normalt registrering. Automatiserade verktyg (till exempel AICCU ) gör det enkelt att använda Point-to-Point-tunnlar.

Säkerhetshänsyn

Exponering

Teredo ökar attackytan genom att tilldela globalt routbara IPv6-adresser till nätverksvärdar bakom NAT-enheter, som annars inte skulle kunna nås från Internet. Genom att göra det kan Teredo potentiellt exponera alla IPv6-aktiverade applikationer med en öppen port till utsidan. Teredo-tunnelinkapsling kan också göra att innehållet i IPv6-datatrafiken blir osynligt för paketinspektionsprogram, vilket underlättar spridningen av skadlig programvara. Slutligen utsätter Teredo IPv6-stacken och tunnelprogramvaran för attacker om de skulle ha någon sårbarhet som kan exploateras på distans.

För att minska attackytan har Microsoft IPv6-stacken ett "skyddsnivå" -socketalternativ . Detta tillåter applikationer att specificera från vilka källor de är villiga att acceptera IPv6-trafik: från Teredo-tunneln, från var som helst förutom Teredo (standardinställningen), eller bara från det lokala intranätet .

Teredo-protokollet kapslar också in detaljerad information om tunnelns slutpunkt i sina datapaket. Denna information kan hjälpa potentiella angripare genom att öka genomförbarheten för en attack och/eller genom att minska den ansträngning som krävs.

Brandvägg, filtrering och blockering

För att en Teredo-pseudo-tunnel ska fungera korrekt måste utgående UDP-paket till port 3544 vara ofiltrerade. Dessutom måste svar på dessa paket (dvs. "efterfrågad trafik") också vara ofiltrerade. Detta motsvarar den typiska installationen av en NAT och dess tillståndsbestämda brandväggsfunktionalitet. Teredo tunnelprogramvara rapporterar ett allvarligt fel och stoppar om utgående IPv4 UDP-trafik blockeras.

DoS via routingslingor

Under 2010 upptäcktes nya metoder för att skapa överbelastningsattacker via routingslingor som använder Teredo-tunnlar. De är relativt lätta att förebygga.

Standardanvändning i MS-Windows

Microsoft Windows från och med Windows 10, version 1803 och senare inaktiverar Teredo som standard. Om det behövs kan denna övergångsteknik aktiveras via ett CLI- kommando eller grupprincip .

Genomföranden

Flera implementeringar av Teredo är för närvarande tillgängliga:

• Windows XP SP2 innehåller ett klient- och värdspecifikt relä (även i Advanced Networking Pack för Service Pack 1).
• Windows Server 2003 har ett relä och en server som tillhandahålls under Microsoft Beta-programmet.
• Windows Vista och Windows 7 har inbyggt stöd för Teredo med ett ospecificerat tillägg för symmetrisk NAT-traversering. Men om endast en länklokal- och Teredo-adress finns, försöker dessa operativsystem inte lösa IPv6 DNS AAAA-poster om en DNS A-post finns, i vilket fall de använder IPv4. Därför använder endast bokstavliga IPv6-adresser vanligtvis Teredo. Detta beteende kan ändras i registret .
• Windows 10 version 1803 och senare inaktiverar Teredo som standard. Om det behövs kan denna övergångsteknik aktiveras via ett CLI- kommando eller grupprincip .
• Miredo är en klient, relä och server för Linux , *BSD och Mac OS X ,
• ng_teredo är ett relä och en server baserad på netgraph för FreeBSD från LIP6 University och 6WIND.
• NICI-Teredo är ett relä för Linux-kärnan och en Teredo-server för användarland, utvecklad vid National Chiao Tung University.

Val av namn

Det ursprungliga smeknamnet för Teredo-tunnelprotokollet var Shipworm . Tanken var att protokollet skulle tränga igenom NAT-enheter, ungefär som skeppsmasken (en sorts marin träborrande mussla) borrar tunnlar genom trä. Skeppsmaskar har varit ansvariga för förlusten av många träskrov. Christian Huitema, i det ursprungliga utkastet, noterade att skeppsmasken "bara överlever i relativt rent och oförorenat vatten; dess senaste comeback i flera nordamerikanska hamnar är ett vittnesbörd om deras nyligen hämtade renlighet. Shipworm-tjänsten bör i sin tur bidra [ sic ] till en nyligen hämtad insyn av Internet."

För att undvika förväxling med datormaskar ändrade Huitema senare protokollets namn från Shipworm till Teredo , efter släktnamnet på skeppsmasken Teredo navalis .

externa länkar

• Teredo Översikt på Microsoft TechNet
• Aktuella anycast Teredo BGP-rutter
• Teredo: Tunnelering av IPv6 över UDP genom Network Address Translations (NAT) . RFC 4380, C. Huitema. februari 2006.
• JavaScript Teredo-IP-adresskalkylator