Network Layer: Miscellaneous

1. Network Layer: Miscellaneous UIUC CS438: Communication Networks Summer 2014 Fred Douglas Slides: Fred, Kurose&Ross(some edited), Caesar&many others (also edited)

2. Details of IPv4 vs IPv6

3. IP protocol version number (so, always 4) 32 bits total datagram length (bytes) header length (indicates options) type of service head. len ver length for fragmentation/ reassembly fragment offset For QoS flgs 16-bit identifier Max remaining hops packet can traverse before being dropped (-1 at each router) upper layer time to live header checksum 32 bit source IP address 32 bit destination IP address upper layer protocol to deliver payload to (UDP, TCP) e.g. timestamp, record route taken, specify list of routers to visit. NOT USED IN PRACTICE options (if any) data (variable length, typically a TCP or UDP segment) IPv4 datagram format

4. IPv6: motivation • initial motivation:32-bit IPv4 address space “soon” to be completely allocated. • people have been saying this for over a decade, but still • additional motivation: streamlining • simplified header format helps speed forwarding • fixed-length header • fragmentation of IP datagrams no longer allowed • no more checksum • recognizes that “IP[v4] Options are not an option”* • options are modular, rather than embedded in IP header *Rodrigo Fonseca, George Manning Porter, Randy H. Katz, Scott Shenker and Ion Stoica, 2005 Tech Report

5. IPv6 datagram format traffic class:QoS (6 bits), ECN (2 bits) flow Label: identify datagrams in same “flow.” next header:combines IPv4 “upper layer” and “options” -this approach allows a fixed-length IPv6 header, so we drop the “header len” t.c. ver flow label this = 6 like TTL hop limit payload len next hdr size of this datagram’s payload source address (128 bits) destination address (128 bits) data 32 bits

6. Other changes from IPv4 • checksum:removed entirely to reduce processing time at each hop • options: allowed, but outside of header, indicated by “Next Header” field • ICMPv6: new version of ICMP • additional message types, e.g. “Packet Too Big” • (to replace fragmentation) • multicast group management functions • ??? multicast? Later this lecture.

7. Transition from IPv4 to IPv6 • not all routers can be upgraded simultaneously • no “flag days” • how will network operate with mixed IPv4 and IPv6 routers? • tunneling: IPv6 datagram carried as payload in IPv4 datagram among IPv4 routers

8. logical view: (acts as IPv4 sender) B (acts as IPv4 receiver) E IPv6 header fields IPv6 source dest addr A A E B F F UDP/TCP payload IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 IPv4 payload Tunneling IPv4 header fields IPv4 source, dest addr IPv6 datagram IPv4 datagram “Internet” C D physical view: IPv4 IPv4

9. Flow: X Src: A Dest: F data Flow: X Src: A Dest: F data IPv4 tunnel connecting IPv6 routers logical view: A A E E B B F F IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 src:B dest: E src:B dest: E flow: X src: A dest: F data flow: X src: A dest: F data A-to-B: IPv6 E-to-F: IPv6 B-to-C: IPv6 inside IPv4 B-to-C: IPv6 inside IPv4 Tunneling C D physical view: IPv4 IPv4

10. Transition from IPv4 to IPv6 • not all routers can be upgraded simultaneously • no “flag days” • how will network operate with mixed IPv4 and IPv6 routers? • tunneling: IPv6 datagram carried as payload in IPv4 datagram among IPv4 routers • dual stack: router translates packets when forwarding to a non-v6-enabled neighbor

11. A E B F IPv6 IPv6 IPv6 IPv6 Dual Stack • Just translate the IPv6 header to an equivalent v4 one • How to translate addresses? v4.ad.dr.es  ::ffff:v4.ad.dr.es C D logical and physical view: IPv4 IPv4 v6 packet v6 packet v4 packet v4 packet translate translate

12. IPv6: adoption • US National Institutes of Standards estimate [2013]: • ~3% of industry IP routers • ~11% of US gov’t routers • Long (long!) time for deployment, use • 20 years and counting! • think of the application-level changes of the last 20 years • The WWW • Peer-to-peer systems • Streaming video • Social networks • Smartphones joining the internet • … • This demonstrates network layer ossification

13. ICMP

14. used by hosts & routers to communicate network-level information error reporting: unreachable host, network, port, protocol echo request/reply (used by ping) network-layer “above” IP: ICMP msgs carried in IP datagrams ICMP message: type, code plus first 8 bytes of IP datagram causing error ICMP: internet control message protocol TypeCodedescription 0 0 echo reply (ping) 3 0 dest. network unreachable 3 1 dest host unreachable 3 2 dest protocol unreachable 3 3 dest port unreachable 3 6 dest network unknown 3 7 dest host unknown 4 0 source quench (congestion control - not used) 8 0 echo request (ping) 9 0 route advertisement 10 0 router discovery 11 0 TTL expired 12 0 bad IP header Network Layer

15. source sends series of UDP segments to dest first set has TTL =1 second set has TTL=2, etc. unlikely port number when nth set of datagrams arrives to nth router: router discards datagrams and sends source ICMP messages (type 11, code 0) ICMP messages includes name of router & IP address when ICMP messages arrives, source records RTTs Traceroute and ICMP stopping criteria: • UDP segment eventually arrives at destination host • destination returns ICMP “port unreachable” message (type 3, code 3) • source stops 3 probes 3 probes 3 probes Network Layer

16. Multicast

17. legend group member not group member router with a group member router without group member source-based trees Multicast routing: problem statement • goal: broadcast without flooding • approach: build a multicast tree that reaches every recipient • shared-tree:same tree used by all group members • source-based:different tree from each sender shared tree

18. Approaches for building mcast trees approaches: • source-based tree: one tree per source • reverse path forwarding • group-shared tree: group uses one tree • minimal spanning (Steiner) • center-based trees

19. Reverse path forwarding receive mcast packet p from sender s if (p arrived on the interface we use to reach s) flood p onto all (other) links else ignore datagram • rely on router’s knowledge of unicast shortest path from it to sender • each router has simple forwarding behavior:

20. Reverse path forwarding: example s: source LEGEND R1 R4 router with attached group member R2 router with no attached group member R5 datagram will be forwarded R3 R7 R6 datagram will not be forwarded

21. Reverse path forwarding: pruning • forwarding tree contains subtrees with no mcast group members • no need to forward datagrams down subtree • “prune” msgs sent upstream by router with no downstream group members s: source LEGEND R1 R4 router with attached group member R2 P router with no attached group member R5 P prune message R3 P links with multicast forwarding R6 R7

22. Shared-tree: steiner tree • steiner tree: minimum cost tree connecting all routers with attached group members • problem is NP-complete • excellent heuristics exists • not used in practice: • computational complexity • information about entire network needed • monolithic: rerun whenever a router needs to join/leave

23. Center-based trees • single delivery tree shared by all • one router identified as “center” of tree • to join: • edge router sends unicast join-msg addressed to center router • join-msg “processed” by intermediate routers and forwarded towards center • join-msg either hits existing tree branch for this center, or arrives at center • path taken by join-msg becomes new branch of tree for this router

24. Center-based trees: example suppose R6 chosen as center: LEGEND R1 router with attached group member R4 3 router with no attached group member R2 2 1 R5 path order in which join messages generated R3 1 R6 R7