Datakommunikasjon Høsten 2001 Forelesning nr 9, 22. oktober 2001 Chapter 15 Internetwork Protocols

Øvingsoppgaver zOppgave 15.3, 15.6 og 15.12

Neste forelesning, Chapter 17 Transport Protocols zFølgende er IKKE pensum: z17.3 TCP Congestion Control

Internet termonologi (1) zKommunikasjonsnett yOverføring av tale og data i et nettverk zinternet yFlere kommunikasjonsnett sammenkoblet av broer og/eller rutere zInternet zIntranet zEkstranett

Internet termonologi (2) zBro yBenyttes for å sammenkoble LAN som benytter samme LAN protokoller yAdressefiltrering slik at den sender kun videre pakker som er beregnet for det aktuelle nettet yOSI lag 2 (Data Link) zRuter yForbinder to nettverk (kan benytte ulike protokoller på lag 1 og 2) yBruker IP som prossereses både i endesystemer og mellomliggende systemer yOSI Lag 3 (Network)

Internetworking Protocols

Type av forbindelse zConnection oriented yX.25 zConnection less yIP (Internet Protocol)

Design parametre for lag 3 zRuting zDatagram livslengde zFragmentering og defragmentering zFeilkontroll zFlytkontroll

Ruting zEnde systemer og rutere vedlikeholder rutingstabeller zTabell som forteller hvilken ruter en innkommende pakke skal sendes til yStatisk xMay contain alternative routes yDynamisk xFlexible response to congestion and errors zSource routing ySource specifies route as sequential list of routers to be followed

Datagram Livstid zDatagrams could loop indefinitely yConsumes resources yTransport protocol may need upper bound on datagram life zDatagram marked with lifetime yTTL (Time To Live) field in IP yOnce lifetime expires, datagram discarded (not forwarded) yHop count xDecrement time to live on passing through a each router yTime count xNeed to know how long since last router

IP Fragmentering (1) zIP setter sammen pakker kun hos mottaker zParmetre i IP header yData Unit Identifier (ID) xIdentifies end system originated datagram Source and destination address Protocol layer generating data (e.g. TCP) Identification supplied by that layer yData length xLength of user data in octets

IP Fragmentation (2) yOffset xPosition of fragment of user data in original datagram xIn multiples of 64 bits (8 octets) yMore flag xIndicates that this is not the last fragment

Fragmentation Example

Feilkontroll zGaranterer ikke at en pakke kommer frem zEn ruter bør gi beskjed om at en pakke kastes yF.eks. TTL=0 (TTL=Time To Live) zTrenger identifikasjon av datagram

Flytkontroll zTillater en ruter eller host å begrense mengden av innkommende data zSender flytkontrollpakker som ber om redusert mengde med pakker zICMP – Internet Control Message Protocol

TCP/IP zInternett og standardiseringer zKommunikasjonslagene yTCP/IP modellen  OSI modellen zIP - Internet protocol yHeader yAdressering yRuting y“Hjelpeprotokoller” - ARP, ICMP zTCP og UDP zDNS - Domain Name System

Organisasjoner og standardisering IAB ISOC ICANN IESG IETF RFC Internet Architecture Board - teknisk ansvarwww.iab.orgwww.iab.org Internet Society - legalt ansvarwww.isoc.orgwww.isoc.org The Internet Corporation for Assigned Names and Numbers - Ansvar for IP- adresser og domain navn (tidligere lå dette under IANA) The Internet Engineering Steering Group - besluttende organ The Internet Engineering Task Force - gjør den egentlige jobben (utarbeider RFCer) Request For Commentswww.rfc-editor.orgwww.rfc-editor.org Standarder / informasjon Overordnet / detaljert Gyldige / ugyldige Nummerert fra 1(april 1969) til ca (sep. 2000) Selvstendige / tillegg til andre Godkjente / drafts / proposals

TCP/IP zEr egentlig en gruppe av protokoller som har fått navn etter to av disse. zLagdelt, 4 lag er definert i TCP/IP modellen yModellen er laget etter at protokollene ble tatt i bruk (i motsetning til ISO’s OSI-modell) yIkke alltid veldefinert i hvilket lag en protokoll befinner seg zIPv4 er den versjonen av IP som er i bruk idag

Kommunikasjonslagene (referert til OSI) ApplicationPresentationSession Ethernet IP ARP ICMP TCPUDP NetworkTransportData LinkPhysicalApplicationTransportNetworkData Link PPP FTPHTTP DNS OSI Internet-TCP/IP SMTP RFC871

Innkapsling IP Header Data TCP Header Data

Innkapsling IP Header Data TCP Header Data

Innkapsling IP Header Data TCP Header Data Ethernet Header Ethernet Checksum Data

