Chapter 3

p. 34

A protocol value of 108 indicates an IP datagram whose payload has been compressed -- see RFC 3173.

pp. 34-35

RFC 2780 confirms that the TOS field described here has been officially replaced by a 6-bit differentiated services codepoint (DSCP) field, described in RFC 2474²⁶, and then a two-bit field which is currently unused²⁷. The DSCP field is intended to be used to select the ``packet handling behaviour'' (PHB) for a particular differentiated services domain. RFC 2474 also contradicts Stevens in the current use of the precedence field, which Stevens describes as ``ignored today'':

In short, IP Precedence is widely deployed and widely used, if not in exactly the manner intended in [RFC791].

TOS fields of the form xxx000xx (i.e. with DSCP field xxx000) are to receive a PHB which is compatible with uses of the precedence field, in particular ``common usage of IP Precedence values `110' and `111' for routing traffic.'' It is worth noting that the mechanism in RFC 2474 was first intended for IPv6 (see notes to p. 50), and has been retro-fitted to IPv4.

p. 36

In 1993, the US academic backbone of the Internet changed, with the phasing out of the old NSFNET. One consequence of this was that it now generally took 3-5 more hops to traverse the new backbone than it did the old. At the same time, there suddenly started to be many complaints about partial or total lack of connectivity between some sites/machines and others. This was finally tracked down to the fact that DEC's VMS, at the time a very popular machine, especially for academic computing services, was shipped with a hard-wired TTL of 32, and the perceived diameter of the Internet (i.e. the number of hops a packet had to travel) now exceeded this. RFC 1700 states that the default TTL should be 64.

pp. 36-37

The IP header checksum is easily calculated in software, since it can be done in 16 or 32-bit chunks, However, it does not prevent against re-arrangement of the (16-bit) words, or insertion/deletion of a word of all 0's or all 1's. Contrast this with the Ethernet CRC described on page 22. However, the IP header checksum is valuable: [11] observes that ``we saw a surprising number of IP datagrams with bad headers -- it turns out that some LAN chipsets periodically erase 16 bits of the IP header (almost certainly due to a timing error on an internal 16-bit bus). These errors almost all get screened out by the first hop router.'' .

p. 44 l. 1

It is not just a case of ``how many'' bits, but which. There is no reason in RFC 950 why the sub-net mask need be next to the net mask (the University of Bath's network would work as well if the subnet mask were ffff00ff, with the Mathematics network being 138.38.x.96, rather than 138.38.96.x, and with the corresponding swaps in the numbers). However, the advent of CIDR (see p. 140) has meant that subnet masks tend to be next to the net masks, and RFC 1812 says that this SHOULD be the case.

While all sorts of tricks can be played, using contiguous bits next to the network's (A/B/C) implicit mask is strongly recommended -- see RFC 1219.

p. 44 bottom

With the advent of CIDR (p. 140), the distinction between ``a host on a different subnet'' and ``a host on a different net'' becomes essentially obsolete. Currently no computation of Class A/B/C should be done -- we should check whether (source address & netmask) is equal to (destination address & netmask). If they are equal, the destination is on our subnet, otherwise it's not.

Figure 3.9

With the advent of CIDR (p. 140), the ``net-directed'' and ``all-subnets'' broadcasts are essentially obsolete. The only broadcasts are the limited one -- ``all on my cable'' (strictly speaking ISO level 2 network), and the subnet-directed one -- ``all on my net/subnet''. However, as Barry Margolin commented on 22 March 2001

many routers have subnet-directed broadcasts disabled, because they're used more for SMURF attacks than any legitimate purposes.

RFC 2644, which is ``Best Current Practice'' amends RFC 1812 (Router Requirements) as follows.

A router MAY originate Network Directed Broadcast packets. A router MAY have a configuration option to allow it to receive directed broadcast packets, however this option MUST be disabled by default, and thus the router MUST NOT receive Network Directed Broadcast packets unless specifically configured by the end user.

The reservation of $-1$ for ``broadcast'' means that the longest sensible netmask is 30 bits: fffffffc. In the special context of a point-to-point link, where broadcasting is not supported, RFC 3021 says that a 31-bit netmask, fffffffe is permissible, with the two ends having Host numbers of 0 and 1.

p. 49

The state of allocation of IP numbers in 1999 was described on the Internet recently as ``Class B addresses are like hen's teeth''. RFC 2050 emphasises that addresses are no longer allocated at the A/B/C borders. RFC 3194 attempts to quantify ``allocation efficiency'' for addresses. The formula is $\log(allocated)\over\log(possible)$, and several instances (e.g. the recent French move from 8-digit telephone numbers to 9-digits ones) of renumbering have taken place when this reaches 0.87.

p. 50

In fact, the replacement for the current IP (IP version 4, or IPv4), will be known (for historical reasons) as IPv6, and is not really any of the proposals here. It has 128-bits addresses: enough for $5\cdot10^{28}$ IP interfaces for every human being alive today. It also has much more variable length headers, whereas in IPv4 we are running out of IP header space (see source routing in the notes to section 8.5) and TCP header length (see the notes to p. 312). The reader should see RFC 2460 (which replaces 1883) and the references therein for the details, or [10] for a readable overview. RFC 2893 discusses some issues in the transition from IPv4 to IPv6.http://www.6net.org describes a Eurpoean project fr migration to IPv6, of whihc UKERNA, who manage JANET are a partner. JANET's own efforts are described at http://www.ja.net/developments/ipv6.