|
|
2.4. AddressingIn this section we discuss IP addresses, but before we begin, we should be clear on what that means. IP uses IP addresses to route packets from one host to another. These hosts may or may not be on the same physical networkon the same Ethernet cable, sayso an IP address is not the same thing as a physical address, such as an Ethernet address. In terms of Figure 2.3, IP addresses are used by the network layer, whereas physical addresses are used by the interface layer. A version 4 IP address is a 32-bit integer. IP addresses are usually written as four decimal numbers connected by dots; we call this dotted decimal notation. Each decimal number is the value of 1 byte of the 32-bit address. Thus, we would write 1.2.3.4 rather than 0x01020304 or, worse yet, 16,909,060. Traditionally, IP addresses were divided into five classes, as shown in Figure 2.6. The division of the address space into classes was intended to make address allocation more flexible. Class D addresses are used in multicastingsending an IP datagram to a group of hosts rather than to a specific host on the network. Class E addresses are used for experimental purposes, and we won't consider them further. Figure 2.6. IP Classful Addressing
Each interface on a host has at least one Class A, B, or C address assigned to it. These are the addresses that are used to send IP traffic to a specific machine.
Although part of the address, we can think of the first few bits of an IP address as identifying the network class, as shown in Figure 2.6. The network ID field identifies the network that this address belongs to. Routers use this field to route IP datagrams through the Internet or other wide area network (WAN). The size of the network ID field depends on the address class, which is determined by the leading bits. The host ID field identifies a particular host on the network specified in the network ID field. The host ID is arbitrary; the system administrator in charge of the network assigns it in any way that is convenient. This field is not used in routing datagrams outside its home network. Figure 2.7 shows the number of networks and hosts and the ranges for Class A, B, and C addresses.
The figure clarifies the distinction between Class A, B, and C addresses: Class A addresses are for the few networks with a huge number of hosts. Class C addresses are for the many networks with just a few hosts. Class B addresses are for networks with a moderate number of hosts.
Although classful addressing is still prescribed in the standards, it is too inflexible to meet the needs of modern networks. There are several problems with classful addressing, so let's consider it first from the point of view of the holder of a Class A or B address block. Conceptually, each network corresponds to a group of machines that are connected by some networking medium, such as an Ethernet cable. But no one puts 65 thousand, let alone 16 million, hosts on a single cable. Instead, the network is organized into several smaller segments, each with its own physical network medium, and these segments are connected with routers. Figure 2.8 shows an example of this with just two segments. Figure 2.8. Two Segments Connected by a Router
If host 1 wants to send an IP datagram to host 2, it need merely map host 2's IP address to its physical address and put the datagram on the wire. Now consider what happens if host 1 wants to send a datagram to host 4: Even if it knows or is able to determine host 4's physical address, host 1 can't send the datagram directly to host 4, because it's on a different physical network. Thus, host 1 must send the datagram to host 4 indirectly through router 2. This raises the question of how host 1 knows that it must send the datagram to router 2. One possibility is for router 2 to masquerade as the hosts on segment 2 for any host on segment 1, and as the hosts on segment 1 for any host on segment 2. For Ethernet segments, this is called proxy ARP.
When host 1 tries to map the IP address of host 4 to a physical address, router 2 replies with its physical address, and then forwards the datagram onto host 4 when it arrives. The problem with this solution is that it does not work with every type of physical network, and that even when it does, it doesn't scale well to complicated network topologies. Another possible solution is to add entries to host 1's routing table for each host on segment 2 listing router 2 as the next hop. This solution will work for any type of physical network but clearly doesn't scale to more than a few hosts. For a large network, the routing tables would be unworkably large and their administration daunting. The problem is that both segments have the same network ID. If we imagine for a moment that they had different network ID's, the difficulty largely disappears. Suppose that all the hosts on segment 1 have Class C addresses of the form 192. 168. 1. n and that all the hosts on segment 2 have addresses of the form 192. 168. 2. n. In this case, segment 1 hosts have a network ID of 192.168.1, and segment 2 hosts have a network ID of 192.168.2. We now need add only a single entry to the routing table of each host on segment 1 specifying router 2 as the next hop for network 192.168.2. We add a similar entry to the routing table of each host on segment 2. We can easily see that this method would scale well to large networks. This solution brings its own problems, however. When both segments had the same network ID, hosts outside the network needed only a single routing table entry to route to any host in the network. If each segment has its own network ID, outside hosts will need a routing table entry for each segment. That doesn't matter much for a single organization with two segments, of course, but imagine thousands of organizations with hundreds of segments, and the problem becomes clear. Routers, especially the high-speed routers in the Internet's core, often put their routing tables in special highspeed memory on the link interface cards, and because the amount of this memory is limited, the large routing tables envisioned by our solution wouldn't work.
What we need is a solution that lets hosts inside an organization see each segment as a separate network but that lets hosts outside the organization see a single network. A simple solution of this sort, called subnetting, does exist. The basic idea is that part of the host ID is used to specify the segment, or subnetwork, and the internal routers know about this. External routers don't concern themselves with the host ID portion of the address, so they need only a single routing table entry for the entire organization's network. The complete details are given in RFC 950 [Mogul and Postel 1985]. CIDRSubnetting is subsumed in a more general solution, so rather than discuss it in detail, let's consider the problems of classful addressing from the point of view of an organization that needs several hundred or thousand IP addresses. Ideally, such an organization would like a Class B address block. A single Class C block doesn't have enough addresses, and using several Class C blocks reintroduces the problem of routing table growth. As we see from Figure 2.7, only 16 thousand Class B address blocks are available, and most of those have already been assigned. That leaves multiple Class C address blocks as the only solution. To avoid the problem of routing table growth, we use a scheme called classless interdomain routing (CIDR). An example will make clear how CIDR works. Suppose that an organization needs 1,000 IP addresses. Under CIDR, we would allocate the organization four Class C blocks that share the same most significant bits200.10.4.0 through 200.10.7.0, say. Note that the upper 22 bits of each address in these blocks are the same. We use these 22 bits as the network ID for the organization, and we write the network ID as 200.10.4.0/22. The "22" is called the prefix, or network mask.
Notice that 200.10.4.0/22 and 200.10.4.0/24 are not the same: The first has a network ID of 0x320281, whereas the second has a network ID of 0xc80a04. Obviously, routers must know the subnet mask so that they can extract the network ID to route the datagram. Thus, under CIDR, the network mask becomes part of the routing table entry for all routers. Recall that with classful addressing, external routers didn't need this information, because they used the first few bits of the IP address to determine the portion of the address making up the network ID. CIDR solves the opposite problem too. Suppose that instead of an organization needing 1,000 addresses, we have a home network that needs only 5. In that case, we can allocate part of a Class C block200.10.4.0, sayby using a 29-bit prefix. Note that we can suballocate the block into 32 such smaller networks. The classless part of CIDR comes from the fact that we completely ignore the original division into Class A, B, and C addresses, and use the network mask to determine the network ID instead. Thus, even though we often hear people say that 200.10.4.0/22 combines four Class C blocks or that 200.10.4.0/29 is part of a Class C block, in reality, Class C blocks no longer exist. CIDR generalizes the Class A, B, C division by allowing us to fix the network/host ID boundary at any bit. Now let's review how CIDR solves the problems with classful addressing. We've just seen how it remedies the problem of Class B address block depletion by combining Class C blocks, and how it helps with IP address depletion in general by allowing networks with fewer than 254 hosts. Our organization with the 200.10.4.0/22 network will probably partition its network into several segments as we discussed above. This reintroduces the internal routing problem that using more than one segment entails. However, because the network mask is part of the routing table entry, the internal routers can use a different prefix. For example, suppose that the organization divided the 200.10.4.0/22 network into four segments. The segments would have the network IDs 200.10.4.0/24, 200.10.5.0/24, 200.10.6.0/24, and 200.10.7.0/24. The internal routers would have a routing table entry for each of these segments with a prefix of 24 and a next hop of the appropriate router.
To help make these ideas clear, let's assume that our example organization with the 200.10.4.0/22 network decides to split the network into two segments, as in Figure 2.8. The system administrator might decide to assign the hosts on segment 1 to the 200.10.4.0/23 network and the hosts on segment 2 to the 200.10.6.0/23 network. Figure 2.9 shows the two segments of Figure 2.8 redrawn and labeled with their network addresses. Each router interface has been labeled with the network address that it reaches, and each host has been labeled with the last 2 bytes of its IP address. Figure 2.9. Two Segments with Suballocated Network Addresses
What would the routing table for host 1 look like? Because it is directly connected to the 200.10.4.0/23 network, it can send datagrams to hosts on that network directly and doesn't need a next hop. We'll indicate that by specifying the next hop as "local." The only way to reach the 200.10.6.0/23 network is through router 2, so we will need an entry for that. All other datagrams will have destinations outside the 200.10.4.0/22 network, so we will need a default route listing router 1 as the next hop. Thus, our routing table would look like Figure 2.10.
Suppose again that host 1 wants to send a datagram to host 4. As shown in Figure 2.9, host 4 has the IP address 200.10.6.1. Host 1 will consult each entry in its routing table and will AND the network mask of the entry with 200.10.6.1. If the result matches the route, then this is a candidate entry to use for routing. If more than one entry matches, the one with the longest match is used. In this case, the 200.10.6.0/23 entry is the best (and only) match, so host 1 will send the datagram to router 2. CIDR is discussed in detail in RFCs 1517, 1518, and 1519 [Hinden 1993, Rekhter and Li 1993, Fuller, Li, Yu, and Varadhan 1993]. Tip 2 of ETCP discusses subnetting and CIDR in a little more detail. Broadcast AddressesBefore leaving the subject of IP addressing, let's take a quick look at broadcast addresses, which are used to send a datagram to all hosts on a segment or a network. With CIDR, there are two types of broadcast address:
A datagram cannot be broadcast outside the network of the host sending it. If we think about the mischief that a malefactor could cause by being able to broadcast a datagram to every host on the Internet, we see that this restriction makes sense. For example, a broadcast with a forged source address would cause every receiving host to reply, resulting in a very efficient denial-of-service attack. The limited broadcast address is 255.255.255.255. It is called limited because routers will never forward datagrams with that destination address. This means that datagrams with the limited broadcast address are confined to the particular network segment on which they originate. A typical use for the limited broadcast address is for a host to map an IP address to a physical address. With Ethernet, for example, a host wishing to determine the physical address of some other host from its IP address broadcasts a request asking the holder of that IP address to send the original host a message with its physical address. All hosts on the segment will receive the request, but only the holder of the target IP address will respond. Other uses are with the Dynamic Host Configuration Protocol (DHCP), used by hosts to obtain an IP address when they boot, and the BOOTP protocol, used by diskless workstations to get their boot images. The network-directed broadcast address has the normal network ID of the specified network, and the host ID set to all ones. Thus, if host 1 of Figure 2.9 wanted to send a broadcast message to every host on the 200.10.4.0/22 network, it would address the datagram to 200.10.7.255. Because of security problems with this type of address, routers are often configured to not forward them.
 |
|
|
