2.1 The IP addressing model

2.1 The IP addressing model

TCP/IP implements a universal addressing scheme. Every device on an IP network, and every IP network itself, has a unique address that identifies it. This addressing scheme enables communication for millions of devices over public networks such as the Internet, as well as private intranets.

2.1.1 Implementation

We start by reviewing the provisions made within the IP protocol itself for Network Layer addressing. This is complicated by the fact that two versions of the IP protocol (IP version 4 and IP version 6) are likely to coexist on public and private networks for some time, for reasons we will discuss later in this chapter. Figure 2.2 illustrates the relative size of the address fields for IPv4 and IPv6. IPv4 provides 32 bits each for both the source and destination address fields. While this may seem huge, with 4,294,960,000 possible addresses available to each field (i.e., 2³²), we will discuss why the hierarchical model chosen for IPv4 has led to serious problems with address depletion. IPv6 provides 128 bits per address and implements a new addressing model designed to overcome some of the more obvious problems with IPv4. This addressing scheme makes it possible for devices such as IP routers to deliver messages between hosts in different parts of the world. With IPv4 each host has a unique address composed of a 32-bit (4-byte) number, and this is broken down into two parts: <netID><hostID>.

Figure 2.2: IP header formats showing the space allocated for source and destination IP addresses. (a) The IPv4 header length is a minimum of 20 bytes, supporting 32-bit addresses. (b) The IPv6 header length is a minimum of 40 bytes, supporting 128-bit addresses.

Since binary is not especially user friendly, IPv4 addresses are typically represented in dotted decimal notation, where each of the four bytes is represented in decimal form 0 to 255 (e.g., 140.55.3.2). This makes IP addresses easier for people to use and recall. All devices on an IP network must have an address; otherwise, they are not logically part of the network.

The netID is administered by the Internet Network Information Center (NIC). This part of the address is unique throughout the Internet.

The hostID refers to an individual end system, unique within a network or subnetwork, which is typically administered locally by a systems administrator or a network design team.

The standards for IP addresses are described in [1], and specifically IPv4 and IPv6 are described in [2, 3]. IPv4 uses a system of hierarchical address classes, as described in the following text. IPv6 is discussed in section 2.1.7.

2.1.2 IP version 4 address classes

Because a host's IP address must uniquely identify not only the device itself but also the network to which the device is attached, the IP address requires at least two components: the network identifier (netID) and a host identifier (hostID). The division of the address space is, in fact, slightly more sophisticated to allow for different sized networks and is currently arranged to offer three classes of network—A, B, and C—together with a special class, D, for multicasting and a reserved class, E.

Of the five IP address classes, only the first three are relevant to the majority of users. Classes A, B, and C are for general-purpose unicast use; class D is used by special multicast applications and routing protocols such as OSPF and RIP II. In order to differentiate address classes quickly, the most significant bits of the netID field (the classID) are used, as illustrated in Figure 2.3. The class ID is a variable-length bit field, used to differentiate between different IPv4 address classes.

Figure 2.3: General IPv4 address format.

Figure 2.4 illustrates how the current IPv4 address space is broken down into the five address classes. Classes are differentiated by the most significant bits of the first byte. Classes A, B, and C each comprise a network part and a host part, which varies to accommodate different sized networks and different host population sizes. Class D is used for multicast applications and routing protocols such as OSPF and RIPv2. Associated with each of the three unicast address classes is a mask, or prefix. This is a bit mask, which is used by hosts and routers to determine how much of the netID is treated as significant for forwarding decisions. Note that IPv6 uses a completely different model, as described in section 2.1.7. The classes can be summarized as follows:

• Class A addresses have the high-order bit set to 0. There are 7 bits available for network addresses. The remaining 24 bits are used for host addresses. The default mask is 255.0.0.0; the default prefix is /8.

• Class B addresses have the high-order bits set to 10. There are 14 bits available for network addresses. The remaining 16 bits are used for host addresses. The default mask is 255.255.0.0; the default prefix is /16.

• Class C addresses have the high-order bits set to 20. There are 21 bits available for network addresses. The remaining 8 bits are used for host addresses. The default mask is 255.255.255.0; the default prefix is /24.

• Class D addresses have the high-order bits set to 210. There are 28 bits available for multicast addresses. These addresses are effectively group addresses, used by applications that need to send the same IP packet to many destinations concurrently. This can be a very efficient way to distribute such information, since the alternative would be to duplicate all of the information for every destination—for example, a financial application might use multicasts to distribute share prices to a group of subscribers. OSPF uses IP multicasts for delivering routing messages to other OSPF routers. See section 2.1.4 for further information.

Figure 2.4: Classes A through E: IP version 4 address formats.

Class E addresses have the high-order bits set to 220. The remaining 27 bits are reserved for experimental use only (not for use on public networks).

Masks and prefixes

