Internet Protocol
- datagram forwarding, subnetting
- IP fragmentation
- IP version 6
- Internet Control Message Protocol
Routing Table Entries
- netstat -r -n on some versions of Unix,
route -n on others (Linux)
Kernel IP routing table
Dest Gateway Genmask Iface Cost
12.17.5.0 0.0.0.0 255.255.255.0 eth0 0
21.23.0.0 0.0.0.0 255.255.0.0 atm0 0
12.17.0.0 12.17.5.1 255.255.0.0 eth1 1
0.0.0.0 21.23.0.1 0.0.0.0 atm0 1
- routing consists of choosing the route with the longest address
mask match: in the above example, 12.17.5.18 must go over eth0,
but 12.17.6.18 must go over eth1
Subnetting
- address masks allow progressively finer (power of two) subdivisions
of the address space
- I can subdivide the address 128.171.0.0/16 into as many as
256 class-C sized networks
- routers outside the network need only route to the border router(s)
for the network
- routers within the network must know the network topology (or have
a good default router)
- hosts within a subnet need not know that they are part of a bigger
network
- if different networks have the same prefix, we can join them into
a supernet, e.g. 1.2.3.0/24 and 1.2.2.0/24 can be joined into 1.2.2.0/23
IP Encapsulation
- when sending a datagram, IP must:
- select the next hop
and find out its hardware address
- encapsulate the IP header and data as the payload
of a hardware frame
- the hardware header must identify this frame as an IP packet
- a router removes the old hardware header, processes the IP header
(including checking the checksum), looks up in the routing table, and
sends the datagram to the next hop
- problem: different networks may have different Maximum Transmission
Units (MTUs) -- eg 1500 for Ethernet, 1024 for SLIP
- an Ethernet packet cannot be sent over SLIP
IP Fragmentation -- concepts
- if IP must send a datagram of size n, and the IP header
is h bytes (typically h = 20), and the MTU is M < n + h, then
IP must fragment the datagram:
- the payload is split up into n / (MTU - h) different units, each
no larger that M - h bytes
- each unit is encapsulated into its own IP packet and sent separately
- the IP header encodes information (in the packet ID, fragment offset,
and flags fields) marking this as part of a larger packet
- the fragments are always reassembled by the end system, never by
a router
- if any fragment is lost, the receiver must discard the entire datagram
IP Fragmentation -- details
- each packet carries a packet ID field which must be different for
packets sent at similar times by the same sender to the same destination
(counter, timestamp, etc)
- all fragments of a packet carry the same packet ID:
if a fragment is re-fragmented, the smaller fragments still carry
the same packet ID
- each fragment also carries a fragment offset: the position of the
fragment payload in the original datagram.
fragment offset must be a multiple of 8, and the lowest 3 bits
are not sent (13-bit field, 216 maximum packet size)
- the size of the original datagram is known when we receive the
specially-marked last fragment
IP Fragmentation -- Bits and Bytes
- the fragment offset field holds the most significant 13 bits of
the actual fragment offset
- two flag bits are used:
- DF: don't fragment, if the packet would need to be fragmented,
drop it instead (and send an ICMP error message)
- MF: more fragments, true (1) if there are more fragments, false
if this is the last fragment
- most of the fragmented header fields are the same, except for
fragment offset, flags, total length, and of course TTL and checksum
- some options go in the first fragment only, some in all,
so header sizes might differ
IP Fragmentation -- In-class Exercise
- work individually
- fragment the IP packet with: version 4, header length 20 bytes,
TOS 0, total length 31, packet ID 0x90ab, DF = 0, MF = 0,
fragment offset 0x100, TTL 17, protocol 17, checksum (correct),
source 128.171.10.1, destination 128.171.10.2, data
0x01,
0x02,
0x03,
0x04,
0x05,
0x06,
0x07,
0x08,
0x09,
0x0a,
0x0b.
- the MTU of the network you are sending on is 28 bytes
- write down all the bytes of all the packets you send (you don't
need to compute the checksum)
Datagram Reassembly
- RFC 815
- goal: space and time efficient
- problems: don't know the datagram size until we receive the last fragment
and since datagrams may arrive out of order, how do we know when we are
done?
- answer: keep a list of holes. Initially, the list has one
hole from 0 to 216
- as datagrams arrive, shrink, split, or delete holes from the list
- when the last datagram arrives (up to index n), can get rid
of the hole from n to 216
- when the hole list is empty, the datagram is complete
Problems with IPv4
- address space too small (32 bits).
- insufficient structure in addresses.
- no support for real-time.
- no support for security.
- no support for auto-configuration.
- no support for mobile hosts.
IPv6
+++++++++++++++++++++++++++++++++
|Ver|Pri| Flow Label |
+++++++++++++++++++++++++++++++++
|Payload Length |Nxt Hdr|Hop Lmt|
+++++++++++++++++++++++++++++++++
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+++++++++++++++++++++++++++++++++
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+++++++++++++++++++++++++++++++++
IPv6
Fields changed from IPv4:
- Header Length is missing
- Type of Service is now Priority
- Fragmentation (Id, flags, fragment offset) is in an extension header
- TTL is now Hop Limit
- Protocol is now Next Header (and substitutes for header length)
- Checksum is gone (and now required in higher-layer protocol)
- Options are in extension headers.
IPv6 Extension Headers
- Hop-by-Hop/Jumbo Payload (up to 232 bytes/packet)
- Routing
- Fragmentation (source only)
- Destination Options
- Security/Authentication
IPv6 Address Classes
- Supersets of other standard addresses (NSAP/02,03, IPX/04,05)
- Provider-based addresses (20-3F)
- v4-compatible addresses (::00:1.2.3.4)
- v4-mapped addresses (::00FF:1.2.3.4)
- Link local use addresses.
- Site local use addresses.
- Multicast.
IPv6 Flow Labels
- special services (quality of service, real-time) may be
requested for a specific flow
- many possible flows between any two hosts
- packets not in a flow have flow label zero
- routers may use flows for soft state (<= 6 s)
- priority:
- [0] default
- [1] "filler" (netnews)
- [2] unattended data (email)
- [4] attended data (ftp)
- [6] interactive (telnet)
- [7] control (routing)
Internet Control Message Protocol (ICMP)
- Internet is complex
- how do we find out what is going wrong?
- send a packet "there and back": ICMP echo and echo reply, ping
- send an ICMP error packet whenever we drop a (non ICMP error) packet
- ICMP: RFC 792
ICMP Echo
- Echo packet (type 8) or Echo Reply (type 0)
- checksum covers entire packet
- identifier (typically process ID on sender machine)
- sequence number (typically 1, 2, 3...)
- arbitrary data follows (could be large)
- for ping, data typically holds binary date and time (2 32-bit
words, 8 bytes)
Other ICMP Types
- [3] Destination Unreachable (network, host, protocol, prohibited...)
- [11] Time Exceeded (in transit, during reassembly)
- [5] Redirect: use this other router for this destination
- [9] Router advertisement
- [10] Router solicitation
- [4] Source Quench
- [12] Parameter Problem