Test Results A A- A- A+ A+ B B+ B+ C C C C- C+ D D+

1. Test Results • A • A- • A- • A+ • A+ • B • B+ • B+ • C • C • C • C- • C+ • D • D+

2. Address Resolution Protocol ARP • RFC 826. • TCP/IP addresses are 32 bits and represent a network, subnet, and host ID. • Addresses on LANs are represented by physical (MAC) layer addresses and they are 48 bits in length. • ARP provides the mapping between a host’s 32-bit IP address and its 48-bit MAC address. • ARP works only on the local subnet (it cannot traverse routers). • ARP builds a table of IP/MAC addresses to properly format a source and destination address field in a packet.

3. ARP Packet Format Type of hardware Type of protocol Length of header Length of protocol address Operation Hardware address of the source station Protocol address of the source station Hardware address of the destination station Protocol address of the destination station CRC Data DA SA TF

4. ARP Operation Here is my MAC address Give me the MAC address of station 129.1.1.4 ARP Request Not me Not me B 129.1.1.1 C 129.1.1.4 ARP Response Accepted Request Ignored Request Ignored That’s me

5. ARP RULE SET • ARP does not run on top of IP and therefore has no IP headers. • ARP requests are transmitted in broadcast so that all stations receive the packet. • New EtherType defined 0x0806 for both the ARP request and reply. • ARP replies are sent directly to the requesting station (unicast, not broadcast). • ARP tables should age out their entries. • An attachment should answer an ARP sent to itself.

6. Reverse Address Resolution Protocol (RARP) RARP Response Give me my IP address 129.1.1.1 Not me Not me RARP Request Diskless Workstation RARP Server B C RARP Response Accepted Request Ignored Request Ignored • Same packet type used as ARP • Only works on local subnets • Used for diskless workstations 6

7. Proxy ARP 130.1.2.1 ARP for 130.1.1.1 No subnetting Proxy ARP Enabled Answers for 130.1.1.1 130.1.1.1 255.255.255.0

8. Extending the Life of the IPv4 Address Space • Original RFC for IP was RFC 760. • No concept of classes; address was 8-bit network ID • RFC 791 introduced a segmentation of the address into Classes. • RFC 950 introduced subnetting. • Allowed for efficiency to exist with Class addresses • RFCs 1517–1520 introduced CIDR. • Used on the Internet routing tables

9. Special notes: • Ping of Death? • C++ double pointer trick. • Since a struct is passed by value, and an array is passed by reference, how is an array that is a member of a struct passed?

10. Using a pointer to a pointer to increment through a two dimensional array (avoids passing an array). • Basic technique: two dim array; an array of pointers to the elements of that array and a single double pointer which points to the array of pointers. • Let the array of pointers ‘point’ to each of the rows of the two dim array. • Then the double pointer points to the array of pointers. • Therefore when the double pointer is passed it may be dual indexed to access the two dim array members.