As mentioned previously, each of the three classes of unicast IP addresses has a fixed contiguous series of bits called the network mask associated with it. In fact, we refer to this as the natural mask, when the number of bits used exactly matches the number of bits allocated to the netID, as illustrated in Figure 2.4. The natural mask indicates exactly how much of the address is allocated to the netID, the remainder being the hostID. For example, the class A address 10.0.0.0 has a natural mask of 255.0.0.0, indicating that only the first 8 bits are used by the netID; the remaining 24 bits are available for hosts. In fact, it is possible to vary the length of the mask (forming unnatural masks) to facilitate address optimization through operations such as subnetting or supernetting. These advanced topics are described later in this section.

The mask is important for any device that transmits or forwards packets, since by ANDing this mask with a destination address we can readily determine if a packet should be sent directly to the local network or forwarded to another network. For example, assume a host using the IP address 195.66.3.6 wishes to communicate with another host at 195.66.5.3. By ANDing these two addresses with the host's own natural mask, 255.255.255.0, we can see that they are not part of the same network, and, therefore, the host must forward packets for this destination to its nearest router (as described in Chapter 3).

 200002 01000010 0000002 0000020 = 195.66.3.6     // Class C address 200002 01000010 00000101 0000002 = 195.66.5.3    // Class C address 2222 2222 2222 XXXXXXXX   255.255.255.0    // Natural Network Mask -----------------------------------        logical_AND 200002 01000010 0000021 XXXXXXXX = 195.66.7.X // Different IP prefix! 

In recent years a shorthand method of representing masks has emerged, called the address prefix. The prefix indicates the number of contiguous bits used by the mask (note that a mask can be noncontiguous, but this makes no sense for a prefix). Using our example class A address 10.0.0.0, the appropriate natural prefix for this address is /8, so we can use the shorthand form 10.0.0.0/8 to indicate both the address and the size of the mask.

Address ranges

Classes A, B, and C are used for a range of large to small IP networks, respectively, where the netID portion of the address competes for space with the hostID portion (since there is only a fixed number of bits). Very few organizations have class A addresses, and they are now practically impossible to get hold of. Class B addresses are used for large organizations, but even they are in rationed supply. When you connect into an ISP nowadays, you will most likely get a class C address, or a number of class C addresses. Table 2.1 illustrates the ranges available. Note that the class A address 127.0.0.0 is reserved as the local loopback address. Max Networks is calculated as 2^(netIDbits) - 1 (we subtract the prefix bits). Max Hosts is calculated as 2^(hostIDbits) - 2. We subtract 2 from this number because all 1s are usually reserved for broadcasting and all 0s is reserved for historical reasons (it was originally used as a broadcast address in early implementations of IP).Nodes with the same address class and prefix can communicate directly. Nodes with a different address class, or the same address class and a different prefix, would normally communicate via an intermediate device (i.e., a Layer 3 switch, router, proxy, or possibly NAT). It is possible to have hosts configured with multiple IP addresses of different classes on the same physical interface.

Table 2.1: Classes A through E: Address Ranges and Configuration Data

Class	Prefix	Address Range		Max Networks	Max Hosts	Type
		From	To
A	0	1.0.0.0	126.0.0.0	126	16,777,124	Unicast
B	10	128.1.0.0	191.255.0.0	16,383	65,534	Unicast
C	110	192.0.1.0	223.255.255.0	2,097,151	254	Unicast
D	1110	224.0.0.0	239.255.255.255	na	na	Multicast
E	11110	240.0.0.0	tbd	tbd	tbd	Reserved

Special and reserved addresses

There are several network addresses that are reserved for special purposes, as follows:

• Source network and host address bits set to 0—Generally there are two cases: either all bits set to 0 or just the network portion set to 0 together with a valid host address. In both cases this equates to This Host This Network and should be seen only in the source IP address field. A typical use of this option would be when a host is initializing, and wants to communicate over a network but does not yet know the network IP address and so solicits help. For example, BOOTP is a good example of this use; a reply from a BOOTP server contains the fully qualified network address, which the sender will then record for subsequent use. BOOTP is described later in this chapter.

• Destination address broadcasts—There are several forms of special IP destination broadcasts, as summarized in section 2.1.3.

• Loopback address—The special class A network 127.0.0.0 is reserved as a special loop-back network address for devices implementing an IP stack. It should never appear outside a host. This network address is typically used for testing and debugging communication software, since it can act as a target sink point inside the host system. For example, a client/server application could easily be tested inside a single host by referencing ports on this IP address, without packets ever leaving the host itself.

2.1.3 Broadcast addresses

A broadcast is a special group destination address, where everybody is expected to be a member of that group by default. In the IP world, as with many other technologies, broadcasts are very common, and in the IP addressing model there are several forms of special IP destination broadcasts to be aware of, including the following:

• Limited broadcast—If all bits of the destination IP address field are set to 1, then this means all networks or all hosts and is effectively a limited broadcast to all nodes on the local network segment (i.e., routers should not forward any such messages).

• Directed broadcast—If the network number is a valid netID but the host number bits are all set to 1, then this is called a directed broadcast—for example, 140.56.255.255. This would be sent to all hosts on the class B network 140.56.0.0. This form of broadcast would be forwarded to all subnetworks of this address if subnetting were employed (assuming that all routers in the distribution path have routing protocols that are subnet aware, as described in Chapter 3).

