1 / 58

Datakommunikasjon Høsten 2001

Datakommunikasjon Høsten 2001. Forelesning nr 9, 22. oktober 2001 Chapter 15 Internetwork Protocols. Øvingsoppgaver. Oppgave 15.3, 15.6 og 15.12. Neste forelesning, Chapter 17 Transport Protocols. Følgende er IKKE pensum: 17.3 TCP Congestion Control. Internet termonologi (1).

syshe
Download Presentation

Datakommunikasjon Høsten 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Øvingsoppgaver • Oppgave 15.3, 15.6 og 15.12

  3. Neste forelesning, Chapter 17 Transport Protocols • Følgende er IKKE pensum: • 17.3 TCP Congestion Control

  4. Internet termonologi (1) • Kommunikasjonsnett • Overføring av tale og data i et nettverk • internet • Flere kommunikasjonsnett sammenkoblet av broer og/eller rutere • Internet • Intranet • Ekstranett

  5. Internet termonologi (2) • Bro • Benyttes for å sammenkoble LAN som benytter samme LAN protokoller • Adressefiltrering slik at den sender kun videre pakker som er beregnet for det aktuelle nettet • OSI lag 2 (Data Link) • Ruter • Forbinder to nettverk (kan benytte ulike protokoller på lag 1 og 2) • Bruker IP som prossereses både i endesystemer og mellomliggende systemer • OSI Lag 3 (Network)

  6. Internetworking Protocols

  7. Type av forbindelse • Connection oriented • X.25 • Connection less • IP (Internet Protocol)

  8. Design parametre for lag 3 • Ruting • Datagram livslengde • Fragmentering og defragmentering • Feilkontroll • Flytkontroll

  9. Ruting • Ende systemer og rutere vedlikeholder rutingstabeller • Tabell som forteller hvilken ruter en innkommende pakke skal sendes til • Statisk • May contain alternative routes • Dynamisk • Flexible response to congestion and errors • Source routing • Source specifies route as sequential list of routers to be followed

  10. Datagram Livstid • Datagrams could loop indefinitely • Consumes resources • Transport protocol may need upper bound on datagram life • Datagram marked with lifetime • TTL (Time To Live) field in IP • Once lifetime expires, datagram discarded (not forwarded) • Hop count • Decrement time to live on passing through a each router • Time count • Need to know how long since last router

  11. IP Fragmentering (1) • IP setter sammen pakker kun hos mottaker • Parmetre i IP header • Data Unit Identifier (ID) • Identifies end system originated datagram • Source and destination address • Protocol layer generating data (e.g. TCP) • Identification supplied by that layer • Data length • Length of user data in octets

  12. IP Fragmentation (2) • Offset • Position of fragment of user data in original datagram • In multiples of 64 bits (8 octets) • More flag • Indicates that this is not the last fragment

  13. Fragmentation Example

  14. Feilkontroll • Garanterer ikke at en pakke kommer frem • En ruter bør gi beskjed om at en pakke kastes • F.eks. TTL=0 (TTL=Time To Live) • Trenger identifikasjon av datagram

  15. Flytkontroll • Tillater en ruter eller host å begrense mengden av innkommende data • Sender flytkontrollpakker som ber om redusert mengde med pakker • ICMP – Internet Control Message Protocol

  16. TCP/IP • Internett og standardiseringer • Kommunikasjonslagene • TCP/IP modellen  OSI modellen • IP - Internet protocol • Header • Adressering • Ruting • “Hjelpeprotokoller” - ARP, ICMP • TCP og UDP • DNS - Domain Name System

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

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

  19. Application Application Presentation Session Transport Transport Network Network Data Link Data Link Physical Kommunikasjonslagene (referert til OSI) RFC871 OSI Internet-TCP/IP FTP HTTP SMTP DNS TCP UDP ICMP IP ARP PPP Ethernet

  20. IP Header TCP Header Data Data Innkapsling

  21. IP Header TCP Header Data Data Innkapsling

  22. Ethernet Header IP Header TCP Header Data Data Data Ethernet Checksum Innkapsling

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

  24. IP - Internet Protocol RFC791 • Ruting • IP adresser • Veivalg • Fragmentering • Overføring (‘best effort’) • Upålitelig • Forbindelsesløs Pakker kan: • mistes • dupliseres • komme i feil rekkefølge IP rydder ikke opp i dette

  25. IP Header RFC791 Version IHL Type of Service Total length DF MF Identification 0 Fragment Offset Time to Live Protocol Header Checksum 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) Protocol - Angir det overliggende lags protokoll, f.eks. TCP. 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. Identification - Benyttes for å identifisere sammenhørende fragmenter (når opprinnelig IP-pakke var for stor for link-laget). MF - More-flag; 1 hvis flere fragmenter, 0 hvis siste fragment (eller hvis ikke fragmentert). 0 - Null - Alltid satt til 0 DF - Don’t Fragment - settes hvis det ikke ønskes at pakker skal fragmenteres. Total Length - Totalt antall oktetter (IP-header + data) Fragment Offset - Offset i antall 64-bits ord; plassering av dette fragmentet i opprinnelig pakke (= 0 for første fragment eller hvis ikke fragmentert) Eksempel

  26. ARP - Address Resolution Protocol RFC826 • Finne fysisk adresse fra IP-adresse • Benyttes i lokale nett • ARP request sendes som broadcast • Svar på denne lagres (og kan benyttes senere) • En host kan svare på vegne av en annen (proxy ARP) • Eksempler • ARP request, ARP reply

  27. Klasse A (0-127): 0 Nett Lokal Klasse B (128-191): 1 0 Nett Lokal Klasse C (192-223): 1 1 0 Nett Lokal IP-adresser RFC791

  28. IP-adresser • Hvordan angis en IP-adresse? • fire desimale nummer, et pr. byte i adressen, separert med punktum • Kalles for “dotted decimal notation” • Eksempel193.69.136.36

  29. IP-adresser • Spesielle adresser • Broadcast - en til alleLokaladresse har alle bit satt til 1 • Loopback (tilgang til tjenester på egen maskin)127.0.0.1 • Alle bit 0; ukjent IP-adresse (eller default rute) • Måter å adressere • Unicast - en til en • Broadcast - en til alle • Multicast - en til mange

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

  31. Opprinnelig klasse B (1 nett med 65.536 lokaladresser) Nett Lokal Nå: 64 subnett, hvert med 1022 lokaladresser 1 0 1 0 Nett Subnett Lokal Subnett, eksempel RFC791 Subnettmaske: 255.255.252.0 eller /22

  32. Subnett RFC950 • Variabel Length Subnet Mask • Man kan ha subnett av forskjellig størrelse • Mer effektiv utnyttelse av organisasjonens adresseområde. • Måter å angi subnettmasker: • 193.69.136.36, subnettmaske 255.255.255.0 • 193.69.136.36/24 • /24 betyr at 24 bit benytttes til å angi nettadressen • Totalt tilgjengelig 32 bit • 32 – 24 = 8 bit til host adresser

  33. Opprinnelig klasse C nett, 1 nett med 254 lokaladresser Nett Lokal 4 subnett, hvert med 30 lokaladresser Subnett 1 1 0 Nett Lokal 0 x x 4 subnett, hvert med 14 lokaladresser Subnett 1 1 0 Nett Lokal 1 0 x x 1 1 0 8 subnett, hvert med 6 lokaladresser Subnett 1 1 0 Nett Lokal 1 1 x x x Subnett - variable subnettmasker, eksempel RFC950 NÅ: Pluss: Pluss:

  34. Adresseoversetting RFC2663 • Bedre kjent som NAT (Network Address Translator) • IP-adresser innenfor et nettverk • ikke er gyldige for bruk utenfra • skal skjules for utenverdenen • En organisasjon har færre eksterne adresser enn størrelsen på det interne nettverket tilsier • Noen adresseområder er reservert til privat bruk • 10.0.0.0 - 10.255.255.255 • 172.16.0.0 - 172.31.255.255 • 192.168.0.0 - 92.168.255.255 • Disse adressene kan fritt benyttes bak en brannmur uten å komme i konflikt med andre sine IP-adresser på Internett.

  35. ICMP - Internet Control Message Protocol RFC792 • Brukes for feilmeldinger, rutinginformasjon og test • Benytter IP for å sende pakker (på samme måte som TCP og UDP), men er samtidig en nødvendig del av IP • Eksempler: • ICMP redirect • ICMP echo • ICMP time exceeded

  36. 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) 12 Parameter Problem on a Datagram 13Timestamp Request 14Timestamp Reply 15Information Request 16Information Reply 17Address Mask Request 18Address Mask Reply

  37. ICMP eksempel WEB-server Internett 193.69.136.54 Ruter ICMP redirect PC Ruter Intranett 193.69.136.8 193.69.136.56 Fefault GW =193.69.136.56

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

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

  40. Tracert

  41. IPv6 - IP versjon 6

  42. IPv6 - Hvorfor? IPng working group • For få adresser i IPv4 • Snart ikke fler igjen • For dårlig organisering av IPv4 adressene • Mange entries i ruting-tabeller • Mye data som må utveksles mellom ruterne • Svakheter i IPv4 skal bedres • Sikkerhet • Quality of Service The IPv6 Channel,

  43. Version IHL Type of Service Total Length DF MF Identification 0 Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options IPv4 header  IPv6 header Total Length  Payload Length TTL  Hop Limit Protocol  Next Header  økes til 128 bits  økes til 128 bits Header Checksum - Kan fjernes fordi lag 2 utfører feilkontroll, smat at TCP har ende-til-ende feilkontroll 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. Options hånderes i egne ‘Extention Headers’.

  44. IPv6 Header RFC2460 Version Traffic class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address 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. 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. Payload Length (v4 Total Length) - antall bytes data. Til forskjell fra v4 inkluderes ikke lengden på headeren, men evt. ‘extension headers’ er inkludert.

  45. IPv6 Header RFC2460 • Enklere header enn v4 • Kun dobbelt så stor, selv om addressefeltene er 4-doblet • Elementer som ikke alltid benyttes, er fjernet fra header • Ingen begrensning på lengde på opsjonsfelt • Opsjoner kommer nå med egne header, ikke lenger inkludert i generell IP-header • Det kan være flere opsjoner (extension headers) i en IP-pakke.

  46. IPv6 Extension Headers RFC2460 • Hop-by-Hop Options header • Routing header • Fragment header • Authentication header (IPSec- Internet Protocol Security) • Encapsulating Security Payload header (IPSec- Internet Protocol Security) • Destination Options header

  47. IPv6 adresser RFC2373 • 3 kategorier adresser • Unicast, single interface • Multicast, set av interface • Anycast, nærmeste interface • Ingen broadcast addresses in IPv6 • Adressen angis i hex, med ‘:’ mellom hvert 16-bits ord. • Eksempel: 1080:0:0:0:8:800:200C:417A • Kan også skrives: 1080::8:800:200C:417A

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

  49. Fra IPv4 til IPv6 RFC2893 • Flere mulige løsninger: • Dual stack, dvs. har support for både IPv4 og IPv6 • Tunneling mode for å kjøre IPv6 over IPv4 • IPv4-kompatible IPv6-adresser • Adressekonvertering • Disse vil kombineres

More Related