11. Void examp (unsigned char **passed_doub_ptr) { int k, l; unsigned char samp_char; for (k = 0; k < 10; k++) { for (l = 0; l < 10; l++) { samp_char = passed_doub_ptr [k] [l]; // deref with brackets or with // ** not BOTH.

12. Multicasting and broadcasting. (chapters 18 and 19) • Everything we’ve done so far deals with unicasting: a process talking to exactly on other process. • TCP works only with unicast addresses while UDP supports other paradigms. • One use for broadcasting is to locate a server on the local subnet when the server is assumed to be on the subnet but its unicast IP address is not known. • Another use would be to minimize traffic on a LAN when there are multiple clients communicating with a single server.

13. Some Internet apps which use broadcasting: • ARP: while not an app ARP broadcasts “will the system with the IP address of x.y.z.v please identify and transmit a hardware address”. • BOOTP: Client assumes a server is on the subnet and sends its request to the broadcast address (often 255.255.255.255). (this is when the client doesn’t know its IP, mask or the broadcast IP of the subnet). • NTP or Network Time Protocol. Server broadcasts time every 64 seconds. • Routing Daemons: routed, most commonly used routing daemon broadcasts its routing table on the LAN. This is done to facilitate the configuration of neighboring routers.

14. Broadcast Addresses • IP address consists of (netid, subnetid, hostid). • Therefore there are four types of broadcast addresses. • 1) Subnet directed broadcast addresses of the general form [netid, subnetid,255]. This will address all of the interfaces on the specified subnet. • Example: 128.7.6.255 (class B address of 128.7) would mean all hosts on the 128.7.6 subnet. • Normally routers do NOT forward these broadcasts.

15. 4 types of broadcast addresses continued: • All subnets directed broadcast address of the general form [netid, 255, 255]. This would be used to address all subnets on a specified network. • Network directed broadcast address. [netid,255]. Used on a network with no subnetting, rarely used in the current era since almost all networks are subnetted. • Limited broadcast address: [-1,-1,-1]. Datagrams destined to this address must NEVER be forwarded by a router.

16. Unicast versus Broadcast • Unicast flow on UDP. • App on left calls sendto on a UDP socket. • UDP layer prepends a UDP header and passes the UDP datagram to the IP layer. • IP prepends an IPV4 header, determines the outgoing interface (assuming Ethernet). • ARP is invoked to determine the Ethernet address corresponding to the IP address. • Packet is then sent as an Ethernet frame with that determined 48 bit address as the destination. • The middle Ethernet host compares the frame address as it passes and ignores the frame. • No overhead to this host.

17. The Ethernet host on the right sees the frame and realizes the address of the frame it its own. • Interface reads the frame, gens a hardware interrupt when the frame is complete and the device driver reads the frame from the interface memory. • The packet is now in the IP input queue. • When the IP layer processes the packet, it first compares the the destination IP with all its IPs (may be multihomed). • The packet is then accepted. • Since the IP has 17 in the protocol field of the header the packet is then passed to the UDP layer. • UDP then, using the 4 tuple places the datagram into the correct socket receive queue.

18. Datagram = UDP Packet = IP Frame = Ethernet • Couple of important concepts. Three headers present at the transmitted level: UDP Header IPv4 Header Ethernet Header

19. Same example with a subnet-directed broadcast address (128.7.6.255) • Host on left sends datagram. When it maps the IP onto the Ethernet address it receives the Ethernet address of FF:FF:FF:FF:FF:FF (48 1 bits). • In this example BOTH hosts will pass the packet to the IP layer. • Both hosts pass the packet to the UDP layer. • Host on right passes the datagram to the application that has bound UDP port 520. • Nothing special has to be done by any application to receive a broadcast UDP (just create a UDP socket and bind the app’s port number to the socket).

20. For the host in the middle however, no application has bound UDP port 520. • The host’s UDP layer code then discards the datagram. • This host MUST NOT send an ICMP port unreachable as a datastorm may result. • The sender port also receives the datagram. • This shows the fundamental problem with UDP broadcast; EVERY HOST ON THE NETWORK MUST MUST COMPLETELY PROCESS THE UDP DATAGRAM ALL THE UP THE PROTOCOL STACK TO THE UDP LAYER BEFORE DISCARDING THE DATAGRAM. • THIS INCLUDES NON-IP HOSTS.

21. Multicasting addresses this problem. • As a side note it might be added that Berkeley derived kernels do not allow a broadcast datagram to be fragmented. • Will receive the ‘sendto error’: Message too long. • Race conditions: not related to country or ethnicity. • Will cover in regards signals upon the first class after the test.

22. MULTICASTING. • A Multicast address identifies a set of interfaces (not all and not one). • Multicasting support in IPv4 is optional. • Multicasting can be done on a WAN. Broadcasting is directed at a LAN • Five socket options are added to the API to support multicasting. • Class D addresses (224.0.0.0 through 239.255.255.255) are the multicast addresses in IPv4. • TCP does NOT support multicast or broadcast.

23. Multicast. • The low-order 24 bits of the class D address form the multicast group ID. The 32 bit address is referred to as the group address. • Page 488 depicts the mapping of a multicast address into an Ethernet address. • Basically 32 multicast addresses map to a single Ethernet address. • The low order two bits the first byte of the Ethernet address identify the address as a universally administered group address.

24. Some special IPv4 multicast addresses. • 224.0.0.1 is the all-hosts group. All multicast hosts on a subnet must join this group on all multicast capable interfaces. • 224.0.0.2 is the all-routers group. All multicast routers on a subnet must join the group on all multicast capable interfaces. • Nothing special is required to send a multicast datagram; the application does NOT have to join the multicast group. • Because of ‘imperfect filtering’ when an interface is told to receive group frames it may receive frames directed for other groups.

25. Multicast: • The IP layer, once it receives the packet from the datalink layer, compares the IP address against all the multicast addresses that applications on the host have joined. • This is perfect filtering. • Mulitcasting on a single LAN is simple; one host sends a multicast packet and any interested host receives the packet. • On a WAN there must be a multicast routing protocol (MRP). • When a process on a WAN joins a multicast group the host sends an IGMP message to any attached routers. • Multicast routing is still a research topic.

26. UDP • Sidebar on the historical basis of computing. • "Who controls the past commands the future. Who commands the future conquers the past." • -George Orwell

27. UDP RFC 768 J. Postel ISI 28 August 1980 User Datagram Protocol ---------------------- Introduction ------------ • This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) [1] is used as the underlying protocol. This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) [2].