• Subnet broadcast—The above rules also apply at the subnet level. If subnetting is implemented, then the subnet address containing all 1s must be reserved for broadcast use. For example, a class C network, 193.160.30.0, could have a subnet mask 255.255.255.192 (prefix /26), where the first two bits of the host address are reserved for subnet addresses. The subnet broadcast in this case is, therefore, 193.160.30.192 (i.e., both bits set).

• HostID zero—HostIDs of all 0s should never appear in destination address fields, (i.e., <netID>.0 or <netID>.<subnetID>.0).

Note that when creating subnetworks you must remember that not all permutations of the subnet bits are valid subnetwork addresses. In the example using a /26 prefix given above we would create four subnets: 192, 128, 64, and 0 (using bit permutations 2, 10, 01, and 00). As stated, we cannot use 2 since this is a subnetwork broadcast. It is also not recommended to use all zero (00) subnet addresses, since some older (before BSD 4.3) IP implementations used 0.0.0.0 for limited broadcasts. Having said that, it is now a fairly common practice to use the all-zero subnet address.

Broadcast forwarding

Routers must discard limited broadcasts unless explicitly configured to relay them. Sometimes broadcasts are required to be flooded through the entire internetwork (e.g., if a device is advertising a global service or issuing a BOOTP request for configuration data). Some routers support a technique by which these broadcasts are forwarded over a Spanning Tree of the network, rather than all branches. (Reference [4] indicates that the Spanning Tree of a graph ensures complete reachability without duplicated traffic.) Another form of broadcast assistance is accommodated with a relay mechanism (often called a helper address [4]). Typically you would manually configure helper addresses on a router, or a series of routers in a path, to relay broadcasts that would otherwise be discarded. Note that enterprise and access routers may support this functionality for several protocol stacks in addition to IP. For example, you could permit retransmission of Novell service announcement (SAP) broadcasts using helper addresses, thereby notifying clients on remote network segments about NetWare services available locally.

Performance issues

Reference [4] discusses how broadcast replication can seriously affect scalability in NonBroadcast MultiAccess (NBMA) networks such as Frame Relay and ATM. On multiaccess LANs, such as Ethernet, the issues are more subtle. IP broadcasts are mapped to the MAC broadcast address 0xFFFFFFFF This is an address that all network interface cards (NICs) and network-attached devices must listen to, and if necessary respond to. Receipt of a broadcast results in an interrupt, since the receiving node must process all broadcasts to assess whether the packet is relevant or should be discarded. The higher the broadcast rate, the more interrupts, sapping valuable CPU time. Unless broadcast levels are controlled, network bandwidth and system resources can be seriously degraded. Routers typically offer various broadcast-limiting functions that reduce network traffic and minimize the probability and scope of broadcast storms. It is notable that IPv6 has done away with the concept of the broadcast altogether, as described in section 2.1.7. This should facilitate tighter control of traffic over internetworks in the future.

2.1.4 Multicast group addresses

The final 28 bits of a class D address are unstructured (there is no associated bit mask) and range in value from 224.0.0.0 through 239.255.255.255. The multicast group address is basically an aggregation of the high-order 4 bits (210) and the multicast group ID (although multicast group addresses are represented by the dotted-decimal notation, this is primarily for ease of use; there is no class prefix). A group of hosts that listens and responds to a particular IP multicast group address is referred to as a host group, and a host group can be physically located on multiple networks. Hosts typically join or leave a host group dynamically, although some implementations may allow static configuration (further information on IP multicast protocol operations is provided in Chapter 4). Well-known multicast group addresses (i.e., the equivalent of a well-known port) are assigned by the Internet Assigned Numbers Authority (IANA): There are two kinds of host group, as follows:

• Permanent—The multicast group address is permanently assigned by IANA. A permanent group exists even if it has no members. Hosts can join or leave a group at will.

• Transient—Any multicast group that is not permanent is transient and can be dynamically assigned as and when required. Unlike permanent groups, transient groups cease to exist when they have no members.

An application can retrieve a permanent host group address from the domain name system using the domain mcast.net, or retrieve the permanent group from an address by using a pointer query in the domain 224.in-addr.arpa (see section 2.3.2 for the operation of the in-addr.arpa domain). The current list of IP addresses assigned to permanent host groups is specified in [5]. Table 2.2 provides a list of important multicast group addresses.

Table 2.2: Examples of Well-known Multicast Group Addresses

Address	Description
224.0.0.0	Reserved Base Address
224.0.0.1	All Systems on this subnet
224.0.0.2	All routers on this subnet
224.0.0.5	All OSPF Routers
224.0.0.6	OSPF Designated Routers
224.0.0.9	All RIP2 Routers

Address mapping to Ethernet

