1 / 65

Designing IP

Designing IP. EE122 Fall 2011 Scott Shenker http:// inst.eecs.berkeley.edu /~ee122/ Materials with thanks to Jennifer Rexford, Ion Stoica , Vern Paxson and other colleagues at Princeton and UC Berkeley. Today’ s Lecture is a Transition. F rom heady principles… . ..to packet headers

kalani
Download Presentation

Designing IP

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. Designing IP EE122 Fall 2011 Scott Shenker http://inst.eecs.berkeley.edu/~ee122/ Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxsonand other colleagues at Princeton and UC Berkeley

  2. Today’s Lecture is a Transition From heady principles… ...to packet headers From essentials… …to esoterica From fundamentals… …to no-fun-at-all

  3. Today’s (Boring) Topics • Design of IP • Comparison with IPv6 • Quick Security Analysis • Introduction to IP Addressing • But first, a chance to grill Shaddi about Project 1

  4. Questions about Project 1

  5. The Design of IP

  6. What is “designing” a protocol? • Specifying the syntaxof its messages • Format • Specifying their semantics • Meaning • Responses

  7. What is Designing IP? • Syntax: format of packet • Nontrivial part: packet “header” • Rest is opaque payload (why opaque?) • Semantics: meaning of header fields • Required processing Header Opaque Payload

  8. Packet Header as Interface • Think of packet header as interface • Only way of passing information from packet to switch • Designing interfaces: • What task are you trying to perform? • What information do you need to accomplish it? • Header reflects information needed for basic tasks

  9. In-Class Exercise • Five minutes to design the IPv7 packet header • Do not look at book, or otherwise copy IPv4 or IPv6 • Do work in groups • Goal not to get right answer, but to think about: • What tasks are involved? • How can a packet header accomplish it? • Note: IPv4 is not a great model • Try to do better!

  10. I’ll Take Two or Three Answers • You tell me your: • Task list • Corresponding information in header • And any deep insights about architecture? • TAs will write on board • We will compare and discuss • Provide useful background for rest of lecture

  11. What Tasks Do We Need to Do? • Read packet correctly • Get packet to the destination • Get responses to the packet back to source • Carry data • Tell host what to do with packet once arrived • Specify any special network handling of the packet • Deal with problems that arise along the path

  12. Reading Packet Correctly • Where does header end? • Where does packet end? • What version of IP? • Why is this so important?

  13. Getting to the Destination • Provide destination address (duh!) • Should this be location or identifier? • And what’s the difference? • If a host moves, should its address change? • If not, how can you build scalable Internet? • If so, then what good is an address for identification?

  14. Getting Response Back to Source • Source address (duh!)

  15. Carry Data • Payload (duh!)

  16. Telling Dest’n How to Process Packet • Indicate which protocols should handle packet • What layer should this protocol be in? • What are some options for this today? • How does the source know what to enter here?

  17. Special Handling • Type-of-service: Priority, etc. • Options: discuss later

  18. Dealing with Problems • Is packet caught in loop? • TTL • Header Corrupted: • Detect with Checksum • What about payload checksum? • Packet too large? • Deal with fragmentation • Split packet apart • Keep track of how to put together

  19. Are We Missing Anything? • Read packet correctly • Get packet to the destination • Get responses to the packet back to source • Carry data • Tell host what to do with packet once arrived • Specify any special network handling of the packet • Deal with problems that arise along the path

  20. From Semantics to Syntax • The past few slides discussed the kinds of information the header must provide • Will now show the syntax (layout) of IPv4 header, and discuss the semantics in more detail

  21. IP Packet Structure 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  22. 20 Bytes of Standard Header, then Options 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  23. Go Through Tasks One-by-One • Read packet correctly • Get packet to the destination • Get responses to the packet back to source • Carry data • Tell host what to do with packet once arrived • Specify any special network handling of the packet • Deal with problems that arise along the path

  24. Reading Packet Correctly • Version number (4 bits) • Indicates the version of the IP protocol • Necessary to know what other fields to expect • Typically “4” (for IPv4), and sometimes “6” (for IPv6) • Header length (4 bits) • Number of 32-bit words in the header • Typically “5” (for a 20-byte IPv4 header) • Can be more when IP options are used • Total length (16 bits) • Number of bytes in the packet • Maximum size is 65,535 bytes (216 -1) • … though underlying links may impose smaller limits

  25. Fields for Reading Packet Correctly 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  26. Getting Packet to Destination and Back • Two IP addresses • Source IP address (32 bits) • Destination IP address (32 bits) • Destination address • Unique identifier/locator for the receiving host • Allows each node to make forwarding decisions • Source address • Unique identifier/locator for the sending host • Recipient can decide whether to accept packet • Enables recipient to send a reply back to source

  27. Fields for Packet Reaching Destination 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  28. Telling Host How to Handle Packet • Protocol (8 bits) • Identifies the higher-level protocol • Important for demultiplexing at receiving host • Most common examples • E.g., “6” for the Transmission Control Protocol (TCP) • E.g., “17” for the User Datagram Protocol (UDP) protocol=6 protocol=17 IP header IP header TCP header UDP header

  29. Field for Next Protocol 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  30. Special Handling • Type-of-Service (8 bits) • Allow packets to be treated differently based on needs • E.g., low delay for audio, high bandwidth for bulk transfer • Has been redefined several times, will cover late in QoS • Options

  31. Fields for Special Handling 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  32. Potential Problems • Header Corrupted: Checksum • Loop: TTL • Packet too large: Fragmentation

  33. Header Corruption • Checksum (16 bits) • Particular form of checksum over packet header • If not correct, router discards packets • So it doesn’t act on bogus information • Checksum recalculated at every router • Why? • Why include TTL? • Why only header?

  34. Checksum Field 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  35. Preventing Loops • Forwarding loops cause packets to cycle forever • As these accumulate, eventually consume allcapacity • Time-to-Live (TTL) Field (8 bits) • Decremented at each hop, packet discarded if reaches 0 • …and “time exceeded” message is sent to the source • Using “ICMP” control message; basis for traceroute

  36. TTL Field 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  37. Fragmentation • Fragmentation: when forwarding a packet, an Internet router can split it into multiple pieces (“fragments”) if too big for next hop link • Must reassemble to recover original packet • Need fragmentation information (32 bits) • Packet identifier, flags, and fragment offset

  38. IP Packet Structure 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  39. FragmentationDetails • Identifier (16 bits): used to tell which fragments belong together • Flags (3 bits): • Reserved (RF): unused bit • Don’t Fragment (DF): instruct routers to not fragment the packet even if it won’t fit • Instead, they drop the packet and send back a “Too Large” ICMP control message • Forms the basis for “Path MTU Discovery”, covered later • More (MF): this fragment is not the last one • Offset (13 bits): what part of datagram this fragment covers in 8-byte units

  40. 500 500 Where Should Reassembly Happen? • Answer 1: router R2 MTU=1000B MTU=1000B Host A MTU=500B Host B R1 R2 1000 1000 MTU (Maximum Transfer Unit) = Maximum packet size handled by network

  41. 500 500 Where should Reassemble Happen? • Answer 2: end-host B (receiver) MTU=1000B MTU=1000B Host A MTU=500B Host B R1 R2 1000 MTU (Maximum Transfer Unit) = Maximum packet size handled by network

  42. 500 500 Which is Right? • Take two minutes to confer with neighbors • Tell me which answer is right, and why! MTU=1000B MTU=1000B Host A MTU=500B Host B R1 R2 1000 MTU (Maximum Transfer Unit) = Maximum packet size handled by network

  43. Where Does Reassembly Happen? • Answer 2: correct answer • Fragments can travel across different paths! R3 MTU=1000B MTU=1000B Host A MTU=500B Host B R1 R2 500 500 1000 MTU (Maximum Transfer Unit) = Maximum packet size handled by network

  44. Example of Fragmentation • Suppose we have a 4000 byte datagram sent from host 1.2.3.4 to host 3.4.5.6 … • … and it traverses a link that limits datagrams to 1,500 bytes Header Length 5 Version 4 Type of Service 0 Total Length: 4000 R/D/M 0/0/0 Fragment Offset: 0 Identification: 56273 Protocol 6 TTL 127 Checksum: 44019 Source Address: 1.2.3.4 Destination Address: 3.4.5.6 (3980 more bytes here)

  45. 20 1480 20 1200 20 1300 1500 1220 1320 Example of Fragmentation (con’t) • Datagram split into 3 pieces • Example: 4000 20 3980

  46. Example of Fragmentation, con’t • Datagram split into 3 pieces. Possible first piece: Header Length 5 Version 4 Type of Service 0 Total Length: 1500 R/D/M 0/0/1 Fragment Offset: 0 Identification: 56273 Protocol 6 TTL 127 Checksum: xxx Source Address: 1.2.3.4 Destination Address: 3.4.5.6

  47. Example of Fragmentation, con’t • Possible second piece: Header Length 5 Version 4 Type of Service 0 Total Length: 1220 Fragment Offset: 185 (185 * 8 = 1480) R/D/M 0/0/1 Identification: 56273 Protocol 6 TTL 127 Checksum: yyy Source Address: 1.2.3.4 Destination Address: 3.4.5.6

  48. Example of Fragmentation, con’t • Possible third piece: Header Length 5 Version 4 Type of Service 0 Total Length: 1320 Fragment Offset: 335 (335 * 8 = 2680) R/D/M 0/0/0 Identification: 56273 Protocol 6 TTL 127 Checksum: zzz Source Address: 1.2.3.4 Destination Address: 3.4.5.6

  49. Offsets vs Numbering Fragments? • Q: why use a byte-offset for fragments rather than a numbering each fragment? • Ans #1: with a byte offset, the receiver can lay down the bytes in memory when they arrive • Ans #2 (more fundamental): allows further fragmentation of fragments

  50. Options: Additional Functionality 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

More Related