Week 6: Oct 1, 2008 Midterm in two weeks, October 15 See study guide online; note that answers are also posted! IP fragmentation review Subnets IP routing: Distance Vector, slow convergence Intro to TCP ====================================================================================== IP reassembly: * at IP level, done ONLY at final destination * routers MAY negotiate a link-specific fragment/reassemble protocol; IP fragmentation/reassembly is a "last resort" * Algorithm design is to support multiple fragmentation, single reassembly * Offsets are 13 bits; packet lengths are 16 bits. Multiple-of-8 rule ====================================================================================== 4.1.4: IP routing host algorithm: deliver directly or to router router: try in order: host-specific, local, net, default why host-specific comes before local Default routes How a packet traverses layers, with headers; routing A net 200.3.9 router net 201.4.6 B |_________________________| |___________________| 200.3.9.5 200.3.9.254 201.4.6.1 201.4.6.7 4.3.1: subnets What if our site has more than one physical LAN? Or is really too big for one physical lan? The latter is Loyola's situation. Getting an IP network number for each subnet: bad for routers, and bad politically Subnets: further routing within the IP_net site "Site" may mean different things, but once the packet has been delivered to the IP_net border router, further routing within the subnet should NOT involve the outside Internet! routing and subnets: moving the IP_net division line RIGHTWARD! subnets versus: bridging multiple IP networks Basic example: divide a class-B into 256 "class-C subnets", on byte boundaries. If a node doesn't know it is on a subnet, it will assume it can deliver locally packets that in fact cannot be so delivered. Nodes know they are on subnets by virtue of having a SUBNET MASK. subnets and local delivery consequences of misconfigured masks variable-sized subnet mask 4.3.1: Division of a class-C into subnets of size 70, 40, 25, and 20. 4.2: routing-table algorithms: 4.2.2: distance vector routing (Routing Information Protocol, RIP) Table exchange: updates in three cases: new node reported decreased distance to existing node reported NOTE: these are the "no-bad-news" cases for which convergence happens because the distances are monotonically decreasing (or the same). If all hopcounts are 1, shortest path is the first discovered. *increased* distance reported by NextHop for that node ============= IP router table construction UDP ARP/DHCP 4.1.5: ARP Basic ideas: broadcast request/unicast reply, cache ICMP Destination Host Unreachable if nobody answers Timeout: used to be ~10 minutes (20 min for early linux), now is much less (linux 2.4 arp timeout is ~60 seconds) Alternatives: polling, link-layer notice, IP-layer notice finer points: If A arps "where is B?" 1. B always puts A in its cache 2. All hosts with A in their cache update the entry Self-arp: detects duplicates, ethernet addr changes Flooding: what if A tries to send 100 packets to B; how many ARPs? A b'casts, everyone replies & needs to ARP to get A's addr ARP and networks without b'cast [eg ATM] Failure in presence of looping security implications of ARP proxy arp DHCP; once known as Reverse ARP (RARP) You b'cast your Ethernet addr, and hope a DHCP server finds it and sends you your IP address. Also other helpful startup options!!! subnet mask default router DNS Server =============================================================== 4.2.2: distance vector routing (used by Routing Information Protocol, or RIP) Routing tables add a third column, "cost" (or "distance") Neighbors exchange tables ("vectors", since they're lists) Table exchange: the local table is updated in three cases: new node reported by neighbor decreased distance to existing node reported NOTE: these are the "no-bad-news" cases for which convergence happens because the distances are monotonically decreasing (or the same). If all hopcounts are 1, shortest path is the first discovered. *increased* distance reported by NextHop for that node Slow convergence problem D-------A----------B ;; "dir": directly connected D---x---A----------B ;; "dir": directly connected small infinity, triggered updates RIP: infinity=16, updates every 30 sec Cisco IGRP: infinity <= 256; default = 100 Fixes: small infinity, split horizon, (don't report reachability to your own NextHop for a node) poison reverse, (claim a node to be at distance infinity, when reporting to your own NextHop for that node) triggered updates: send report immed. on any change hold down, (*receiver* doesn't use new alternate routes for ~60 sec following discovery of unreachability) route poisoning: hold down only for changes that increase hop count =========================================== Chapter 5: transport UDP - P&D 5.1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ unreliable, unconnected (stateless). General uses: NFS, boot, RPC checksum & algorithm checksum can also be updated; eg in IP header 0000 checksum never occurs naturally, can be used as "checksum not used" pseudo-header: include some IP header fields in UDP checksum ports & final destinations lost packets due to queue overflow (skipped) at router at host socket programming interface (P&D 1.3) // done in java udpclient/udpserver simpletalk client, server: TCP and UDP versions socket, bind, sockaddr_in, gethostbyname, Note how socket programming interface corresponds to the actual options: * create a socket * ask for a specific port number * send or receive ========================================================================= TCP - P&D 5.2 more semantic issues: connected v connectionless connection is between two sockets: a socketpair one socket on host A can be part of multiple distinct socketpairs reliable v unreliable stream v packets what TCP does; header fields TCP Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format connection establishment Logical issue of what is a "connection" connection state on top of stateless lower layer basic strategy of 3-way handshake ISN issue outline versus one 2-way handshake TCP sliding windows mostly done earlier basic outline examples, window-size flow control fast sender, slow receiver fast receiver, slow sender slow router Keeping the pipe full: bandwidth*delay! p. 301 eoc: just got to TIMEWAIT and final ACK Introduction to TCP state diagram, as far as connection establishment Initial Sequence Numbers (ISNs) SYN, ACK, FIN, RST packets TIMEWAIT and final ACK again old late duplicates problem: TIMEWAIT again! what a connection is: machine state at each endpoint TCP should handle: lost packets damaged packets reordered packets duplicated packets widely varying delay OLD LATE DUPLICATES problem TCP example ISN negotiation, choice MSL TIMEWAIT TIMEWAIT and final ACK ISN rationale 1: old late duplicates ISN rationale 2: distinguishing new SYN from dup SYN From Dalal & Sunshine's original paper on the TCP 3-way handshake: 2-way handshake: can't confirm both ISNs 4-way handshake: 1 --SYN-> 2 <-ACK-- 3 <-SYN-- 4 --ACK-> FAILS if first SYN is very very old The ack at line 2 is ignored. LHS thinks the SYN on line 3 is a new request, and so it acks it. It would then send its own SYN (on what would be line 5), but it would be ignored. At this point A and B have different notions of ISN_A. 3-way handshake