The IANA owns a block of Ethernet addresses in the range 00:00:5e:00:00:00 through 00:00:5e:ff:ff:ff. Half of this block is allocated for multicast addresses. Since the first byte of an Ethernet address must be set to 0x01 to signify a multicast, the actual addresses that map to IP multicast addresses are in the range 01:00:5e:00:00:00 through 01:00:5e:7f:ff:ff. The least significant 23 bits of the Ethernet address are, therefore, available for mapping to IP multicast group IDs. The mapping places the low-order 23 bits of the multicast group ID into these 23 bits of the Ethernet address. For example, an OSPF Hello message (see Chapter 3) uses the multicast destination address 224.0.0.5, which maps onto the Ethernet MAC address 01005e000005. Figure 2.5 shows an example of how mapping works at the bit level.

Figure 2.5: Multicast addresses mapping between an IPv4 address and Ethernet. In this example the class D multicast 224.3.5.1 is mapped onto the MAC address 0x01005e030501.

Since the five high-order bits of the multicast address are ignored in this mapping, the resulting address is not unique; in fact, 32 different multicast group IDs map to each Ethernet address. Because the mapping is not unique, the interface card is likely to receive some multicast frames that the host is really not interested in, so the device driver or IP stack must filter out unwanted frames.

Multicasting on a multiaccess network is quite straightforward. The sending process inserts a destination IP multicast address into the IP packet header, and a media device driver maps this to the corresponding multicast MAC address before transmission. The media device driver also handles multicast reception. The receiving process must notify its own IP protocols and services to establish whether they want to receive packets destined for a given multicast address; if so, then it must deliver a copy to all processes belonging to that group (multiple processes on a given host can belong to the same multicast group). In a routed environment the situation is more complicated; the processes and protocols required for group registration and multicast delivery are dealt with in Chapter 4.

2.1.5 The official IP address space

In order to guarantee any-to-any communication over public networks such as the Internet, all participating systems must use IP addresses that have been officially allocated (often called legal addresses). If you are setting up an entirely private network and do not intend to communicate with systems over the Internet, then you are free to choose your own network numbers. However, if circumstances change, you run the risk of redesign of your network or having to use address translation devices (see section 2.1.6 for the recommended way to design private addressing schemes).

Obtaining registered addresses

IP addresses belong to what is referred to as the IP Address Space, and are administered by the Internet Assigned Numbers Authority (IANA—see [6]). The IANA is the overall authority for administration of IP addresses, Domain Name System (DNS) names, Autonomous System Numbers (ASNs), and Top-Level Domains (TLDs). When discussing IP addresses, you will come across the terms assigned and allocated. The terms have the following meanings:

• Assigned—The number of network numbers in use. The class C figures are somewhat inaccurate, because the figures do not include many class C networks in Europe, which were allocated to [7] and subsequently assigned but are still recorded as allocated.

• Allocated—This includes all of the assigned networks and, additionally, those networks that have either been reserved by IANA or have been allocated to regional registries by IANA and will subsequently be assigned by those registries.

There is a hierarchy of assignment authority, with authority delegated down from the IANA itself. Below the IANA are the Regional Registries (RRs); below them lie the subregistries (Local Internet Registries [IRs], Internet Service Providers [ISPs], etc.). Requests are normally made to the higher authority unless a particular organization is large enough to require a direct dialog with the IANA (requirements for a class A network, for example, are handled on an individual case basis). There are three regional registries that handle worldwide IP address assignments, as follows:

• APNIC (Asia-Pacific Network Information Center)—Handles IP address allocation for Asia-Pacific. Contact [8] for registration.

• ARIN (American Registry for Internet Numbers)—Handles IP address allocation for North and South America, the Caribbean, and sub-Saharan Africa. Contact [9] for registration.

• RIPE NCC (Réseau IP Européens)—Handles IP address allocation for Europe and surrounding areas. Contact [7] for registration.

To obtain an official IP address and have your host name officially recognized, you must register with the appropriate authority. Depending on your needs, you will most likely be allocated a class C network identifier. Class B addresses are now only available to large organizations, and class A network space is effectively used up (remember that there are only 126 possible class A networks). When you register, you'll also need to choose a domain name. For the interested reader, reference [10] describes the rules and guidelines governing the distribution of the official IP address space.

IP address depletion

When the IP protocols were first devised, it was reasonable to assume that a 32-bit address space would satisfy all future demands. Unfortunately, this is now known not to be the case; over the past decade the number of networks on the Internet has been roughly doubling annually, and the distribution host space within the address classes varies enormously. The class A portion of the number space represents 50 percent of the total IP host addresses; class B is 25 percent of the total; and class C is approximately 12 percent of the total. By 1993, 38 percent of class A addresses, 45 percent of class B addresses, and only 2 percent of class C addresses were already allocated. Many new network addresses assigned in the late 1980s were actually class B, and it became apparent in 1990 that if this trend continued, the last class B network number would be assigned during 1994. Since class C networks were rarely being used, this made no sense at all. By 1996, all class A addresses were either allocated or assigned, as were 62 percent of class B addresses and 36 percent of class C addresses. The result is that the amount of address space currently available for new networks is quite limited and requires careful control. Because of these limitations, many organizations have been using privately assigned (unregistered) IP addresses, either because they were not expecting to use the Internet or because they did not want the constraints of building a network around a small number of registered addresses.

