# IP-adresse ## Hva det er En IP-adresse er tallet som internettprotokollen skriver inn i hver pakke for å si hvor den skal, ved siden av en annen adresse som sier hvor den kom fra. I dagligtale kalles den ofte et IP-nummer. RFC 791, spesifikasjonen av IP versjon 4 fra 1981, kaller den en internettadresse og trekker skillet i én setning: «En adresse angir hvor den er.» Et navn, for eksempel et domene, sier hva du leter etter, og må først gjøres om til en adresse, og det er jobben til [DNS](/nb/glossary/#dns). Ruten, veien mellom de to adressene, overlates til ruterne underveis. I IPv4 er adressen på 32 bit, fire oktetter, skrevet som fire desimaltall fra 0 til 255 med punktum imellom: 192.0.2.10. RFC 791 delte disse bitene i et nettverksnummer og en lokal del, og tre faste klasser avgjorde hvor delingen falt. Klassene passet dårlig for de fleste organisasjoner: et klasse C-nett rommet høyst 254 verter, et klasse B opptil 65 534, så klasse B-numrene tok slutt mens rutingtabellene vokste. I september 1993 erstattet RFC 1519 klassene med CIDR, som lar delingen falle etter hvilken som helst bit og skriver posisjonen etter en skråstrek. 192.0.2.0/24 er blokken der de første 24 bitene ligger fast: 256 adresser. IPv6 utvider adressen til 128 bit. Den skrives som åtte grupper med opptil fire heksadesimale sifre adskilt av kolon, og RFC 4291 lar én rekke med nullgrupper trekkes sammen til `::`, slik at 2001:db8:0:0:0:0:2:1 også kan skrives 2001:db8::2:1. Fordi den samme adressen da kunne skrives på mange måter, fastsatte RFC 5952 senere én anbefalt form: små bokstaver, ingen innledende nuller i en gruppe og `::` brukt for den lengste rekken med nullgrupper. En adresse hører til et nettverksgrensesnitt, ikke til en maskin. Allerede RFC 791 sa at en enkelt vert må kunne opptre som flere, med flere internettadresser, og at noen verter har flere fysiske grensesnitt. RFC 4291 krever at hvert IPv6-grensesnitt har minst én lenkelokal adresse, som bare gjelder på sitt eget nettverkssegment, uansett hvilke andre adresser det har. En vert på et nettverk som kjører begge versjonene, har derfor flere adresser samtidig, i tillegg til loopback-adressene den bruker for å nå seg selv: blokken 127.0.0.0/8 i IPv4 og `::1` i IPv6. Ikke alle adresser kan nås fra overalt. RFC 1918 setter av tre IPv4-blokker til private nettverk, 10.0.0.0/8, 172.16.0.0/12 og 192.168.0.0/16, og sier at rutinginformasjon om dem ikke skal sendes videre mellom organisasjoner. En enhet med en slik adresse når derfor internett bare gjennom noe som trer inn i stedet for den, for eksempel NAT, som RFC 3022 beskriver som en oversettelse av den private adressen til en offentlig på vei ut. Tre andre blokker, 192.0.2.0/24, 198.51.100.0/24 og 203.0.113.0/24, er reservert av RFC 5737 til dokumentasjon, og RFC 3849 gjør det samme for 2001:db8::/32 i IPv6. Alle eksempeladressene i denne artikkelen er hentet fra disse dokumentasjonsområdene. ## Hvorfor det er viktig Adressen er den ene opplysningen om en klient som en server alltid har, for uten den ville svaret ikke hatt noe sted å gå. Derfor er den standardnøkkelen for mange avgjørelser: regler i en [brannmur](/nb/glossary/#firewall) tillater eller blokkerer etter adresse, en ratebegrensning teller forespørsler per adresse, en tilgangslogg skriver den på hver linje, og en misbruksrapport nevner den. Hver av dem fungerer bare så godt som adressen identifiserer det du tror den identifiserer. Den identifiserer mindre enn det ser ut til. Bak NAT kan alle enhetene på et kontor eller i en husstand nå internett fra den samme offentlige IPv4-adressen, så en blokkering eller en grense rettet mot én av dem treffer alle. Bak en proxy eller et [CDN](/nb/glossary/#cdn) ser serveren proxyens adresse på hver forespørsel, og klientens egen adresse kommer, om den kommer i det hele tatt, i et hodefelt som noen andre har skrevet. En regel skrevet mot en adresse er en regel om en posisjon i nettverket, aldri om en person. Samtidig avslører den mer enn folk regner med. RFC 7239, som standardiserte hodefeltet `Forwarded` som proxyer bruker for å sende klientens adresse videre, påpeker i personvernavsnittet sitt at en IP-adresse kan identifisere en klient entydig, vise hvilken operatør den bruker, og gi et grovt bilde av hvor den befinner seg. En logg full av adresser er derfor et ansvar like mye som et verktøy, og en god grunn til å bestemme hva du tar vare på, før du begynner å ta vare på det. Og nå finnes det to slag. Alt som tolker, lagrer eller sammenligner adresser, må ta imot IPv4 og IPv6 like godt, fordi en klient på et nettverk som tilbyr begge, kan komme over det ene eller det andre. Kode skrevet den gangen hver adresse fikk plass i femten tegn med sifre og punktum, går i stykker ved den første besøkende med IPv6, som regel et sted langt unna der adressen ble lest. ## Slik ser det ut i praksis Standardbiblioteket i Python har en `ipaddress`-modul som tolker begge versjonene og tar seg av regningen, så du aldri trenger å splitte tekststrenger for hånd. I en interaktiv økt: ```text >>> import ipaddress >>> ipaddress.ip_address("203.0.113.57") IPv4Address('203.0.113.57') >>> ipaddress.ip_address("2001:0DB8:0000:0000:0000:0000:0002:0001") IPv6Address('2001:db8::2:1') >>> ipaddress.ip_network("203.0.113.57/24", strict=False) IPv4Network('203.0.113.0/24') >>> ipaddress.ip_network("2001:db8:42:7::5/48", strict=False) IPv6Network('2001:db8:42::/48') ``` Det andre kallet viser normaliseringen som RFC 5952 ber om: den lange skrivemåten med store bokstaver og den korte med små er samme adresse, og modulen skriver ut den kanoniske formen. En streng som 192.0.2.300 avvises med en `ValueError`, fordi 300 ikke får plass i en oktett. De to siste kallene gjør en adresse om til nettverket rundt den. Uten `strict=False` ville modulen avvist også dem, fordi 203.0.113.57/24 har vertsbiter satt; med det settes vertsdelen til null, og igjen står nettverket alene. Akkurat den nullstillingen bruker dette nettstedet på adressene til de besøkende. [Personvernsiden](/nb/privacy/) sier at IP-adressen aldri lagres i sin helhet: den kortes ned i det øyeblikket logglinjen skrives, og siste del erstattes med nuller før noe når disken, så det som lagres, identifiserer et grovt nettverk der et helt kontor og en hel gate kan se helt like ut. Siden legger til at serveren registrerer adressen under to navn og maskerer begge, og at den fjerner hodefeltene som kan bære en egen adresse, de som en bedriftsproxy eller et innholdsleveringsnettverk legger til foran den besøkende, før linjen skrives. Den sier ikke hvor mange biter som overlever; /24 og /48 ovenfor er denne artikkelens illustrasjon, ikke nettstedets innstillinger. Poenget holder uansett. En adresse som aldri skrives i sin helhet, kan ikke lekke i sin helhet, og når den kortes ned på vei inn, avhenger det ikke av en oppryddingsjobb som en dag kan slutte å kjøre. ## Hvor det går galt **Å stole på et hodefelt for klientens adresse.** `X-Forwarded-For` og standardfeltet `Forwarded` er vanlige hodefelt i forespørselen, og RFC 7239 advarer om at hver node på veien til serveren kan endre `Forwarded`, også klienten selv. Kode som tar den første adressen i listen, lar enhver klient velge sin egen adresse, og dermed sin egen ratebegrensning og sin egen plass på en tillatelsesliste. Bruk adressen til TCP-forbindelsen, med mindre forespørselen kom gjennom en proxy du selv drifter, og les i så fall bare det dine egne proxyer har lagt til, regnet fra høyre. **Å behandle en adresse som en person.** Fordi mange brukere kan dele én adresse, kan en utestengning av en adresse stenge ute et helt kontor, og en grense beregnet for én person struper en hel skole. Bruk adresser til grove avgjørelser, sett grenser med delte adresser i tankene, og knytt alt personlig til en innlogget konto i stedet. **Å sammenligne adresser som tekst.** 2001:db8::2:1 og 2001:DB8:0:0:0:0:2:1 er én adresse og to forskjellige strenger, så en tillatelsesliste som sammenligner tekst, godtar den ene og avviser den andre. Tolk begge sider før du sammenligner, eller lagre bare formen fra RFC 5952. **Å tolke for IPv4 alene.** Et regulært uttrykk for fire tall med punktum, en kolonne beregnet for femten tegn eller kode som skiller vert og port ved det siste kolonet, svikter alle på IPv6. Bruk en ekte parser og en kolonnetype eller -lengde som passer for begge versjonene. Når en port skrives ved siden av en IPv6-adresse, anbefaler RFC 5952 hakeparenteser, som i [2001:db8::1]:443, fordi den siste gruppen ellers kunne leses som en del av adressen. **Å beholde fulle adresser lenger enn nødvendig.** Logger, analysetabeller og sikkerhetskopier samler adresser i årevis hvis ingenting stopper dem. Bestem hvilken presisjon du trenger, kort ned adressen når den skrives, ikke etterpå, og gi resten en utløpsdato. **Å bruke ekte adresser i eksempler.** En eksempelkonfigurasjon, et sett med testdata eller et skjermbilde med noen andres ekte adresse sender kopiert trafikk til en fremmed. RFC 5737 reserverer de tre blokkene sine nettopp for å redusere den slags konflikter og forvirring; bruk dem, og 2001:db8::/32 for IPv6. ## Les mer - [RFC 791: Internet Protocol](https://www.rfc-editor.org/rfc/rfc791.html) — spesifikasjonen av IPv4 fra 1981, med adressen på 32 bit og skillet mellom navn, adresser og ruter. - [RFC 4291: IP Version 6 Addressing Architecture](https://www.rfc-editor.org/rfc/rfc4291.html) — adressetypene i IPv6, tekstformene deres og kravet om en lenkelokal adresse. - [RFC 5952: A Recommendation for IPv6 Address Text Representation](https://www.rfc-editor.org/rfc/rfc5952.html) — én kanonisk måte å skrive en IPv6-adresse på, og problemene som frie skrivemåter skaper. - [RFC 7239: Forwarded HTTP Extension](https://www.rfc-editor.org/rfc/rfc7239.html) — hvordan proxyer sender en klients adresse videre, hvorfor du ikke bare kan stole på resultatet, og hva det koster i personvern. - [RFC 5737: IPv4 Address Blocks Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc5737.html) — de tre områdene som er ment for eksempler. - [ipaddress: IPv4/IPv6 manipulation library](https://docs.python.org/3/library/ipaddress.html) — standardmodulen i Python for å tolke, sammenligne og gruppere adresser.