1. 1 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

2. 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 3

4. Questions about Project 1 4

5. The Design of IP 5

6. 6 What is “designing” a protocol? Specifying the syntax of 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 7 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 8

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! 9

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 10

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 11

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

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? 13

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

15. Carry Data Payload (duh!) 15

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? 16

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

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 18

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 19

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 20

21. IP Packet Structure 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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 Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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 23

24. 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 (2 16 -1) –… though underlying links may impose smaller limits

25. Fields for Reading Packet Correctly 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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 26

27. Fields for Packet Reaching Destination 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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. 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) IP header TCP headerUDP header protocol=6protocol=17

29. Field for Next Protocol 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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. 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 Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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 32

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? 33

34. Checksum Field 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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. 35 Preventing Loops Forwarding loops cause packets to cycle forever –As these accumulate, eventually consume all capacity 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 oUsing “ICMP” control message; basis for traceroute

36. TTL Field 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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. 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 Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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. 39 Fragmentation Details 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 oInstead, they drop the packet and send back a “Too Large” ICMP control message oForms 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. 40 Where Should Reassembly Happen? Answer 1: router R2 1000 500 MTU=1000B MTU=500B MTU=1000B Host A Host B R1 R2 MTU (Maximum Transfer Unit) = Maximum packet size handled by network 1000

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

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

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

44. 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 Version 4 Header Length 5 Type of Service 0 Total Length: 4000 Identification: 56273 R/D/M 0/0/0 Fragment Offset: 0 TTL 127 Protocol 6 Checksum: 44019 Source Address: 1.2.3.4 Destination Address: 3.4.5.6 (3980 more bytes here)

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

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

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

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

49. 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 Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 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

51. Option Field Layout 51 FieldSize (bits)Description Copied1Set if field copied to all fragments Class20=control, 2=debugging/measurement Number5Specifies option Length8Size of entire option DataVariableOption-specific data

52. Examples of Options End of Options List No Operation (padding between options) Record Route Strict Source Route Loose Source Route Timestamp Traceroute Router Alert ….. 52

53. Announcements There is now room in EE122 –Students in 194 should register for 122 instead –Will need some forms signed Project 1 due Wednesday HW2 will be released tonight, due Sunday Oct 9th Project 2 will be released on Monday Survey results (76 responses, ~1/3 rd ) 53

54. Lectures 67%About right (51) 24% Too fast (18) 8% Too slow (6) 17%Too boring (13) 42%More beanbags!(32) 54

55. Reliable Transport 14%I'm really confused(11) 22%Please cover in section(17) 50%Understood in lecture(38) 13%Enough already!(10) 55

56. Link State 22%I'm really confused(17) 50%Please cover in section(38) 22%Understood in lecture(17) 5%Enough already!(4) 56

57. Distance Vector 30%I'm really confused(23) 46%Please cover in section(35) 20%Understood in lecture(15) 4%Enough already!(3) 57

58. IPv6

59. Motivated (prematurely) by address exhaustion –Addresses four times as big Steve Deering focused on simplifying IP –Got rid of all fields that were not absolutely necessary –“Spring Cleaning” for IP Result is an elegant, if unambitious, protocol 59

60. IPv4 and IPv6 Header Comparison VersionIHLType of ServiceTotal Length IdentificationFlags Fragment Offset Time to LiveProtocolHeader Checksum Source Address Destination Address OptionsPadding VersionTraffic ClassFlow Label Payload Length Next Header Hop Limit Source Address Destination Address IPv4 IPv6 Field name kept from IPv4 to IPv6 Fields not kept in IPv6 Name & position changed in IPv6 New field in IPv6

61. Summary of Changes Eliminated fragmentation (why?) Eliminated header length (why?) Eliminated checksum (why?) New options mechanism (next header) (why?) Expanded addresses (why?) Added Flow Label (why?) 61

62. IPv4 and IPv6 Header Comparison VersionIHLType of ServiceTotal Length IdentificationFlags Fragment Offset Time to LiveProtocolHeader Checksum Source Address Destination Address OptionsPadding VersionTraffic ClassFlow Label Payload Length Next Header Hop Limit Source Address Destination Address IPv4 IPv6 Field name kept from IPv4 to IPv6 Fields not kept in IPv6 Name & position changed in IPv6 New field in IPv6

63. Philosophy of Changes Don’t deal with problems: leave to ends –Eliminated fragmentation –Eliminated checksum –Why retain TTL? Simplify handling: –New options mechanism (uses next header approach) –Eliminated header length oWhy couldn’t IPv4 do this? Provide general flow label for packet –Not tied to semantics –Provides great flexibility 63

64. Comparison of Design Philosophy VersionIHLType of ServiceTotal Length IdentificationFlags Fragment Offset Time to LiveProtocolHeader Checksum Source Address Destination Address OptionsPadding VersionTraffic ClassFlow Label Payload Length Next Header Hop Limit Source Address Destination Address IPv4 IPv6 To Destination and Back (expanded) Deal with Problems (greatly reduced) Read Correctly (reduced) Special Handling (similar)

65. Improving on IPv4 and IPv6? Why include unverifiable source address? –Would like accountability and anonymity (now neither) –Return address can be communicated at higher layer Why packet header used at edge same as core? –Edge: host tells network what service it wants –Core: packet tells switch how to handle it oOne is local to host, one is global to network Some kind of payment/responsibility field? –Who is responsible for paying for packet delivery? –Source, destination, other? Other ideas? Survey results 65