The reasons for IP address depletion are in part due to the inefficiency of the IPv4 addressing scheme, and the way in which addresses have been allocated to users, as follows:

• Address model inefficiency—There is a substantial difference between the number of host addresses allocated and those actually needed. Although the natural byte-aligned divisions of the IP address classes are simple and relatively user friendly, with hindsight it is not the most efficient scheme. The host space in class B networks is invariably too huge to be fully populated by the majority of organizations, and class C networks are simply too small to be useful in many cases.

• Demand for class B—Many users realized that a class B address was future proof (accommodating up to 65,534 hosts). Since it makes sense to use the largest address space available, even designers of small networks chose class B addresses. Since many class B networks were also being assigned to small networks (well below 65,534 hosts), these networks effectively locked out huge areas of the address space.

• Inflexibility and hidden costs for class C—Many users regard class C addresses (with a maximum of 254 hosts) as extremely limiting. Clearly, one could use multiple class C networks; however, this could be much more expensive in real terms, since routers are required to communicate between each network and more sophisticated designs are required.

A network of 5,000 hosts could be supported by a single class B network (65,534 hosts) or 20 class C networks (2 × 254 = 5,080). While the class B address copes with this requirement comfortably, it is only 7.6 percent efficient (5,000/65,534), locking up 92.4 percent of perfectly good address space. On the other hand, our class C approach is 98 percent efficient but requires special techniques such as supernetting (described in section 2.5.4) to deal with the fact that we now have 20 routing advertisements to cope with.

IP address allocation guidelines

As a result of these problems, several measures have been put in place to avoid complete depletion as the number of new networks requiring Internet access rises. Since 1990, the number of assigned class B networks has been increasing at a much lower rate than the total number of assigned networks, due largely to the introduction of tighter address allocation policies by IANA. In 1993, much stronger constraints were introduced in the address allocation guidelines outlined in RFC 1466 (made obsolete by [10]). In late 1996, these policies were refined further and are briefly summarized as follows:

• The IANA and the IR retain sole responsibility for the assignment of class A network numbers. The upper half of the class A address space (network numbers 64 through 127) is reserved indefinitely to allow for the possibility of using it for transition to a new numbering scheme. The lower half of the class C address space (network numbers 192.0.0 through 207.255.255) is divided into eight blocks, which are allocated to regional authorities, as shown in Table 2.3. The upper half of the class C address space (208.0.0 through 223.255.255) remains unassigned and unallocated. In Table 2.3 others are to be used where flexibility outside the constraints of regional boundaries is required. Multiregional incorporates the class C networks that were already assigned before this scheme was adopted. The 192 networks were assigned by the InterNIC, and the 193 networks were previously allocated to RIPE in Europe.

  Table 2.3: Class C Address Allocation

  Address Range		Allocation
  From	To
  192.0.0	193.255.255	Multi-Regional
  194.0.0	195.255.255	Europe
  196.0.0	197.255.255	Others
  198.0.0	199.255.255	North America
  200.0.0	201.255.255	Central & South America
  202.0.0	203.255.255	Pacific Rim
  204.0.0	205.255.255	Others
  206.0.0	207.255.255	Others

• One of the key factors in determining how much address space is appropriate for an organization is the expected utilization rate of the network. This is expressed as the number of hosts attached to the network divided by the total number of hosts possible on the network. In addition, the estimated number of hosts should be projected over a reasonable time frame—that is, one in which the requesting enterprise has a high level of confidence. The minimum utilization rate is set by the IANA. Depending upon the type or number of addresses requested, details of the network design and intended numbering plan may also be required.

• In effect, the traditional concept of IP assignment by address class has been abandoned. To maximize use of address space, IP addresses are now assigned in classless blocks (i.e., by prefix length). Consequently, an organization that would previously have been assigned a class B will now be assigned a /16 prefix, regardless of the actual address class.

• The use of static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged.