Ethernet Header Ethernet Checksum Data Innkapsling IP Header Data TCP Header Data ‘Protocoll type’ identifiserer neste protokoll som IP (=0800) ‘Protocol’ definerer neste protokoll som TCP (=6) ‘Destination port’ definerer applikasjon, f.eks. HTTP (=80) Eksempel

zRuting yIP adresser yVeivalg zFragmentering zOverføring(‘best effort’) yUpålitelig yForbindelsesløs Pakker kan: xmistes xdupliseres xkomme i feil rekkefølge IP rydder ikke opp i dette IP - Internet Protocol RFC791

IP Header VersionIHLType of ServiceTotal length Source Address Destination Address Options Version -Hvilken verson av IP som benyttes, her vil det stå 4, siden dette er en IPv4 header IHL -Internetwork Header Length - headerens lengde i 32-bits ord (er 5 for header uten opsjoner) Type of Service -Precedence (3 bit), Delay (low/normal), Throughput (normal/high), Reliability (normal/high), Cost (normal/maximize) Total Length -Totalt antall oktetter (IP-header + data) Identification 0 DFDF MFMF Fragment Offset Identification -Benyttes for å identifisere sammenhørende fragmenter (når opprinnelig IP-pakke var for stor for link-laget). DF -Don’t Fragment - settes hvis det ikke ønskes at pakker skal fragmenteres.0 - Null - Alltid satt til 0MF - More-flag;1 hvis flere fragmenter, 0 hvis siste fragment (eller hvis ikke fragmentert). Fragment Offset -Offset i antall 64-bits ord; plassering av dette fragmentet i opprinnelig pakke (= 0 for første fragment eller hvis ikke fragmentert) Time to LiveProtocolHeader Checksum Time To Live -Maxverdi for søkets levetid. Angis i sekunder, men blir i praksis antall ruterhopp; telles ned i hver ruter det passerer inntil det når 0, da sendes det ikke videre. Protocol -Angir det overliggende lags protokoll, f.eks. TCP. RFC791 Eksempel

ARP - Address Resolution Protocol zFinne fysisk adresse fra IP-adresse zBenyttes i lokale nett zARP request sendes som broadcast zSvar på denne lagres (og kan benyttes senere) zEn host kan svare på vegne av en annen (proxy ARP) zEksempler yARP request, ARP replyARP requestARP reply RFC826

IP-adresser 0 NettLokal Klasse A (0-127): 01 NettLokal Klasse B ( ): 011 NettLokal Klasse C ( ): RFC791

IP-adresser zHvordan angis en IP-adresse? yfire desimale nummer, et pr. byte i adressen, separert med punktum yKalles for “dotted decimal notation” yEksempel

IP-adresser zSpesielle adresser yBroadcast - en til alle Lokaladresse har alle bit satt til 1 yLoopback (tilgang til tjenester på egen maskin) yAlle bit 0; ukjent IP-adresse (eller default rute) zMåter å adressere yUnicast - en til en yBroadcast - en til alle yMulticast - en til mange

Subnett zKlasseinndelingen er lite fleksibel, og gir mange ubrukte adresser zBedre utnyttelse av adresseområdet oppnås ved bruk av subnettmasker. zEn subnettmaske angir hvor stor del av adressen som er nettprefikset (nett+subnett) og dermed også hvor stor del lokaladressen er RFC950

Subnett, eksempel RFC NettLokal Opprinnelig klasse B (1 nett med lokaladresser) Nå: 64 subnett, hvert med 1022 lokaladresser 01 NettSubnettLokal Subnettmaske: eller /22

Subnett zVariabel Length Subnet Mask yMan kan ha subnett av forskjellig størrelse yMer effektiv utnyttelse av organisasjonens adresseområde. zMåter å angi subnettmasker: y , subnettmaske y /24 y/24 betyr at 24 bit benytttes til å angi nettadressen yTotalt tilgjengelig 32 bit y32 – 24 = 8 bit til host adresser RFC950

Subnett - variable subnettmasker, eksempel RFC NettLokal Opprinnelig klasse C nett, 1 nett med 254 lokaladresser 011 NettLokal 4 subnett, hvert med 30 lokaladresser Subnett xx0 011 NettLokal 4 subnett, hvert med 14 lokaladresser Subnett 0x1x Pluss: 011 NettLokal 8 subnett, hvert med 6 lokaladresser Subnett x1x1x NÅ:

Adresseoversetting zBedre kjent som NAT (Network Address Translator) zIP-adresser innenfor et nettverk yikke er gyldige for bruk utenfra yskal skjules for utenverdenen zEn organisasjon har færre eksterne adresser enn størrelsen på det interne nettverket tilsier  Noen adresseområder er reservert til privat bruk y y y  Disse adressene kan fritt benyttes bak en brannmur uten å komme i konflikt med andre sine IP-adresser på Internett. RFC2663