28. UDP • User Datagram Header Format Fields ------ Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted.

29. Destination Port has a meaning within the context of a particular internet destination address. • Length is the length in octets of this user datagram including this header and the data. (This means the minimum value of the length is eight.) • Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. • The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP.

30. UDP • When the UDP checksum is calculated, it includes not only the UDP header, and the UDP data, but also fields from the IP header. • These additional fields form the pseudo header. • The purpose of the pseudo header is to verify that if the checksum is correct then the datagram was delivered to the correct host and to the correct protocol code.

31. Many applications employ UDP instead of TCP: DNS, NFS, SNMP. • In UDP Clients do NOT establish a connection with the server. • Clients only use the ‘sendto’ function while servers only employ the recfrom function. • recvfrom returns the protocol address of the client along with the datagram, so the server can send a response to the correct client. • recvfrom (sockfd, void *buff, size_t nbytes, int flags, struct sockaddr *from, socklen *addrlen) • sendto( sockfd, const void *buff, size, flags, const struct sockaddr *to, socket_length addrlen)

32. The recvfrom and sendto functions are very similar to the familiar read and write functions. • FLAGS • MSG_DONTROUTE by pass routing table lookup (send) • MSG_DONTWAIT only this op is nonblocking (recv) • MSG_OOB send or receive out of band data (send/recv) • MSG_PEEK peek at incoming message (recv) • MSG_WAITALL wait for all the data (recv)

33. Given the following; • DHCP running on your windows box (Dynamic Host Configuration Protocol).

34. Given: your platform does not have an IP. • Question: So how does it form a connection? • Answer: It does a UDP broadcast message which asks for a DHCP server. • The DHCP server answers and returns an IP address to the platform. • Which means that we must have an understanding of UDP.

35. UDP: selected readings from Chapter 8. • UDP is a connectionless, unreliable, datagram protocol. • Several important applications require UDP: DNS, NFS, and SNMP (Simple Network Management Protocol). • In UDP the client does not establish a connection with the server; instead the client simply sends a message with the server address as a parameter. • The server does not accept a connection; instead it waits on the recvfrom function until data arrives from some client. • recvfrom returns the protocol address of the client as well as the actual datagram. Hence the server can send a response.

36. UDP does use the IP address the same as TCP. • Similarly a socket address structure is employed. • The two primary functions used in simple UDP are; ssize_t, sendto (int sockfd, const void *buff, size_t nbytes, int flags, const struct sockaddr *to, socklen_t addrlen); ssize_t, recvfrom (int sockfd, const void *buff, size_t nbytes, int flags, struct sockaddr *from, socklen_t addrlen); • note that the sockfd is used similar to connect. • The sockfd value will be returned by the socket function per its use in the TCP client and server code.

37. The flags argument is interesting (chapter 13, pg 355). • The flags argument is either 0 or is formed by logically OR’ing the following constants. MSG_DONTROUTE - bypass routing table MSG_DONTWAIT - only this operation is non-blocking MSG_OOB - send or receive out-of-band data MSG_PEEK - peek at incoming message MSG_WAITALL - wait for all the data. The flags arg can only be used to pass data from the process to the kernel.

38. The to arg is a socket address structure which contains the protocol address structure (IP/port) where the data is to be sent. • The size of the address structure is indicated by addrlen. • The recvfrom function fills in the struct pointed to by from with the address of who sent the datagram. • sockfd is the integer descriptor for the particular socket, buff is the location of the data and nbytes is the size of the data sent or received. • If the from arg is a null ptr then the addrlen is a null pointer which indicates that the server is not interested in knowing who sent the data.

39. Similar to TCP a UDP server will bind to a specific port. • With a UDP client the bind is rarely used; when the client invokes sendto the ephemeral port is assigned by the kernel. • UDP is not reliable, hence datagrams can become ‘lost’. This means that the client could block forever in its call to recvfrom. • There are techniques such as employing a timer which will keep a UDP client or server from blocking forever. Most importantly however UDP will never know if a datagram either never made it to a server or the server reply never made it back. • There are schemes to add reliability to UDP. However they are convoluted in the extreme.

40. Verifying received response in UDP • With UDP any process which knows the client ephemeral port number can send datagrams. These will be intermixed with those from the server. Inducing a form of chaos (looking at the tracks will not tell you which way the train went). • Effected via changing the recvfrom call to return the IP/port of who sent the reply. • Now ignore all datagrams from any server which does not have this pattern. Demultiplexing at the process level. • The example (pg 219) uses memcmp to compare the two socket address structures.

