Mer om IP adresser

I ett lokalt nätverk och på Internet identifieras alla enheter med IP-adresser. Det förutsätter att varje nätverksenhet har tilldelats en unik IP-adress.

Bild 1: Regional Internet Registers

Ett sådant adresseringssystem kräver en centraliserade administration. Detta görs av IANA (Internet Assigned Numbers Authority) som drivs av ICANN (Internet Corporation for Assigned Names and Numbers). Ansvaret är sedan delegerat till regionala organisationer (Regional Internet Registers). I Europa är det RIPE (RIPE NCC) som hanterar detta (Réseaux IP Européens se www.ripe.net). RIPE delar sedan ut block med IP-adresser till europeiska operatörer. På RIPE:s hemsida kan man söka upp vem som administrerar en europeisk IP-adress.

Det innebär att en publik adress är alltså spårbar vilket  hjälper att ha regler (Netiquette) på hur man bör bete sig på nätet för att underlätta samvaron med övriga användarna och hur ska man undvika rena olagligheter. Om du tittar igenom avtalet med din Internetoperatör finns det ofta klausuler om att operatören förbehåller sig rätten att stänga av din anslutning ifall ditt användande strider mot god netiquette.

Till skillnad från publika IP-adresser kan privata IP-adresser användas lokalt och lite hur som helst så länge de används tillsammans med adressöversättning.

IP adressutdelning

Datorer i ett nätverk, och andra nätverksenheter, kan konfigureras manuellt för att tilldela de en unik IP-adress. Detta fungerar i ett relativt små nätverk, men i större nätverksmiljö tilldelas IP adresser på ett dynamisk sätt. IP konfigurationer omfattar flera komponenter, hostadress, subnätmask, default gateway, och flera andra adresser exempelvis DNS servers IP-adress.

Den vanligaste metoden för dynamisk utdelning av IP-adresser är DHCP (RFC 1541 och 2131 med flera). DHCP är en funktionell förbättring av det äldre protokollet Bootp. DHCP använder också samma portnummer som Bootp. Bootp var ett enkelt protokoll där en server huvudsakligen höll reda på vilken IP-adress som skulle delas ut till vilken MAC-adress. Sådana statiska mappningar kan även DHCP erbjuda men DHCP erbjuder flera förbättringar.

Med DHCP kan flera noder dela på ett fåtal adresser. På servern lägger vi bara in hur stor adressrymd som ska delas ut. Servern håller sedan reda på vilken nod som fått dem. Då lånet av IP-adress är tidsbegränsat kan IP-adressen sedan erbjudas en ny nod. Själva låneprocessen fungerar så här:

  • Klienterna börjar med att fråga efter DHCP-servers (DHCP Discover)
  • och får då ett erbjudande (DHCP Offer).
  • Klienten tar det första erbjudande och bekräftar det till servern (DHCP request)
  • varpå servern bekräftar (DHCP ack).

Hur länge klienten erbjuds att låna IP-adressen är en viktig parameter. Efter halva den tiden kommer klienten försöka att förnya lånet. Detta för att hela tiden försäkra sig om att ha en fungerande IP-adress. Om detta inte lyckas kommer klienten att göra en helt ny förfrågan (DHCP Discover) efter 87 procent av tiden.

Lånetidens längden varierar beroende på konfigurationer. I ett företagsnät har man ofta lånetider på en vecka, antalet maskiner som flyttar sig är inte så stort. På ett publikt trådlöst nätverk där användare kommer och går kan man ha lånetider på fem minuter. I ett operatörsnät låter man kunderna typiskt ha lånetider mellan 20 och 60 minuter. På mer avancerad nätverksutrustning är därför lånetiden alltid ställbar.

DHCP designades i början av 1990-talet och är idag en självklar del av modern nätverksteknik. Men det är ofta svårt att kombinera säkerhet med användbarhet. DHCP är gjort för att inte krångla eller konstra. Varken klienten eller servern har i grundutförandet någon slags autentisering. Det öppnar möjlighet till varierande attack från en förövare som svarar på DHCP Discover från en nod och sedan ange sig själv som standard gateway. På så vis kan man göra kopior på all information till och från klienten.