• CIDR addresses (discussed in section 2.5.4) are allocated to ISPs in blocks, and fragmentation of blocks is discouraged. ISPs are recommended to treat address assignments as loans; if a customer terminates the ISP contract, it is recommended that the address be returned and the customer should renumber (presumably from a new ISP's address space). The ISP should allow sufficient time for the renumbering process to be completed before the IP addresses are reused. This recommendation could prove interesting for large organizations unhappy with their ISP, since the burden of renumbering could be significant.

Many of the guidelines are rightly concerned with controlling the rate of address allocation based on quantifiable measurements—that is, predicted and achieved consumption rates provided by the ISP or requesting organization. There is also more emphasis on documented evidence, such as accounting and historical address allocation data and future deployment plans. The complete guidelines can be found in [10]. In particular, the move toward prefix-based allocation will become apparent in the following sections; this is not a permanent solution to the overall IP address space constraints but will help in the interim. A long-term solution is available with IPv6, as discussed in section 2.1.7.

2.1.6 Private intranet addressing

Another approach to conservation of the IP address space is described in [11] and is generally referred to as private IP addressing. Private addressing relaxes the rule that IP addresses must be globally unique, by reserving part of the official IP address space for networks that are used exclusively within a single organization and that do not need to communicate publicly (e.g., over the Internet). A large organization may feel, for example, that a set of class C addresses or a subnetted class B address may be too clumsy or inflexible to deal with and may choose its own addressing scheme. In this event you are strongly advised not to choose just any address at random. The only application where unregistered addresses are appropriate is for lab-testing equipment in isolation (where you may, in fact, need to replicate legal addressing to simulate a customer network).

Registered private addresses

It turns out that there are three official IP address blocks that have been reserved by IANA for private use [11]. The fact that addresses will not be unique is irrelevant, since by definition all users of these addresses must be running their networks in isolation. The following chart lists these addresses.

From	To	Prefix	Class
10.0.0.0	10.255.255.255	/8	A
172.16.0.0	172.31.255.255	/12	B
192.168.0.0	192.168.255.255	/16	C

The first block is a single class A network number, while the second block is a group of 16 contiguous class B network numbers, and the third block is a group of 256 contiguous class C network numbers. Any organization can use any of these addresses privately. You are, therefore free, for example, to build a huge class A network, so long as its address is 10.x.x.x/8. The advantage of this scheme (at least from the Internet's point of view) is that if you should accidentally connect into the Internet via an ISP, then your traffic should be discarded. Since ISPs are aware of these addresses, they should filter any traffic originating from these addresses to avoid any duplicate addressing issues.

Migrating to public network access

If access to public networks is subsequently required by an organization, regardless of whether it has chosen an illegal or an RFC 1918—compliant addressing scheme, then the choices are as follows:

• Obtain registered addresses and reconfigure all network attached devices (as described in section 2.1.5).

• Use application gateways or application proxies, which are legally addressed on their public interfaces.

• Use Network Address Translation (NAT) to convert legal to private addresses dynamically at the public-private edge.

It is not hard to obtain legal addresses, but the implications for a large enterprise in terms of redesign and reconfiguration could be daunting. A business may not sanction the need to take the network offline while this work is done, and a less aggressive migration path may have to be found. Application proxies are widely available for most of the common IP-based services (such as FTP, HTTP, and SMTP). Proxies have the added bonus of providing a good security barrier, as described in Chapter 5. The downside is that they are not transparent and require all users to be relayed through them, leading to potentially serious throughput and latency problems. Since proxies are also application specific, they can limit flexibility; it is difficult to find good proxies for protocols other than TCP. Perhaps the most popular and convenient solution to this problem is Network Address Translation (NAT), discussed in section 2.5.2. NAT is a generic solution and completely transparent to users. NAT's flexibility means that access to public networks can be granted immediately, while remedial work to rework the network can take place in parallel. Furthermore, for increased performance NAT can be deployed in load-sharing clusters, as described in Chapter 6.

2.1.7 IP next generation (IPng)

Because of the well-publicized limitations of IPv4, in 1992 the IETF issued a call for proposals for a new version of IP, commonly referred to as IP Next Generation (IPng). IPng emerged in final form in late 1994 as IPv6 (the more observant will have noted the absence of IPv5; in fact, IPv5 exists today as the so-called stream protocol used in some routers). The designers of IPv6 paid particular attention to the following areas: addressing, performance, class of service, and security enhancements (outlined as major requirements in [12]). These features are discussed below and in subsequent chapters. For full details of IPv6 and the addressing architecture the interested reader is referred to [3, 13].

Message format

The IPv6 header is a radical departure from the IPv4 header format, as illustrated in Figure 2.6. The minimum header size is now 40 bytes (as opposed to 20 bytes with IPv4). The most significant change is the expansion of the address space to support 128-bit (16-byte) source and destination addresses (discussed in section 2.1.1). IPv6 also integrates strong security features via the IP Security Architecture (IPSec), as described in Chapter 5.

Figure 2.6: IPv6 message format. Only the version field (Ver) remains intact from the IPv4 format.

As indicated, the IPv6 header can be supplemented by a series of extension headers of variable length. The following extension headers are currently defined [3], listed in the order they would appear in the packet (if included):

• Hop-by-hop options header—for special operations that require hop-by-hop processing.

• Routing header—provides extended routing (such as IPv4 source routing).

• Fragment header—contains fragmentation and reassembly information.

• Authentication header (AH)—provides packet authentication and integrity for network security.

• Encapsulating Security Payload (ESP) header—provides privacy.

• Destination options header—provides additional data to be examined by the destination node.

The AH and ESP headers are an integral part of IPSec, and are discussed in more detail in Chapter 5. We now briefly review some of the more important aspects of this new format.

Field definitions

• Ver—The IP version number. Set to 6.

• Priority—Enables the source to specify the desired transmit and delivery priority on a per-packet basis. Packets can be assigned one of eight priority levels. This field also identifies traffic that is congestion controlled at source.

• Flow label—Enables the source to label packets for special handling by intermediate devices.

• Length—The payload length in bytes (i.e., all data following the mandatory 40-byte IP header).

• Next header—Signifies the type of header following the IPv6 header—either an extension header or a higher-layer protocol, such as TCP, UDP, OSP.

• Hop limit—The number of hops remaining valid for this packet. Set by the source and decremented by intermediate devices. The packet is discarded if a decrement operation results in zero.

• Source address—The address of the source node. Described further in the following sections.

• Destination address—The address of the destination node. Described further in the following sections.

• Extension headers—Special options headers. Described further in the following sections.

Addressing model

IPv6 supports three modes of addressing: unicast, anycast, and multicast, as follows:

• Unicast addresses operate as expected, in that they target individual host interfaces. There are several variations of unicast, including an IPv4-compatibility mode (intended to provide a smooth migration path). Unicast addresses may be assigned to multiple physical interfaces if the implementation treats the interface group as a single interface at the Internet layer (useful for load sharing over multiple physical interfaces).

• Anycast addressing is a refinement of unicast that streamlines routing. It identifies a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the nearest one, according to the routing metric employed).

• Multicast addresses operate as expected; they allow messages to be sent to a predefined group of interfaces with a single multicast address.

The IPv6 address model approaches host addressing in a manner subtly different from IPv4. IPv6 addresses are assigned to interfaces, not nodes. A node can have several interfaces and any of the unicast addresses assigned to an interface can be used as an identifier for the node. There are no broadcast addresses in IPv6; these are superseded by multicast addresses. In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain zero-valued fields or end in zeros. There are two special addresses to note, as follows:

• The unspecified address—The special address 0:0:0:0:0:0:0:0 must never be assigned to any node. It indicates the absence of an address. One example of its use is in the source address field of any IPv6 datagrams sent by an initializing host before it has learned its own address. The unspecified address must not be used as the destination address of IPv6 datagrams or in IPv6 routing headers.

• The loopback address—The special unicast address 0:0:0:0:0:0:0:1 may be used by a node to send an IPv6 datagram to itself. It may never be assigned to any interface. The loopback address must not be used as the source address in IPv6 datagrams that are sent outside of a single node. An IPv6 datagram with a destination address of loopback must never be sent outside of a single node. Note that [14] states that the IPv4-compatible IPv6 address ::127.0.0.1 should also be treated as a loopback address for migration purposes.

Address format

The address field in IPv6 is 128 bits (16 bytes) wide, as illustrated in Figure 2.2. This is four times wider than the IPv4 address space, and so unfortunately requires a new syntax. The preferred form for writing IPv6 addresses is H:H:H:H:H:H, where H is a hexadecimal 16-bit piece of the address. For example:

• FF0E:0:0:A0B9:0:23

• FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

• 1080:0:0:0:8:800:200C:417A

It is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field. Having said that, in IPv6 it is common for addresses to contain long strings of zeros. Reference [13], therefore, specifies the use of the special shorthand indicator ::, which can be used once in the address to compress arbitrary length strings of zeros. For example:

Address	Shorthand	Type
1080:0:0:0:8:800:200C:417A	1080::8:800:200C:417A	unicast
FF01:0:0:0:0:0:0:43	FF01::43	multicast
0:0:0:0:0:0:0:1	::1	loopback
0:0:0:0:0:0:0:0	::	unspecified

In mixed IPv4 and IPv6 environments it may also be beneficial to use the form H:H:H:H:H:H:D.D.D.D, where H is a 16-bit hexadecimal value and D is an 8-bit decimal value corresponding to the standard IPv4 representation. For example:

• 0:0:0:0:0:0:193.128.68.1

• 0:0:0:0:0:FFFF:12.100.50.77

Clearly, in an IPv6 environment the importance of name services (described in section 2.3) will be brought to the fore! For the interested reader [14] provides useful material on IPv6 addressing formats with several examples.

Address type representation

As with IPv4, the leading bits in the address field determine the address type. In IPv6 this is called the Format Prefix (FP). The initial allocation of these prefixes is shown in the following chart.

Allocation	Prefix (binary)	Fraction of Address Space
Reserved	0000 0000	1/256
Unassigned	0000 0001	1/256
Reserved for NSAP Allocation	0000 001	1/128
Reserved for IPX Allocation	0000 010	1/128
Unassigned	0000 02	1/128
Unassigned	0000	1 1/32
Unassigned	0001	1/16
Unassigned	001	1/8
Provider-Based Unicast Address	010	1/8
Unassigned	02	1/8
Reserved for Geographic-Based Unicast Addresses	100	1/8
Unassigned	101	1/8
Unassigned	20	1/8
Unassigned	210	1/16
Unassigned	220	1/32
Unassigned	22 10	1/64
Unassigned	22 20	1/128
Unassigned	22 210 0	1/512
Link Local Use Addresses	22 210 10	1/1024
Site Local Use Addresses	22 210 2	1/1024
Multicast Addresses	22 22	1/256

Unicast addresses are distinguished from multicast addresses by the high-order octet: a value of 0xFF (binary 2222) identifies a multicast address; any other value identifies a unicast address. Anycast and unicast addresses use the same FP and the same address space. Note that the unspecified address, the loopback address, and IPv6 addresses with embedded IPv4 addresses are assigned out of the 0000 0000 FP space. For full details of the IPv6 addressing model the interested reader is referred to [13].

Performance

IPv6 has the potential to improve performance in three ways, as follows:

• Fewer header fields. Although the IPv6 header is twice the size of the IPv4 header (see Figure 2.2), it contains fewer fields (8, as opposed to 12 in IPv4), reducing the processing overhead on routers.

• Fixed-length headers. IPv4 supports variable-length options in the header; this complicates packet processing in routers and end systems. IPv6 has a fixed 40-byte header.

• No fragmentation. IPv6 determines the MTU requirements of intermediate networks at source by using an algorithm to discover the lowest MTU supported over the transmission path. This negates the requirement for fragmentation and reassembly at the expense of the discovery process (especially useful in long-haul networks over mixed media types).

On the downside, addresses are significantly larger, so any address manipulation operations will spend more time parsing. Routing table entries will also be significantly larger, so routing protocols need to carry more payload, and memory requirements on routing systems generally will increase.

Migration to IPv6

IPv6 is designed to ease the task of migrating from IPv4, but nobody seriously expects the process to be without a great deal of pain and cost. Features such as IPv4-compatible addressing and IPv6-over-IPv4 tunneling at least make coexistence possible, but there are several major obstacles to overcome, including the following:

• The memory requirements for intermediate devices and devices that manipulate and store address—based data (e.g., routers, switches, and firewalls) are increased by a factor of four (worst case) for network addresses. These devices will also need to support both IPv4 and IPv6 devices in the interim.

• During the transition phase IPv6 hosts are likely to have both a 32-bit IPv4 address and a 128-bit IPv6 address. This causes extra problems for applications such as the Domain Name System (DNS), which will have to respond to queries from IPv6 hosts with both addresses. The implications for DNS resources and performance are significant.

• The installed base of TCP/IPv4 applications, tools, and services is huge and have for years assumed 32-bit IP addresses. The ability to manipulate and store larger addresses is almost certainly going to require some element of redesign, as are the user interfaces. In the interim these applications will be unable to communicate with IPv6 hosts without some form of intermediate gateway.

The transition to a pure IPv6 network will be gradual, although there is mounting pressure to deploy migration services now. IP addresses are becoming increasingly scarce, as organizations expand and demand for Internet access increases daily. All of the major router vendors have already implemented, or are planning to implement, IPv6 in their operating systems in preparation for the road ahead. The interested reader is referred to [15].

2.1.8 Autonomous System Numbers (ASNs)

At the top of the IP address hierarchy is a layer of abstraction called the Autonomous System (AS). An AS is essentially a group of LANs and WANs interconnected via routers, under common administrative control (i.e., having a single routing policy). ASs are identified by a globally unique Autonomous System Number (ASN). This number is used in both the exchange of exterior routing information (between neighboring ASs) and as an identifier of the AS itself. ASNs are, therefore, configured on routers and routing protocols and are entirely transparent to users. They are primarily an administrative addressing layer used to constrain and route traffic. Furthermore, ASNs are applicable only to routing nodes that run exterior gateway routing protocols such as BGP and IDRP. End systems are not configured as AS members.

ASNs are 16 bits wide, and, therefore, a total of 65,535 ASNs are possible. ASNs are ultimately administered by the IANA. The IANA has reserved the block of ASNs between 64,512 and 65,535 for private use (these ASNs are not to be advertised publicly). This leaves only 6,452 ASNs for user allocation, so this address space requires careful monitoring and strict control over registration if it is not to be depleted. In March 1996 approximately 5,100 ASNs had been allocated, with approximately 600 actively routed over the Internet [16]. Commercial organizations must register for an official ASN; it is not recommended that you choose your own, particularly if you intend to attach your network to a public network such as the Internet. The basic criteria for deciding whether an ASN is required are summarized as follows:

• Exchange of external routing information—An ASN is required for exchanging external routing information with other ASs through an exterior routing protocol such as BGP. Note that the exchange of external routing information alone does not constitute the need for an AS.

• Many prefixes, one AS—As a general rule, one should try to place as many prefixes as possible within a given AS, provided all of them conform to the same routing policy. So, for example, a single-homed site with a single prefix should use the ASN of the provider and does not require one of its own. The same is true for a single-homed site with multiple prefixes. A multihomed site attached to different service providers and different ASs does, however, require its own ASN.

• Unique routing policy—An ASN is required when you have a routing policy that differs from that of your border gateway peers.

For ease of use ASNs are generally represented using the familiar dotted-decimal notation, although the ASN number space is entirely flat, with no prefix or class bits to worry about. For example, 1.0.0.1 is a valid ASN number. Note that ASNs are also configured on routers running hierarchical interior routing protocols (such as OSPF and Dual-IS-IS). In this case, however, ASNs are used as routing tags, and in practice are not seen by exterior routing protocols. You could, therefore, use your own ASN internal to your network; the key issue is not to configure a private ASN on your BGP-enabled interfaces pointing out to a public network. For further detail on routing operations refer to Chapter 3. For full details on registration and use guidelines refer to [16]. For an up-to-date list of assigned ASNs refer to [17].