41. Demulitplexing UDP responses (continued) if ( len != servlen || memcmp(pseraddr, preply_addr, len) != ) { errror_out; • one signifcant problem (among others); what if the server is on a host which does NOT use a single IP address (multihomed server). In this case the server did not bind or used the wildcard address). • One solution is for the client to use the host name instead of the IP (employ DNS lookup). • Another solution is for the server to bind to every IP address on the host and then use select to appropriately respond when it becomes readable.

42. What if the server is not running in a UDP environment? The client could block forever. • First we should recall the Address Resolution Protocol (ARP). This protocol maps an IPv4 address onto a hardware address (MAC address). ARP is normally used on broadcast networks such as 802.3, .4 and FDDI (not needed on point to point networks such as 802.5) • First note; none of my available Unix systems employ tcpdump. However netXray will show the arp packets running. • Typically, an ARP request / reply pair are necessary before the client can send a UDP datagram to the server. This is not a hard and fast rule, but is certainly done on some systems.

43. When the client in our scenario sends to the ‘down’ server, there is an ARP request / reply pair (which merely validates that there is such an address on the local network). • Then the client sends its datagram; however this causes an ICMP error (port unreachable). • But this ICMP error is NOT returned to the client process. • This leaves the client blocking forever. • The reason why the client does not receive the ICMP error is that the error is asynchronous; when the client sends data (sendto function) ICMP will not return an error until some time later (a function of TTL).

44. Asynchronous errors are not returned to UDP sockets unless the socket is connected (????). • The reason why this design choice was made was to allow multiple send messages to proceed even in the condition where one particular address was down. • The ICMP error message contains sufficient information (IP header / UDP header) to determine what caused the error. • Linux will return ICMP destination unreachable errors even for an unconnected socket (SO_BSDCOMPAT socket option is disabled).

45. A TCP server always has access to the 4 tuple of a connected socket. This 4 tuple remains constant for the lifetime of a connected socket. • With a UDP socket however, the destination IP addr can only be obtained by setting the IP_RECVDSTADDR socket option. Then rcvmsg must be called from recvfrom. • This is because UDP is connectionless; the destination can change for each datagram sent to the server. • The UDP client must specify the servers IP/port for the sendto invocation. • Once the client is assigned an ephemeral port it keeps it for the entire sendto loop.

46. While the client port remains constant the IP address can change on every datagram (assuming no client side bind). • However if the client binds an IP address to its socket the kernel may still send out the datagram on another datalink. (the datagram will contain an address which is different from that where it originated). • Basically the four tuple remains the essence of what is required to demulitplex a connection. In UDP however there are some problems with getting and maintaining this information. • UDP is connectionless.

47. UDP connect function • Asynchronous errors are not returned on UDP sockets unless the socket has been connected. • The UDP connect does not result in a TCP style of connection. • Instead the kernel records the IP address and port number of the peer in the socket address struct passed to connect. • With a connected UDP socket sendto is not used; rather write or send functions are invoked. • Anything written to a connected UDP socket is guaranteed to be sent on the protocol address specified by the connect.

48. With a connected UDP socket recvfrom is not used; rather read or recv. • The only datagrams returned by the kernel for an input are those specified by the protocol of the connect. • This effectively limits a datagram exchange to a peer to peer transfer. • Asynchronous ICMP errors are returned to the process for a connected UDP socket. • If a datagram arrives and cannot be delivered to a some UDP socket on a given host (source IP and source UDP port do not match), UDP will discard the datagram and generate an ICMP error.

49. Normally a UDP client calls connect. However in some long-lived applications (TFTP) both the client and the server call connect. • DNS employs UDP. Generally do not use connect when a client is trying to find a DNS server (same with DHCP). There are typically a number of such servers. • UDP has no flow control. This means that a UDP sender can easily overrun the receiver. Steven’s recalled an example with a 96% loss rate. • The example, which sent 2000 datagrams, had 1912 of them lost due to “full socket buffers” • When using a slow client and a fast server Steven’s recounted no losses at all.

50. UDP socket receive buffer. • The SO_RCVBUF socket option can be used to change the size of the socket’s receive buffer. • The default size is 41.6 kbytes (29 datagrams of 1.4kbytes). • Steven’s anecdote only showed a marginal improvement when moving the buffer size from 41.6k to 240 kbytes. • UDP should not be used for bulk data transfers. It is acceptable for small transfers. • One interesting side effect of UDP connect is that it can be used to determine the outgoing interface used for a particular destination.