ICMP - Internet Control Message Protocol zBrukes for feilmeldinger, rutinginformasjon og test zBenytter IP for å sende pakker (på samme måte som TCP og UDP), men er samtidig en nødvendig del av IP zEksempler: yICMP redirectICMP redirect yICMP echoICMP echo yICMP time exceededICMP time exceeded RFC792

ICMP message types Type FieldMessage Type 0Echo Reply (Svar på Ping) 3Destination Unreachable 4Source Quench (Flyt kontroll) 5Redirect 8 Echo Request (Ping) 11Time Exceeded for a Datagram (Traceoute) 12Parameter Problem on a Datagram 13Timestamp Request 14Timestamp Reply 15Information Request 16Information Reply 17Address Mask Request 18Address Mask Reply

ICMP eksempel PC Internett Ruter Fefault GW = WEB-server ICMP redirect Intranett

PING ping Pinging [ ] with 32 bytes of data: Reply from : bytes=32 time=140ms TTL=126 Reply from : bytes=32 time=10ms TTL=126 Ping statistics for : Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 10ms, Maximum = 140ms, Average = 42ms

Tracert kommando zTraceroute, lister opp hvilke rutere som passeres på vei til mottaker zBenytter TTL (Time To Live) feltet i ICMP Echo Request zFår svar i form av ICMP Time Exceeded melding zTTL settes til 1 for så å økes med 1 hver gang

Tracert

IPv6 - IP versjon 6

IPv6 - Hvorfor? zFor få adresser i IPv4 ySnart ikke fler igjen zFor dårlig organisering av IPv4 adressene yMange entries i ruting-tabeller yMye data som må utveksles mellom ruterne zSvakheter i IPv4 skal bedres ySikkerhet yQuality of Service IPng working group The IPv6 Channel,

VersionIHLType of ServiceTotal Length Source Address Destination Address Options Identification 0 DFDF MFMF Fragment Offset Time to LiveProtocolHeader Checksum IPv4 header  IPv6 header Total Length  Payload Length  økes til 128 bits TTL  Hop LimitProtocol  Next Header Ikke behov for IHL (Internet Header Length) siden IPv6-headeren har konstant lengde. Type of Service - noe av det denne har vært brukt til kan erstattes av Class- parametern i IPv6 Fragmentering hånderes i egen ‘Fragmentation Header’, ikke nødvendig med fragmenteringsinfo i IPv6-headeren. Funksjonen er også endret. Header Checksum - Kan fjernes fordi lag 2 utfører feilkontroll, smat at TCP har ende-til-ende feilkontroll Options hånderes i egne ‘Extention Headers’.

IPv6 Header RFC2460 Source Address Destination Address Hop LimitNext HeaderPayload Length Flow LabelVersionTraffic class Version - samme navn og funksjon som i IPv4, men annen verdi, skal nå identifisere IPv6 (=6). Class - Ny for v6 (evt. erstatter ToS (Type of Service) i v4), kan benyttes for å skille typer av trafikk Flow Label - Ny for v6, avsender benytter denne til å angi QoS (Quality of Service), f.eks real-time data som tale og video. Payload Length (  v4 Total Length) - antall bytes data. Til forskjell fra v4 inkluderes ikke lengden på headeren, men evt. ‘extension headers’ er inkludert. Next header (=v4 Protocol) - Beskriver neste header (i samme pakke), enten dette er en ‘extension header’ eller header for overliggende protokoll. Hop Limit (=v4 Time To Live) - Parameter har endret navn for å bedre samsvare med virkeligheten.

IPv6 Header zEnklere header enn v4 yKun dobbelt så stor, selv om addressefeltene er 4- doblet yElementer som ikke alltid benyttes, er fjernet fra header zIngen begrensning på lengde på opsjonsfelt yOpsjoner kommer nå med egne header, ikke lenger inkludert i generell IP-header yDet kan være flere opsjoner (extension headers) i en IP-pakke. RFC2460

IPv6 Extension Headers zHop-by-Hop Options header zRouting header zFragment header zAuthentication header (IPSec- Internet Protocol Security) zEncapsulating Security Payload header (IPSec- Internet Protocol Security) zDestination Options header RFC2460

IPv6 adresser z3 kategorier adresser yUnicast, single interface yMulticast, set av interface yAnycast, nærmeste interface  Ingen broadcast addresses in IPv6 zAdressen angis i hex, med ‘:’ mellom hvert 16-bits ord. yEksempel: 1080:0:0:0:8:800:200C:417A yKan også skrives: 1080::8:800:200C:417A RFC2373

