Chapter 4: Internetworking

1. Chapter 4: Internetworking CS 332

2. Assumptions • Data pipe from every machine to every other machine. • Need not be single link (and in most cases will involve several links and several networks). • Pipe can lose or corrupt messages (think postal system analogy – vast majority of time it arrives, but not always). • So what info do we need to build a single “logical” network (either reliable or unreliable)? CS 332

3. Issues • Getting various technologies to work with one another (I.e. creating a single “network” from many heterogeneous systems). • Problem magnified since packet may need to traverse several different networks (and network technologies), each with their own addressing schemes, service models, media access protocols, etc. • Scale: It’s the big issue • How can you find an efficient path through a network with millions (and perhaps billions eventually) of nodes? • How do you provide addressing for a network with this many nodes? CS 332

4. Chapter 4 Outline • The Internet Protocol (IP) Version 4 • Routing • IPv6 • Multicast The present set of slides. CS 332

5. Internetwork: • Arbitrary collection of possibly heterogeneous networks interconnected to provide host-to-host packet delivery service. • Network: Directly connected or switched network that uses a single technology (i.e. ATM, 802.5, Ethernet). • Could be many physical networks creating a single logical network. CS 332

6. Internetwork • Internet—THE internetwork. • Runs the Internet Protocol (Kahn-Cerf) • Interesting because it has faced the problems of scale • internet—abstract internetwork CS 332

7. IP Internet Note Hn denotes host, Rn denotes router. • Concatenation of Networks CS 332

8. H1 H8 TCP TCP R1 R2 R3 IP IP IP IP IP FDDI PPP ETH ETH ETH FDDI PPP ETH IP Internet • Protocol Stack CS 332

9. The Internet Outline Best Effort Service Model Global Addressing Scheme CS 332

10. Service Model • Connectionless (datagram-based) • So each packet must be “self-contained” • Best-effort delivery (unreliable service) • packets are lost • packets are delivered out of order • duplicate copies of a packet are delivered (?!) • packets can be delayed for a long time CS 332

11. Why?! • Best Effort service model is as simple a model as you could want, and this is a strong point! • If you provide best effort service over a network technology that provides reliable delivery, you’re fine • If you provide reliable delivery over a network technology that is unreliable, then you’ve got a problem: you need lots of extra functionality in the routers to handle the network deficiencies, and keeping the routers as simple as possible was an IP design goal. (Why?) • Note: IP today runs over many technologies that were not in existence when IP was invented! CS 332

12. 0 4 8 16 19 31 In 32 bit words TOS Length V ersion HLen In bytes Ident Flags Offset TTL Protocol Checksum SourceAddr DestinationAddr Pad Options (variable) (variable) Data IP Datagram Format Note: fields aligned on 32 bit boundaries CS 332

13. Fields • Version: note placement at front of packet (why?) • Header Length: in 32 bit words (20 bytes when no options) • Type of service: later • Length: of entire packet in bytes (note max of 65,535 bytes because of 16 bit length field) • Ident, flags, offset all deal with fragmentation • Time to live: first seconds, but evolved to be hop count CS 332

14. Fields • Protocol: demux key specifying higher level protocol that gets datagram • Checksum: take IP header as sequence of 16 bit words, add them using ones complement, take ones complement of result. • Relatively easy to calculate in software • Not as strong error detection as CRC • Bad packets discarded • Src, dest address: pretty clear (and these are unique!) • Options: rare, but complete IP implementation must handle them all! Presence determined by header length field CS 332

15. Fragmentation and Reassembly • Each network has some MTU (why?) • Why not some uniform standard? • What is a reasonable choice for a given host? • Strategy • fragment when necessary (MTU < Datagram length) • try to avoid fragmentation at source host • re-fragmentation is possible • fragments are self-contained datagrams • delay reassembly until destination host • do not recover from lost fragments CS 332

16. Fragmentation and Reassembly • Ident field: chosen by sending host, intended to be unique among all datagrams that might be received at this dest from this source over reasonable time period. • All fragments keep this same ident value • Offset: specifies 8 bytes chunk of data (why?) • Flags: M is “more” flag CS 332

17. Start of header Ident = x Offset = 0 0 Rest of header MTU 532 bytes 1400 data bytes Start of header Ident = x 1 Offset = 0 Rest of header 512 data bytes Start of header Ident = x 1 Offset = 512 Rest of header 512 data bytes Start of header Ident = x 0 Offset = 1024 Rest of header 376 data bytes Example Note: fragmentation can occur at multiple hops! CS 332

