15-441 Computer Networking Outline IP Service Model Ipv4 Header Fields

15-441 Computer Networking Outline IP Service Model Ipv4 Header Fields

Outline 15-441 Computer Networking • IP Packet Format Lecture 9 – IP Addressing & Packets • IPv6 • NAT 2 IP Service Model IPv4 Header Fields • Low-level communication model provided by Internet 3 •! Version: IP Version 0" 4" 8" 12" 16" 19" 24" 28" 1" ver-" HLe TOS" Length" • Datagram sion" n" Fl • 4 for IPv4 Identifier" ag Offset" ! s" • Each packet self-contained TTL" Protocol" Checksum" • All information needed to get to destination Source Address" •! HLen: Header Length Destination Address" • No advance setup or connection maintenance Options (if any)" •! 32-bit words (typically 5) Data" • Analogous to letter or telegram •! TOS: Type of Service 0" 4" 8" 12" 16" 19" 24" 28" 31" •! Priority information version" HLen" TOS" Length" •! Length: Packet Length IPv4 Identifier" Flag" Offset" •! Bytes (including header) Packet! TTL" Protocol" Checksum" Header! Format! •! Header format can change with versions Source Address" •! First byte identifies version Destination Address" •! Length field limits packets to 65,535 bytes Options (if any)" •! In practice, break into much smaller packets for network performance considerations Data" 3 4 1 IPv4 Header Fields IPv4 Header Fields •! Identifier, flags, fragment offset à used primarily for fragmentation 0" 4" 8" 12" 16" 19" 24" 28" 31" ver-" HLen! TOS" Length" sion" Identifier" Fla Offset" • Source Address gs! ! •! Time to live 3 0" 4" 8" 12" 16" 19" 24" 28" 1" TTL" Protocol" Checksum" ver-" HLe •! Must be decremented at each router TOS" Length" sion" n" Source Address" Fl •! 32-bit IP address of sender ag Identifier" Offset" Destination Address" •! Packets with TTL=0 are thrown away s" TTL" Protocol" Checksum" Options (if any)" •! Ensure packets exit the network Source Address" Data" •! Destination Address •! Protocol Destination Address" Options (if any)" •! 32-bit IP address of destination •! Demultiplexing to higher layer protocols Data" •! TCP = 6, ICMP = 1, UDP = 17… •! Header checksum •! Ensures some degree of header integrity •! Like the addresses on an envelope •! Relatively weak – 16 bit •! Options •! Globally unique identification of sender & •! E.g. Source routing, record route, etc. receiver •! Performance issues •! Poorly supported 5 6 IP Fragmentation…jokes... IP Delivery Model …are always…told in parts… •! Best effort service MTU = •! Network will do its best to get packet to destination 2000! host! router! router! MTU = 1500! •! Does NOT guarantee: host! •! Any maximum latency or even ultimate success MTU = 4000! •! Sender will be informed if packet doesn’t make it •! Every network has own Maximum Transmission Unit •! Packets will arrive in same order sent (MTU) •! Just one copy of packet will arrive •! Largest IP datagram it can carry within its own packet frame •! Implications •! E.g., Ethernet is 1500 bytes •! Scales very well •! Don’t know MTUs of all intermediate networks in advance •! Higher level protocols must make up for shortcomings •! IP Solution • Reliably delivering ordered sequence of bytes à TCP ! •! When hit network with small MTU, fragment packets •! Some services not feasible •! Latency or bandwidth guarantees 7 8 2 Reassembly Fragmentation Related Fields •! Where to do reassembly? •! Length • End nodes or at routers? ! •! Length of IP fragment •! End nodes •! Identification •! Avoids unnecessary work where large packets are •! To match up with other fragments fragmented multiple times •! Flags •! If any fragment missing, delete entire packet •! Don’t fragment flag •! Dangerous to do at intermediate nodes •! More fragments flag •! How much buffer space required at routers? •! Fragment offset • What if routes in network change? ! •! Where this fragment lies in entire IP datagram •! Multiple paths through network •! All fragments only required to go through destination •! Measured in 8 octet units (13 bit field) 9 10 IP Fragmentation Example #1 IP Fragmentation Example #2 MTU = 2000! router! host! router! router! MTU = 4000! Length = 2000, M=1, Offset = 0! Length = 3820, M=0! IP" IP" IP" IP" Header" Data" Length = 3820, M=0! Header" Data" IP" IP" 1980 bytes! Header" Data" 3800 bytes! Length = 1840, M=0, Offset = 1980! IP" IP" Header" Data" 1820 bytes! 11 12 3 IP Fragmentation Example #3 IP Reassembly Length = 1500, M=1, Offset = 0! Length = 1500, M=1, Offset = 0! host! •! Fragments might arrive out-of- router! IP" IP" IP" IP" MTU = 1500! Header" Data" Header" Data" order •! Don’t know how much memory Length = 520, M=1, Offset = 1480! Length = 2000, M=1, Offset = 0! 1480 bytes! required until receive final fragment IP" IP" Length = 520, M=1, Offset = 1480! • Some fragments may be IP" IP" Header" Data" ! Header" Data" duplicated IP" IP" Length = 1500, M=1, Offset = 1980! Header" Data" •! Keep only one copy IP" IP" 1980 bytes! Length = 1500, M=1, Offset = 1980! • Some fragments may never arrive Header" Data" ! 500 bytes! IP" IP" •! After a while, give up entire process Length = 1840, M=0, Offset = 1980! Length = 360, M=0, Offset = 3460! Header" Data" Length = 360, M=0, Offset = 3460! IP" IP" IP" IP" IP" IP" Header" Data" Header" Data" Header" Data" 1480 bytes! IP" IP" IP" IP" Data" Data" Data" Data" 1820 bytes! 340 bytes! 13 14 Fragmentation and Reassembly Concepts Fragmentation is Harmful •! Demonstrates many Internet concepts •! Uses resources poorly •! Decentralized •! Forwarding costs per packet •! Every network can choose MTU •! Best if we can send large chunks of data •! Connectionless •! Worst case: packet just bigger than MTU •! Each (fragment of) packet contains full routing information •! Poor end-to-end performance •! Fragments can proceed independently and along different routes •! Loss of a fragment •! Best effort •! Fail by dropping packet •! Path MTU discovery protocol à determines minimum MTU •! Destination can give up on reassembly along route •! No need to signal sender that failure occurred •! Uses ICMP error messages •! Complex endpoints and simple routers •! Common theme in system design •! Reassembly at endpoints •! Assure correctness by implementing complete protocol •! Optimize common cases to avoid full complexity 15 16 4 Internet Control Message Protocol (ICMP) IP MTU Discovery with ICMP • Short messages used to send error & other control ! MTU = information 2000! host! router! •! Examples router! MTU = 1500! host! •! Ping request / response MTU = 4000! •! Can use to check whether remote host reachable •! Typically send series of packets from one host to another •! Destination unreachable •! Indicates how packet got & why couldn’t go further •! Typically, all will follow same route •! Flow control •! Routes remain stable for minutes at a time •! Slow down packet delivery rate •! Makes sense to determine path MTU before sending real packets •! Redirect •! Operation •! Suggest alternate routing path for future messages •! Send max-sized packet with “do not fragment” flag set •! Router solicitation / advertisement •! If encounters problem, ICMP message will be returned •! Helps newly connected host discover local router •! “Destination unreachable: Fragmentation needed” •! Timeout •! Usually indicates MTU encountered •! Packet exceeded maximum hop limit 17 18 IP MTU Discovery with ICMP IP MTU Discovery with ICMP ICMP" ICMP" Frag. Needed" Frag. Needed" MTU = 2000" MTU = MTU = 1500" MTU = 2000! host! 2000! host! router! router! router! MTU = 1500! router! MTU = 1500! host! host! MTU = 4000! MTU = 4000! ’ Length = 4000, Don’t Fragment! Length = 2000, Don t Fragment! IP" IP" Packet" Packet" 19 20 5 IP MTU Discovery with ICMP Outline MTU = 2000! host! router! router! MTU = 1500! •! IP Packet Format host! MTU = 4000! Length = 1500, Don’t Fragment! •! IPv6 IP" Packet" • NAT •! When successful, no reply at IP level ! •! “No news is good news” •! Higher level protocol might have some form of acknowledgement 21 22 IPv6 IPv6 Addressing •! “Next generation” IP. •! Do we need more addresses? Probably, long term •! Most urgent issue: increasing •! Big panic in 90s: “We’re running out of addresses!” address space. •! Big worry: Devices. Small devices. Cell phones, toasters, •! 128 bit addresses V/Pr Flow label everything. •! Simplified header for faster Length Next Hop L •! 128 bit addresses provide space for structure (good!) processing: •! Hierarchical addressing is much easier •! No checksum (why not?) •! Assign an entire 48-bit sized chunk per LAN – use Ethernet •! No fragmentation (?) addresses Source IP address •! Support for guaranteed •! Different chunks for geographical addressing, the IPv4 address services: priority and flow id space, •! Perhaps help clean up the routing tables - just use one huge chunk •! Options handled as “next per ISP and one huge chunk per customer. header” Sub •! reduces overhead of handling Destination IP address 010 Registry Provider Subscriber Host options Net 23 24 6 IPv6 Autoconfiguration IPv6 Cleanup - Router-friendly •! Common case: Switched in silicon (“fast path”) •! Serverless (“Stateless”). No manual config at all. •! Weird cases: Handed to CPU (“slow path”, or “process •! Only configures addressing items, NOT other host things switched”) •! If you want that, use DHCP. •! Typical division: •! Fast path: Almost everything •! Link-local address •! Slow path: •! 1111 1110 10 :: 64 bit interface ID (usually from Ethernet addr) •! Fragmentation •! (fe80::/64 prefix) •! TTL expiration (traceroute) •! Uniqueness test (“anyone using this address?”) •! IP option handling •! Slow path is evil in today’s environment •! Router contact (solicit, or wait for announcement) •! “Christmas Tree” attack sets weird IP options,

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    11 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us