Fra IPv4 til IPv6 Hvordan skal oppgradering til IPv6 foregå? zVanskelig (=umulig) og kostbart å få oppgradert hele Internett samtidig zMå være mulig å gjøre dette gradvis zIPv4 og IPv6 må kunne fungere side om side i samme nett i en lengre periode zTransisjon fra IPv4 til IPv6 har vært vurdert helt fra begynnelsen av, dvs. en del av designet i IPv6. RFC2893

Fra IPv4 til IPv6 zFlere mulige løsninger: yDual stack, dvs. har support for både IPv4 og IPv6 yTunneling mode for å kjøre IPv6 over IPv4 zIPv4-kompatible IPv6-adresser zAdressekonvertering zDisse vil kombineres RFC2893

IPv4 Dual stack IPv6 RFC2893 All trafikk som både origineres og termineres innenfor IPv6 området går med IPv6 All trafikk som har minst et endepunkt i IPv4-området går med IPv4, selv om det andre endepunktet skulle være i IPv6- området.

Dual stack zEn node har både IPv4 og IPv6 implementert yHar da også normalt tilordnet både IPv4 og IPv6 adresse yBegge disse må ha et record i DNS zVelger v4 eller v6 på bakgrunn av yinformasjon fra navneserver (ang. destinasjon) yHva hvis det returneres både en v4 og en v6 adresse? xDa må det velges, enten av applikasjonen eller at ‘resolveren’ filtrerer / bestemmer prioriteringen. RFC2893

IPv6 i IPv4 tunnel IPv4 IPv6 RFC2893

Adresse og protokollkonvertering IPv4  IPv6 IPv4 IPv6 RFC2765RFC2765, RFC2766 RFC2766

Vil IPv6 bli tatt i bruk? zParallelt med arbeidet med IPv6 har man funnet løsninger på en del av problemene i IPv4 som IPv6 skulle løse. yEr løsningene i IPv6 bedre enn i IPv4? yEr løsningene i IPv4 holdbare på lang sikt? yGir IPv6 mer enn IPv4? zDet blir dyrt å oppgradere eksisterende installasjoner yFår man nok igjen for investeringene? yBlir det nok etterspørsel til at produsentene satser på IPv6?

Status IPv6 zDet finnes eksprimentelle nett y6bone (6bone homepage) (6bone homepage) xUnder overvåkning av IETF IPv6 Transition Working Group. yInternet2 (Internet 2 homepage) (Internet 2 homepage) xSamarbeid mellom universiteter i USA xTester “fremtidens” internett, IPv6 er en del av dette zTilgjengelig utstyr yDet finnes noe tilgjengelig, både host og rutere. yCISCO har beta-versjoner som er tilgjengelige for eksprimentell bruk yse her for info: ipng-implementationsipng-implementations

Status IPv6 i Norge 6bone i Norge (hentet fra UK IPv6 Resource Center)UK IPv6 Resource Center HOMELIEN: Homelien Consulting, Oslo, Norway KQIP-NO: KPNQwest Norway AS, Oslo, Norway NR: Norwegian Computing Center NVG-NTNU: NVG, NTNU, Norway POWERTECH:PowerTech Information Systems AS, Oslo, Norway PVV: Programvareverkstedet, NTNU, Trondheim, Norway PVV2: Programvareverkstedet, NTNU, Trondheim, Norway SERAF: The Students' Electronics and Radio Amateur's association. TELENOR-FOU:Telenor Research and Development TELIANET-NO:Telia Network Services Norway UIO:University of Oslo/Norwegian Internet 2 UIO-IFI:University of Oslo / Institute for Informatics UIT:University of Tromso UNIK:Center for Technology at Kjeller UNINETT:Uninett

Eksempel: FTP fra FTP klient A til FTP server D A  ALLE: ARP Request B  A: ARP Response A  B: DNS Query B  ALLE: ARP Request R1  B: ARP Response B  C (R1): DNS Query B (R1)  C (R2): DNS Query R2  ALLE: ARP Request C  R2: ARP Response B (R2)  C: DNS Query C  B (R2): DNS Response C (R2)  B (R1): DNS Response C (R1)  B: DNS Response B  A: DNS Response B C A D R2 R3 R1 Local nameserver Nameserver FTP server A  ALLE: ARP Request R1  A: ARP Response A  D (R1): TCP SYN (FTP) A (R1)  D (R3): TCP SYN (FTP) R3  ALLE: ARP Request D  R3: ARP Response A (R3)  D: TCP SYN (FTP) D  A (R3): TCP SYN, ACK (FTP) D (R3)  A (R1): TCP SYN, ACK (FTP) D (R1)  A: TCP SYN, ACK (FTP) A  D (R1): TCP ACK (FTP) A (R1)  D (R3): TCP, ACK (FTP) A (R3)  D: TCP ACK (FTP)