18. 7 24 A: 0 Network Host 14 16 B: 1 0 Network Host 21 8 C: 1 1 0 Network Host Global Addresses • Properties • globally unique (don’t want anyone with my phone #) • Why not just use Ethernet address?! • hierarchical: network + host (really interface) • Dot Notation • 10.3.2.4 • 128.96.33.81 • 192.12.69.77 CS 332

19. IP Internet Note Hn denotes host, Rn denotes router. Routers need two IP addresses. All hosts on same network have same network part of IP address CS 332

20. Terminology • Routing Mechanism: How a router selects the link over which to forward a packet • Routing Protocol: Policies that determine what is placed in the routing tables. These are not the same thing! CS 332

21. Datagram Forwarding • Strategy • every datagram contains destination’s address • if directly connected to destination network, then forward to host • if not directly connected to destination network, then forward to some router • forwarding table maps network number into next hop • each host has a default router • each router maintains a forwarding table • Example (R2) Network Number Next Hop 1 R3 2 R1 3 interface 1 4 interface 0 CS 332

22. Network 1 (Ethernet) H7 R3 H8 H2 H1 H3 Network 4 (point-to-point) Network 2 (Ethernet) R1 R2 H4 Network 3 (FDDI) H5 H6 Recall: CS 332

23. Pseudocode if (networknum dest = networknum my interface) deliver packet over that interface else if (networknum in my routing table) deliver packet to next hop router else deliver packet to default router CS 332

24. Address Translation • Map IP addresses into physical addresses • destination host • next hop router • Why not just broadcast it? (E.g. if physical network is Ethernet). • Techniques • encode physical address in host part of IP address • table-based • ARP • table of IP to physical address bindings • broadcast request if IP address not in table • target machine responds with its physical address • table entries are discarded if not refreshed CS 332

25. ARP Details • Request Format • HardwareType: type of physical network (e.g., Ethernet) • ProtocolType: type of higher layer protocol (e.g., IP) • HLEN & PLEN: length of physical and protocol addresses • Stands for “hardware address length” and “protocol address length” • Operation: request or response • Source/Target-Physical/Protocol addresses • Notes • table entries timeout in about 10 minutes • update table with source when you are the target (why?) • update table if already have an entry • do not refresh table entries upon reference CS 332

26. 0 8 16 31 Hardware type = 1 ProtocolT ype = 0x0800 HLen = 48 PLen = 32 Operation SourceHardwareAddr (bytes 0 – 3) SourceHardwareAddr (bytes 4 – 5) SourceProtocolAddr (bytes 0 – 1) SourceProtocolAddr (bytes 2 – 3) T argetHardwareAddr (bytes 0 – 1) T argetHardwareAddr (bytes 2 – 5) T argetProtocolAddr (bytes 0 – 3) ARP Packet Format CS 332

27. Dynamic Host Configuration Protocol (DHCP) • Manually configuring IP information can be hard • Large networks (lots of hosts, many of which are unreachable until configured!) • Configuration process error prone • Every host needs correct network number • No two hosts can have same IP address • DHCP automates process • Important aspect of scaling: scaling of network management! CS 332

28. DHCP (continued) • At least one DHCP server per administrative domain • Centralized repository for host configuration info • Info can be sent to hosts at boot or connection time. • Can also be used to maintain pool of available addresses assigned on demand • Method • Send DHCPDISCOVER msg to 255.255.255.255. • Relay agents CS 332

29. 0 7 8 15 16 31 type code checksum Contents depends on type and code Internet Control Message Protocol (ICMP) • Communicates error messages and other conditions that require attention • ICMP messages are acted on by either the IP layer or higher layers (TCP or UDP). • Transmitted within IP datagrams CS 332

30. ICMP (cont.) • 15 different values for the type field, then several codes for each of the types • Checksum computed same as for IP packet • Complete specification of protocol is RFC 792 (Postel) • Another good source is TCP/IP Illustrated, Vol. 1, Ch. 6 CS 332

31. Types of ICMP Messages • Echo (ping) • Redirect (from router to source host) • Destination unreachable (protocol, port, or host) • TTL exceeded (so datagrams don’t cycle forever) • Checksum failed • Reassembly failed • Cannot fragment CS 332

32. Virtual Private Networks (VPNs) You read about them! CS 332