En annan aspekt på problem med DHCP är att generera tusentals DHCP request så att DHCP-server tömmer ut IP-adresserna därmed inte behöriga klienter kan få låna IP-adresser.

Under arbete …………………………………………………………………………………………….

Enkel routing
Varje IP-nod har en enkel routingtabell. Du kan få fram den genom kommandot netstat -rn eller ”route print” i Windows. I Unix, Linux och Mac OS X används kommandot netstat -r.

För att förstå tabellen behöver vi förstå subnätmaskens roll. Och vi behöver titta på hur grundfunktionen för routing fungerar:
1. Är mottagaren direkt adresserbar?
2. Är mottagaren en känd nod?
3. Tillhör mottagaren ett känt nät?
4. Använd ”default route”

Routing-processen testar i denna ordning tills den hittar ett giltigt villkor. Och om den inte hittar något villkor som är applicerbart så kastas paketet och protokollet ICMP får se till så att ett felmeddelande skickas. Ordningen är i sig rätt självklar. Först kontrollerar vi om mottagaren sitter på samma nät som vi, i så fall behöver vi inte blanda in routrar och operatörer. Sedan kontrollerar vi om vi vet något om nätet eller just denna adress. I sista hand får vi skicka paketet till en router som förhoppningsvis vet mer.

Routrarna arbetar på samma sätt. Antingen sitter de på samma nät som mottagaren och då handlar det om LAN-teknik hur paketet ska vidarebefordras. Annars undersöker routern om den vet något om just denna nod eller detta nät. Annars skickas paketet till routerns standardlösning: default route. På så sätt routas paketen högre upp i hierarkin. Till slut kommer paketet hamna på en knutpunkt där anslutna routrar känner till alla nätnummer på Internet. Paketet leds då till en väg där routrarna känner till detta specifika nät. De här Internetknutpunkterna kallas idag för IXP, Internet eXchange Points. I Sverige finns cirka tio stycken.

För att kunna avgöra om en mottagare är direkt adresserbar behöver noder och routrar förstå hur stort nät de hanterar. Detta är subnätmaskens uppgift och vi kan uppfatta nätets storlek olika. Många routrar i världen arbetar med nätet 17.0.0.0/8. Detta är ett stort nät om drygt 16 miljoner noder. Men internt på Apple kan de arbeta med 17.0.0.0/24 som bara avser drygt 250 adresser. Det här är ett fundament inom IP. Adressrymder kan aggregeras till större nät. Detta gör routingtabellerna mindre och routingprocessen effektivare.
Första steget, direkt adresserbar, avgör om paketet behöver adresseras till ett lokalt nät. Med hjälp av subnätmasken /24 i detta fall så kan noden räkna ut att nätets storlek är 256 adresser.

Default route (default gateway är samma sak men en vanlig beteckning för en enstaka nod) talar som sagt om vart enstaka paket ska skickas. Default route betecknas med nätnumret 0.0.0.0 och mask 0.0.0.0.
I routingtabellen på föregående sida finns nätet 127.0.0.0. Detta nät med nodadressen 127.0.0.1 används bland annat för felsökning. 127.0.0.1 kallas för localhost och gör det bland annat enkelt att felsöka. Vill man undersöka om IP fungerar så startar man gärna med localhost. Vid felsökning kan man gärna starta med localhost. Adressen används även i accesslistor och brandväggar. Om man startar en servertjänst är det inte ovanligt att den bara svarar på localhost innan man uttryckligen konfigurerat programmet eller brandväggen att svara på andra adresser.

