MC, mc vid hack.org
OBS! Detta är några anteckningar inför ett kort föredrag på Hackaton 2007 men alls ingen färdig text. Ibland innehåller den pinsamma hål där jag menar att fylla i mer information. Ha förbarmande.
Definitionen av att "vara på Internet" är att en dator är nåbar via internetprotokollet (IP) på en globalt annonserad IP-adress.
Är man på Internet pratar man alltså IP och kan nås av alla andra datorer som också pratar IP. Det här brukar ibland kallas "end to end connectivity".
Det här betyder att vem som helst direkt kan vara producent eller konsument av tjänster. Det spelar ingen roll vilken leverantör man använder eller om man kör över koppartråd eller radiovågor. Alla pratar IP.
IP föddes som eget protokoll 1978 och har sedan dess ändrats ganska lite. Den nu närmast allenarådande versionen är version 4 som publicerades 1981.
Övergången till IPv4 genomfördes fram till 1:a januari 1983 och sedan dess har vi alltså pratat IPv4 på Internet.
Sedan 1983 har knappt någonting hänt med IP. Den stora utvecklingen har i stället skett på nivåerna under och över IP-nivån. Under IP har vi sett nya transmissionstekniker som fiber, mer effektiv radiotransmission och nya länklager för att bättre utnyttja kopparkabel. Ovanför IP har mycket hänt med allt från TCP och uppåt till massor av olika applikationsprotokoll.
IPv4 har alltså klarat sig väldigt bra över tid.
Det finns emellertid ett antal problem med IPv4. De här problemen har framförallt märkts när det blivit väldigt många fler noder på Internet än när IPv4 infördes. Det tål att tänka på att när övergången mellan NCP och IPv4 gjordes i januari 1983 hade Internet totalt mindre än 1000 noder. Idag är man osäker på siffran, men det är troligt att det finns fler än 100 miljoner noder.
För att råda bot på problemen har det närmaste Internet kommer ett standardorgan, IETF, sedan 90-talets början arbetat med en ersättare till IPv4: IP version 6, som sedan -98 befinner sig på standards track.
Med den takt som IPv4-adressblock delas ut förutsåg nätorganisationen RIPE på sitt senaste möte (RIPE55 i oktober 2007) att alla nätblock är utdelade senast 2009--2010.
Om inga fler nätblock kan delas ut överhuvudtaget betyder det att en ny organisation, till exempel ett mediaföretag, inte kan få några egna IP-adresser överhuvudtaget.
Naturligtvis finns det kvar oanvända adresser som kontrolleras av olika internetleverantörer, så ytterligare några år kan folk få tag i riktiga IPv4-adresser, men det kommer att vara en stor brist på adresser och kontrollen kommer att mest att ligga hos internetleverantörerna.
Det som kommer att hända är troligen att internetleverantörerna själva börjar sätta upp NAT för stora delar av sina nät. Mer senare om detta.
En lösning på problemet med att IP-adresserna tar slut är NAT, Network Address Translation. Det går ut på att en router konfigureras att översätta privata adresser som används internt till en enda publik adress som används utåt.
På det här viset kan ett väldigt stort nät bestående av massor (kanske miljoner) noder utifrån Internet se ut som en enda nod.
Det finns några olika sorters NAT, men här är ett exempel:
En av de saker som går sönder med NAT är alla program som använder ett protokoll där IP-adresser nämns i protokolldialogen. Några exempel är FTP eller RTSP.
I fallet RTSP så försöker en klient fjärrstyra en server som skickar ut strömmande media, till exempel audio och video. I dialogen med servern säger klienten att den är beredd att ta emot strömmande data på en viss port på sin IP-adress.
Om klienten befinner sig bakom NAT och själv heter, säg, 10.0.0.2 så säger den alltså till RTSP-servern att den vill ta emot data på 10.0.0.2, port 4711. När servern börjar skicka data dit så kommer det ingenstans eller i vilket fall inte till rätt plats.
Man kan lösa en del av de här NAT-problemen genom att sätta upp port forwarding, som ser till att vissa yttre portar på NAT-routern motsvarar något särskilt på insidan eller genom att installera ett proxyprogram som tolkar alla anrop för det protokoll man anropar och översätter dem. Båda kräver emellertid att man har makt över NAT-routern och det är ju inte alltid fallet för användaren av en ändnod.
Är det här ett problem? Kommer folk som sitter med maskiner bakom NAT att vilja sätta upp en server överhuvudtaget? Kan de inte bara konfigurera sin NAT om de måste göra det?
För det första har slutanvändare möjligen inte makten över en NAT-router överhuvudtaget, speciellt inte om NAT görs i internetleverantörerns nät. För det andra: Vad är en server?
Är en server bara, säg, en mailserver eller en webserver? Vad är ett P2P-program? Är det inte samtidigt en server? Hur är det med en IP-telefon som pratar SIP? Är det inte samtidigt en klient och en server?
Många nu existerande protokoll och säkert många framtida gör att gränsen mellan klient och server blir suddig. Det finns ingen anledning att tro att det kommer att upphöra.
Här behövs en annan lösning. En annan lösning är naturligtvis att alla ändnoder får en riktig IP-adress.
Ett annat problem med IPv4 är att de routers som bygger upp stommen i Internet har fått stora tabeller (i slutet av november 2007 omkring 250 000 aktiva routes av totalt 500 000). Stora tabeller i routrarna betyder sämre prestanda. Eftersom vi talar om stommen betyder detta sämre prestanda för alla.
En anledning till att det blivit så stora tabeller är sättet som IPv4-adresser har delats ut och delats in. Det har delvis lösts med olika tekniker (CIDR, Classless Inter-Domain Routing och aggregering), men tabellerna är fortfarande väldigt stora.
En av sakerna som gjort att tabellerna blivit stora är Provider Independent-adresser och multihoming, som kräver PI-adresser.
PI-adresser är ett nätblock som inte tillhör någon internetleverantör. I stället tillhör nätblocket den egna organisationen. Motsatsen mot PI kallas Provider Allocated-adresser (PA).
Multihoming betyder att ett IP-nät har två eller fler vägar ut i världen och annonserar ut sitt nätblock via alla vägar.
Detta betyder i praktiken att om en av dina vägar ut i världen går ner så kan trafiken, även den redan etablerade trafiken, fortfarande flyta fram som om ingenting hänt.
Oumbärligt om du kör en verksamhetskritisk tjänst.
Adresserna i IPv6 är 128 bitar. 2^128 ger ungefär 3,4 * 10^38 adresser. En typisk adress ser ut så här:
2001:c0:9881::1
men det är egentligen en förkortning av:
2001:00c0:9881:0000:0000:0000:0000:0001
Eftersom det finns så gott om adresser behövs normalt inte NAT.
En ändnod skall normalt inte anta något om adressernas struktur, förutom att de är uppbyggda av ett prefix och något som kallas "host interface ID". Det senare är garanterat att alltid vara minst 64 bitar och identifierar en enskild ändnod.
Host interface ID byggs vanligen upp antingen som en funktion av MAC-adressen på gränssnittet, eller slumpmässigt.
Routingen i IPv6 är strikt prefixstyrd. Här finns alltså inga Provider Independend-adresser som jag talade om förut. Det leder automatiskt till mindre tabeller i routrarna.
Det här ersätter DHCP i IPv6. Det gör att maskiner som kan tala IPv6 genast kan konfigurera en IPv6-adress och default gateway åt sig själva och komma ut på nätet utan att någon behöver sätta upp något särskilt för det.
Det fungerar genom att en ändnod först själv bestämmer sin "host interface ID", de 64 bitarna av adressen som unikt identifierar den på det lokala nätverket. En (eller flera) router(s) på det lokala nätet annonserar ut nätprefix och genom att ta dessa nätprefix och sätta ihop med sitt gränssnitts-ID får en ändnod globalt unika IPv6-adresser.
Eftersom adresserna och routingen är prefixstyrd är det också väldigt lätt att numrera om IPv6-adresser genom att bara byta ut det prefix en router annonserar.
Mycket i IPv6 bygger på multicast, så det finns redan från början krav på att alla IPv6-stackar skall klara multicast.
IPsec ger kryptering och autenticering för IP-trafik. Det är obligatoriskt för en IPv6-stack att det skall finnas stöd för detta.
Det finns ett uttalat stöd för prioriterad trafik (Quality of Service, QoS) i IPv6.
Det går enkelt att bygga på IPv6, om man behöver.
I IPv6 fungerar routingen, som jag sagt ovan, enbart med hjälp av prefix. Det betyder alltså att det inte finns några nätblock med Provider Independent-adresser. Sådana PI-adresser är ett krav för multihoming i IPv4, om ni minns.
Eftersom det finns siter som kör så pass verksamhetskritiska saker att de måste fortsätta fungera även om en av deras internetleverantörer faller ner, så vill man ändå ha möjligheten att köra multihoming. Hur gör man då det i IPv6?
Lösningar:
IPsec är, som jag nämnde, obligatoriskt i IPv6.
IPsec fungerar bra för att sätta upp autenticerade och krypterade tunnlar mellan parter som redan känner varandra och fördelen med IPv6 är alltså att det är garanterat att alla inblandade kan tala IPsec. Det underlättar för till exempel uppsättande av VPN och dylikt.
IPsec fungerar mindre bra i det generella fallet, när alla vill kommunicera krypterat och autenticerat med alla. Det skalar helt enkelt inte.
En möjlighet är kanske KINK, som arbetar med Kerberos som pålitlig tredje part. En annan sak är Better Than Nothing Security, som skall leda till användning av en krypterad men oautentiserad version av IPsec.
Alla rotservrar i DNS är ännu inte tillgängliga per IPv6. Fyra av 13 finns på IPv6 i november 2007.
Autokonfiguration i IPv6 må automatiskt konfigurera IP-adressen och default gateway, men man vill typiskt också ha reda på vilken DNS-server man skall kontakta för att slå upp namn. Idag finns det ingen standard för det, även om det finns splitter ny experimentell RFC för det, IPv6 Router Advertisement Option for DNS Configuration, RFC 5006.
IPv6-adresser är, som ni sett, något otympliga. Så ofta det går vill man, förstås, slippa se dem alls. Detta inbegriper och bakåtuppslagningar i DNS.
Eftersom majoriteten av IPv6-adresser antagligen kommer att skapas dynamiskt...
Det finns flera olika implementationer av IPv6. Den vanligaste fria IPv6-stacken just nu är KAME-projektets som finns i alla aktiva operativsystem i BSD-familjen och i Linux.
Microsoft har, så vitt jag förstått, en helt egen implementation som ursprungligen kommer från Microsoft Research. Den har funnits tillgänglig för nedladdning direkt från Research i flera år, men ingår nu som standard i moderna Windows-OS.
Om ni sitter på ett nät med en lokal IPv6-router så skall ni redan nu ha en IPv6-adress och kunna nå åtminstone routern och, kanske, varandra.
Om man sitter fast på en öde ö av IPv4 kan man använda något som kallas 6to4 för att komma det globala IPv6-nätet.
6to4 är ett sätt att snabbt komma in i IPv6-nätet. Det fungerar med en välkänd IPv4-adress som fungerar som gateway. Denna adress är anycastad (överlagrad, så den finns på flera ställen och routing tar hand om att hitta den närmaste åt dig).
När du satt upp 6to4 kommer dina IPv6-paket att läggas in i IPv4-paket och skickas till denna gateway. På samma sätt kommer IPv6-paket på väg till dig att skickas från en gateway instoppade i IPv4-paket.
Det här betyder förstås att du inte kan befinna dig bakom NAT om du vill köra 6to4.
Den här routerns adress i IPv4 är 192.88.99.1 och i IPv6 2002:c058:6301::. Om du kan pinga 192.88.99.1 är du inte långt från IPv6-konnektivitet.
Det finns reserverat en adressrymd i IPv6 för detta. Den ser ut så här:
2002:<din IPv4-adress>::/16
Det betyder alltså att om jag har 82.209.158.128 på min server så översätter jag den till hexadecimalt, som ger 52d1:9e80. Det lägger jag in i det ovan och får då ett helt (jättestort) nät jag kan leka med som heter
2002:52d1:9e80::/16
För att få upp det hela på FreeBSD gör man:
# skapar ett interface för en 6to4-tunnel ifconfig stf0 create # Konfigurerar gränssnittet med en adress ur mitt IPv6-nät ifconfig stf0 inet6 2002:52d1:9e80::1 prefixlen 16 alias # Sätter 6to4-gatewayen 192.88.99.1 som default gateway for # IPv6-trafik route add -inet6 default 2002:c058:6301::
Färdigt.
För att ha en mer fast, konfigurerad tunnel finns flera tekniker. Ett ganska vanligt sätt är att använda IPv6-paket direkt i IPv4-paket på samma sätt som i 6to4, fast mot en vänlig själ som agerar gateway.
Om man inte känner någon som har fast IPv6-konnektivitet kan man sätta upp en tunnel mot en "tunnel broker" som då ofta har någon form av autenticering med i bilden före tunneln etableras. En del av dessa brokers använder också protokoll som kan tunnla IPv6 i UDP eller TCP för att komma igenom NAT och/eller brandväggar.
Några sådana tunnel brokers är SIXXS och Freenet6.
http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html