IP on Local Networks

• special IP addresses
• IP addressing examples
• router IP addresses
• IP host routing algorithm
• Address resolution:
  • table lookup
  • computation
  • message exchange
  • ARP header
  • ARP request-reply
• IP header
• IP processing

Special IP addresses

• address A, network mask M
• network address: A and M
• directed (single-network) broadcast address: A V ( != g M)
• single-network broadcast address: 255.255.255.255
• unconfigured address: 0.0.0.0
• loopback address: 127.X.X.X, typically 127.0.0.1
• private internets: 10.0.0.1 through 10.255.255.254 (10/8), 172.16.0.1 through 172.31.255.254 (172.16/12), and 192.168.0.1 through 192.168.255.254 (192.168/16)

IP Addressing Examples

• A network with network number 128.171.0.0, address mask 255.255.0.0, has at most 2¹⁶ - 2 hosts, all of whose numbers begin with 128.171.
• A network with network number 123.45.64.0, address mask 255.255.255.0, has at most 2⁸ - 2 hosts, all of whose numbers begin with 123.45.64
• A network with network number 123.46.64.0, address mask 255.255.192.0, has at most 2¹² - 2 hosts, all of whose numbers begin with 123.46.64 ... 123.46.127
• how about a router connecting these three networks?

Router IP Addresses

• a router has an interface on each different network
• some of those networks might be real small, e.g. have a network mask 255.255.255.252 (only two valid IP addresses)
• default routers for a network often have the .1 address, but this is not a requirement
• a multi-homed host can also have interfaces on different networks, but unless it forwards packets from one to the other, it is not a router: it does not need to run any routing protocols to build routing tables

IP Host Routing Algorithm

• I am configured with my address A, my mask M, and the default route via gateway G
• note that A and M = G and M, unless we have errors
• when sending a packet to destination D, I must:
  • see if D and M = A and M
  • if it is, the destination is on the same network
  • if it is not, the destination is on a different network, so I must send it to G
  • either way, I must find out the hardware address for the next hop given only its IP address D or G

Address Resolution

• address resolution is the process of finding a hardware address given a protocol (IP) address
• on Ethernet, for example, NICs will filter out packets that don't have their hardware address
• on ATM, the data will have to be sent on a connection -- if the connection exists I need to figure out which VPI/VCI to use, otherwise I will need an ATM hardware address
• how to resolve?
  • table lookup (ARP table)
  • computation (same addresses)
  • message exchange -- ask someone else

Address Resolution: Table Lookup

• fixed-size protocol address, fixed-size hardware address (for a given network)
• could omit the network number from the table
• sequential search may be OK
• direct indexing (host number is index into table) may be OK
• but who builds the table?

Address Resolution: Message Exchange

• the information is available in the network
• why not use the network to create the lookup table?
• because we don't know who to send the request to
• broadcast request, addressed host can reply -- every Ethernet NIC accepts broadcast frames
• request from one or more servers, server(s) do table lookup -- hardware address of server must be configured in

Address Resolution: Computation

• if the hardware address can be assigned, then we can assign the IP address and the hardware addresses to match
• if the host part of the IP address is as long as the hardware address (same number of bits), simply assign the host number as the hardware address
• if the hardware address is longer (more bits) than the host number, can assign an arbitrary hardware address prefix
• if the hardware address is shorter (fewer bits) than the host number, can use any computation that won't cause collisions -- e.g. modulo n if host numbers are in the range of m to m+n - 1. If the hardware address has b bits, then 2^b > n -- why?

ARP packet

• request (op 1) is sent to broadcast address, reply (op 2) to sender hardware address
• only 28 bytes, padding needed to get to 46
• hardware and protocol lengths (hl, pl) make ARP flexible enough for lots of protocols (e.g. IPv6)

ARP processing

• when I have a packet to send on an ethernet to a directly-connected next-hop H
• I build an ARP packet with protocol 0x800, op 0x1 (request), my hardware and IP addresses, target hardware address 0xffffffffffff, and target IP address H
• I send this to the broadcast address with ethtype 0x806,
• receivers discard it if not for them
• H remembers my IP to hardware translation, and builds an ARP with protocol 0x800, op 0x2 (request), H's hardware and IP addresses, my hardware address and IP addresses
• if I don't get a reply, I retransmit

IP datagram

• an IP datagram consists of a header followed by the payload (data)
• an IP header is normally 20 bytes, but may have additional optional headers, up to a maximum of 60 bytes (always a multiple of 4 bytes)
• the data can be arbitrary, but has a maximum length of 2¹⁶ - 20 bytes (20 bytes is the minimum IP packet header length, and 2¹⁶ is the maximum length of the packet + header
• overhead of sending header is less (per byte) for larger packets, but the same per packet
• 32-bit source and destination addresses in the IP header are IP addresses
• IP is designed to be handled in software

IP header

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| HLen  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP header fields

• all fields are big-endian
• version number must be first field (so we can evolve)
• Type of Service is defined but not widely used
• Total Length is needed for protocols that may pad the packet (e.g. ethernet) and to check for errors
• header length used for options
• TTL/Time To Live (really a "maximum hop count") kills packet in case of routing errors
• protocols: 1 (ICMP), 6 (TCP), 17 (UDP)

IP Header fields

• all fields are aligned on their own size
• header checksum (RFC 1071, http://www.cis.ohio-state.edu/htbin/rfc/rfc1071.html) only protects header
• source address might be useful for responding, but not used in "normal" processing
• packet ID and fragmentation fields (discussed next lecture) allow us to send packets larger than the underlying network's MTU
• minimum MTU for carrying IP is 576 bytes

Some properties of IP

• connectionless: routing is based only on the destination address
• TTL field keeps small routing mistakes from bringing down the network
• unreliable:
  • no packet sequence numbers,
  • no acknowledgements,
  • no error checking on the data
• possible errors:
  • loss
  • duplication
  • out-of-order delivery
  • corruption