Vad gör subnätmasken?
Subnätmasken består av 32 bitar, som var och en kan ha värdet ett eller noll. På samma sätt som med IP-adresser skrivs varje byte decimalt med en särskiljande punkt. 255.255.255.0 motsvarar alltså 11111111 11111111 11111111 00000000. Ett annat sätt att notera subnätmasken är att notera antal ettor, i detta fall 24 stycken vilket noteras ”/24”. Denna kortform är vanlig i IP-planer. På samma sätt kan man lätt få fram att 255.255.0.0 kan noteras som ”/16”. Däremot kräver det räknande via binära tal för att se hur till exempel 255.255.255.248 kan skrivas som ”/29”. På nästa sida följer en tabell med bägge noteringssätten. Det finns andra möjliga värden på subnätmasken men detta är de absolut vanligaste.
Subnätmasken anger nätets storlek. En nod som har subnätmasken 255.255.255.0 kan då räkna ut att den sitter på ett nät som har
254 noder direkt adresserbara. Om den istället har nätmasken 255.255.255.248 så är 6 noder direkt adresserbara.
Med hjälp av subnätmasken räknar noden ut vilket nätnummer den sitter på. Beräkningen går till så att IP-adressen multipliceras med subnätmasken bit för bit (programmeringsmässigt används en logisk AND-operation: 0 AND 0 = 0, 0 AND 1 = 0, 1 AND 0 = 0, 1 AND 1 = 1). Att använda en AND-operation är ett vanligt sätt i programmering för att ta bort värden vi inte vill behandla. Vi kallar detta för att maska bort bitar och därav kommer namnet subnätmask.
En nod med IP-adressen 195.6.7.25 och subnätmask 255.255.255.0 utför följande beräkning:
IP-adress 195.006.007.025
Nätmask 255.255.255.000
Nätnummer 195.006.007.000
En nod med IP-adressen 195.6.7.25 och subnätmask 255.255.255.240 utför följande beräkning, nu med binär notering:
IP-adress 11000011 00000110 00000111 00011001
Nätmask 11111111 11111111 11111111 11110000
Nätnummer 11000011 00000110 00000111 00010000

Om vi omvandlar denna siffra till decimal punktnotation får vi 195.6.7.16. Noden kan alltså räkna ut nätnumret och dessutom räkna ut att nätets storlek är 14 noder, Första tillåtna värde blir 195.6.7.17 och det sista 195.6.7.30. Även IP-adressen 195.6.7.31 tillhör detta nät men detta värde används för IP-broadcast, det vill säga när alla noder ska adresseras. Totalt ingår IP-adresserna 195.6.7.16–195.6.7.31 i adressrymden men det lägsta numret används som nätnummer och nätnumret behövs i routingtabeller. Det högsta numret används för broadcast. Det är därför vi inte kan adressera 16 noder utan 14.
Subnätmasken används alltså för att räkna ut nätets storlek och det nätnummer som noden sitter på. Noderna 195.6.7.25 och 195.6.7.30 kommer att räkna ut att de sitter på samma nät. Och om vi tittar på hur routing fungerar är detta första villkoret, kontrollera
om noden är direkt adresserbar, i så fall kan noderna utbyta data direkt. Om vi återvänder till IP-planen i början på detta kapitel kan alltså noderna i Sigtuna pratat direkt med sin server medan noderna i Märsta och Knivsta räknar ut att de måste gå via sin router.
Felaktig subnätmask får till konsekvens att noderna misstolkar både nätnummer och nätstorlek och då fungerar inte routing. De kan då råka ut för att de försöker skicka paket till en dator som inte sitter på samma nät eller att de inte når sin default gateway. Alla tre IP-parametrarna IP-adress, mask och default gateway måste alltså vara rätt.
I tidig IP-teknik hade subnätmasken bara värdena /8, /16 och /24. Men detta var en väldigt grov indelning som snabbt ledde till brist på IP-adresser. Själv arbetade jag under tidigt 1990-tal på ett företag med cirka 30 noder, men vi behövde på den tiden dela upp nätet. Därför erhöll vi två stycken publika nät med nätmask /24 vilket gav oss adresseringsmöjlighet upp till drygt 500 noder. Andra som var tidigt ute och lite större än oss fick ett helt /16-nät. När variabel subnätmask infördes runt mitten av 1990-talet så blev både användning och utdelning av publika adresser mycket effektivare. Det enda pris vi fått betala är att det blivit lite krångligare att räkna ut nätstorlek och nätnummer.

IP-headern
Om vi använder en nätverksanalysator för att spela in en IP-header så skulle vi normalt se 20 byte, till exempel sekvensen:
45000056b1ae40003506586b58831e68c0a8 03f5
Vi lägger in mellanslag för att öka tydligheten:
4500 0056 b1ae 4000 3506 586b 5883 1e68 c0a8 03f5
För att kunna tolka detta brukar man granska fyra byte i taget, och läsa dem som en rad. (Kom ihåg att en byte motsvarar åtta bitar eller 2 hexadecimala siffror.) Vi får då fem rader enligt figuten:

Första siffran anger att detta är IP version 4. •
Nästa siffra (dvs 4 bitar) IHL står för IP • Header Length och mäts i 32-bitars ord. Värdet 5 är vanligast och innebär att headern är 20 byte lång.
Nästa byte är ofta just ”00”. Detta fält har • historiskt tolkats som Type of Service, förkortat ToS. I modern IP tolkas detta fält enligt en standard som kallas Diffserv, en kort form av differentiated services. Fältet används av noder för att kunna skilja olika trafiktyper åt.
Total längd består av 2 byte och anger paketets storlek inklusive • header. Mäts i byte, 0x0056 motsvarar decimalt 86 byte. (Beteckningen 0x innebär att efterföljande format är hexadecimalt.)
Varje paket förses med en unik identitet bestående av två byte. I • detta fall 0xB1AE. IP-identiteten används bland annat vid fragmentering.
Tre bitar är reserverade för flaggor. Den första används för när• varande inte. Den andra biten avser ”Don’t Fragment” den tredje avser ”More Fragments”. Dessa tre flaggor tillsammans med offsetvärdet bildar två byte. Värdet 4 (binärt 0100) innebär att flaggan Don’t Fragment är satt till ett. En router får alltså inte fragmentera detta paket.
Fragment offset består av 13 bitar. Värdet är ofta noll som i • exemplet ovan. Funktionen förklaras i nästa avsnitt.
TTL,• Time To Live motsvarar antal routerhopp paketet ska kunna passera. I detta fall 0x35=53 hopp innan paketet kastas. Totalt kan IP inte hantera ett Internet som skulle ha mer än 255 routerhopp, fältet är åtta bitar stort. På Internet idag ligger vi inte i närheten, ett typiskt värde idag är snarare 10–30 hopp innan paketet når sin mottagare. Av historiska skäl lever beteckningen med time kvar, i modern IP borde parametern kallas ”hops to live”.
Protokollfältet med i detta fall innehåll 06 tolkas som att IP bär • protokollet TCP.
Checksumma 586b används för att kunna detektera överförings• fel eller fel i program. Checksumman i IP är av en enkel typ och detekterar bara fel i IP-headern, inte i nyttolasten. IP-nivån förutsätter inte att nivå två kontrollerar innehållet, därför kan överföringsfel uppstå och IP-nivån skulle då fatta routingbeslut på felaktiga paket. Behovet av denna funktion har minskat kraftigt sedan IP togs fram, moderna nivå två protokoll hanterar överföringsfel effektivare än IP.
Funktionen för fältet IP-avsändare framgår av namnet. I den här • guiden används ofta kortformen S-IP, IP-Source, men även beteckningen ”Src” förekommer. Det hexadecimala värdet
5883 1e68 motsvarar 88.131.30.104.
IP mottagare, i den här guiden ofta betecknat som D-IP,• D för destination. c0a8 03f5 motsvarar 192.168.3.245.

Fragmentering
I bästa fall kan vi helt undvika fragmentering. TCP ska dela upp dataflödet i lagom stora paket. Men en avsändare kan inte vara säker på hur paket hanteras av alla länkar som kan vara inblandade i en överföring mellan två noder. Dessutom kan ju förhållandena ändras. Därför kan en router få ett inkommande paket med en storlek som nästkommande länk inte kan hantera. Alltså behöver paketet delas upp – fragmenteras.
Varje länk har ett maximal värde för hur stora paket den hanterar, värdet kallas för MTU Maximum Transmission Unit. För ett vanligt Ethernet är värdet 1 500 byte, men värden ned till 576 byte är tillåtna i IPv4.
Om vi tänker oss att servern i Sigtuna ska skicka paket till en nod på Märsta-nätet så kommer den försöka med paketlängden 1 500 byte. Den seriella länken mellan Sigtuna och Märsta har en MTU om 1 024. Routern har därför inget annat val än att dela upp
paketet.
När routern fragmenterar får den göra det i sektioner om åtta byte,
och längden på ett fragment mäts i ”enheter om åtta byte”. Ett
giltigt
värde skulle därför vara 1 000 byte nyttolast plus 20 byte
header. Totallängden blir då 1 020 vilket inte överskrider MTU för
länken. Routern behåller samma identitet som det ursprungliga
paketet. Första fragmentet skickas iväg med flaggan More Fragments=
1 samt Fragment Offset satt till 0. Nästa fragment är det
sista så flaggan More Fragments sätts till 0. Fragment offset sätts
till 1 000/8 = 125. Totallängden för varje paket sätts till nyttolast
plus 20 byte header.
För mottagarens IP-stack, det vill säga slutstationen kommer
sedan fragment tas emot med flaggan More Fragments satt till ett.
Det vill säga mottagaren förstår att detta inte är den sista delen av
ett paket så den får mellanlagra detta fragment. Sedan kommer fragment två, mottagaren ser på ID-värdet att dessa hör ihop. Flaggan More Fragments satt till noll gör att mottagaren kan avgöra att detta var det sista fragmentet.
Offsetvärdet tillsammans med flaggorna gör att pakten kan komma fram i godtycklig ordning. Om det andra fragmentet kommer först så skulle flaggan More Fragments vara satt till noll. Men Fragment Offset är satt till 125, mottagaren kan alltså avgöra att innehållet i detta fragment ska föregås av 8 × 125 = 1 000 byte data.

Att undvika fragmentering
Fragmentering är något vi vill undvika. Det belastar routrar som helst ska ägna all kraft åt att vidareförmedla paket. Och vi har ju en gång delat upp dataflödet i paket, varför inte göra rätt från början?
Fragmentering kombinerat med paketförluster är riktigt dåligt. Om ett fragment saknas kan mottagaren inte återskapa det ursprungliga datagrammet (paketet). Efter ett tag kommer TCP upptäcka att ett paket saknas och skicka om det men nu med ett annat ID, samtidigt som det ofullständiga paketet ligger och tar plats hos mottagaren. Alltså måste mottagaren regelbundet städa bort misslyckade refragmenteringar.
En avsändare kan hindra fragmentering genom att sätta flaggan Don’t fragment till ett. En router som tar emot ett paket som behöver fragmenteras kommer då att skicka tillbaka ett felmeddelande. Avsändaren har då möjlighet att skicka om paketet men med minskad paketlängd.
Ofta kan man i operativsystem eller register sätta vilken MTU man vill använda. Om man misstänker att någon slags IP-tunnling kan förekomma kan det vara en god idé att ställa ner MTU till 1 480 eller 1 460 för att ge plats åt extra headers. (IP-tunnling innebär att paket förses med en ny IP-header, till exempel för att kunna routas på Internet med en publik adress.)
En sista möjlighet som vissa operativsystem använder är att använda det lokala nätets MTU då man adresserar noderna som sitter på samma nätverk medan man använder en mindre paketstorlek då paketen skickas via default gateway.

Kortfattat om ICMP
Ibland fungerar inte routing eller förmedling av paket på IP-nivån. Paket kommer inte fram eller en router hinner inte hantera paketet i tid. I sig är IP både förbindelselöst och baserat på den praktiska modellen går-det-så-går-det (best effort). Förbindelselös kommunikation innebär att paketet skickas utan att vi kontrollerat om mottagaren är redo att ta emot paket, eller att mottagaren över huvud taget existerar. IP behöver i princip inte ta hänsyn till de problem som kan uppstå. Problem som uppstår ska istället hanteras av protokollet ICMP, Internet Control Message Protocol.
I praktiken ska vi se ICMP som en del av IP. IP beskrivs i RFC 791 och ICMP i nummer 792. De har utvecklats för att vara beroende av varandra. När problem uppstår med att skicka ett paket vidare på IP-nivå så skickas normalt ett ICMP-paket tillbaka till den nod som står som avsändare på det paket som förorsakade problemet. Problemen kan till exempel vara:
Vi hittar ingen bra väg till mottagaren, varken som nod eller nät • (”no route to host” eller ”destination unavailable”).
Paket har passerat för många routrar, vanligtvis beror detta på • fel i routingtabeller så att paketet skickas runt i en loop. (Felet som uppstår kallas time exceed.)
Parameter problem.•
Det är även mekanismer i ICMP som används med felsökningskommandona traceroute och ping.