IP Addresses

The Internet Protocol enables computers on many disparate LANs to find their way to one another; this is accomplished through the hierarchical IP address system. If you've ever done anything on the Internet at all, you're probably familiar with IP addressesat least enough to know what they look like. An IP address is typically used as a way to refer to a specific computer on the Internet, although its meaning is actually a lot more flexible than "one IP address per machine." Most generally, it's a logical designation whose purpose is to locate a machine on the Internet so that IP routers can direct traffic between it and any other machine.

An IP address is a string of 32 bits in the IP header, which specifies either what machine a packet came from or where it is destined (both addresses are present in the header). The 32 bits can be thought of also as four 8-bit bytes, each of which is expressed as a number from 0 to 255hence, the familiar four-part dotted-decimal notation, of the form 111.112.113.114. This allows it to be treated hierarchically when dealing with Class A, B, or C subnets, as we will discuss next.

There are a few "special" IP addresses to keep in mind. First is the network address. This is an IP address in which one or more of its bytes are zero, such as 64.41.131.0. If the final byte is a zero, the address is a synonym for the entire 64.41.131 network and is generally used only when configuring routers. More important is if one or more of the trailing bytes are 255 (all bits set to 1). This is the broadcast address for the network, an address that matches all hosts on that network as defined by the mask; for example, 64.41.131.255 matches all hosts on the 64.41.131.xxx network, and 64.41.255.255 matches all hosts on the 64.41.xxx.xxx network. A packet sent to the broadcast address will be received and processed by all hosts on the network, which is useful for finding out which host on the network has a certain Ethernet address. We will be discussing how these matching addresses work a little later when we discuss routing and subnets.

Subnets and the Network Mask

The network mask (or netmask), which travels hand in hand with IP addresses when you're configuring TCP/IP on a machine, is one of the most misunderstood parts of the whole structure, and yet potentially one of the most elegant when understood properly.

The purpose of the netmask is simply to tell a router or host whether a packet is supposed to go to the network it's on or go upstream to the next router. When a router receives an IP packet and it has to decide what to do with it, it checks the packet's destination IP address against its own netmask.

The netmask, a 32-bit string like an IP address, usually takes the form 255.255.255.0 (with a combination of 255 fields and 0 fields). Let's say you have a router managing the 64.41.131.xxx network. The router receives a packet addressed for 64.41.131.45. This address, in binary format, is matched against the netmask in an "and" fashion, where a resultant bit is set to 1 only if both addends are 1:

  0100 0000 0010 1001 1000 0011 0010 1101 (64.41.131.45) + 1111 1111 1111 1111 1111 1111 0000 0000 (255.255.255.0)   0100 0000 0010 1001 1000 0011 0000 0000 (64.41.131.0)

The result works out to 64.41.131.0, the address of the network your router manages. This packet is thus a match and passed on to the network over Ethernet, destined for the target machine. Another packet now comes in, destined for 64.41.189.45:

  0100 0000 0010 1001 1011 1101 0010 1101 (64.41.189.45) + 1111 1111 1111 1111 1111 1111 0000 0000 (255.255.255.0)   0100 0000 0010 1001 1011 1101 0000 0000 (64.41.189.0)

This result does not match the router's network address, and the router passes the packet upstream to the next router.

This mechanism allows you to set up subnets within your network. Let's assume you have a Class B address range to work with (64.41.xxx.xxx). Your network's main router, R1, manages this entire range, but you can put a router (R2) inside this network to manage two Class C address ranges: 64.41.131.xxx and 64.41.132.xxx. Hosts in the 64.41.131 network can be plugged into the same hub as hosts in the 64.41.132 network, as shown in Figure 22.7, but they won't speak directly to each other if their netmasks are set to 255.255.255.0, a Class C mask.

Figure 22.7. A network with subnets, demonstrating the packet path between two hosts whose netmasks don't permit them to communicate directly.

Destination IP addresses in sent packets won't match the senders' netmasks. However, if a sender host (H1) in 64.41.131 sets its netmask to a Class B mask (255.255.0.0), the addresses will match, and the sender would be able to send the packet directly to H2 (a host on 64.41.132). However, note that H2 won't be able to send its replies directly back to H1 because its netmask prevents this! It has to send the reply back via R2, which has multiple network addresses and subnets bound to its internal interface. You'd need to set H2's netmask to 255.255.0.0 for it to talk directly to H1 without going through the router.

Netmasks don't need to be aligned on the byte boundary, either. For this reason, they're sometimes specified in pure hexadecimal format (for example, 0xffffff00 rather than 255.255.255.0), as in the output of the ifconfig command in FreeBSD. You can specify a netmask of 0xffffffc0, for instance, or 255.255.255.192. This mask will match a network of 64 hoststhe ones between 1 and 64.

Another notation used in specifying networks that incorporates the netmask is Classless Inter-Domain Routing (CIDR), which takes the form of the network address, a slash, and the number of bits that make up the mask. For example, a mask of 255.255.255.0 on your 64.41.131 network would be written as 64.41.131/24 because the mask consists of three 8-bit bytes with all bits set to 1 (or 24 bits). The 255.255.255.192 example, likewise, would correspond to a notation of 64.41.131/26. This notation is seen in routing tables and other places where succinctness is useful.

Working with IP Addresses

Typically, a single IP address is bound to a single physical port (or interface) on an Ethernet card; this is only by convention, though, and you can bind multiple IP addresses to a single card if necessary. The only constraint is that no two Ethernet interfaces on the same network can share the same IP address. Every interface needs to have at least one unique IP address to function. You might choose to install two Ethernet cards in your system in order to have access to two different networks at once, for example, or one address might be bound to an Ethernet card while another refers to your wireless 802.11 card. Many Ethernet cards have multiple ports, and each one can have one or more addresses assigned to it. What configuration you choose depends on how your network is set up.

You can find out the IP addresses of any Ethernet cards and other network interfaces in your system using the ifconfig utility, as shown in Listing 22.1. The -a option shows all devices, or you can specify a specific interface (such as xl0) to single out. The inet line shows a configured IP address; the xl0 interface in this example shows multiple IP addresses bound to a single card.

Listing 22.1. Typical Output of ifconfig

[View full width]

# ifconfig -a xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500         inet 64.41.131.102 netmask 0xffffff00 broadcast 64.41.131.255         inet6 fe80::201:2ff:fe55:1256%xl0 prefixlen 64 scopeid 0x1         inet 209.154.215.246 netmask 0xffffffff broadcast 209.154.215.246         ether 00:01:02:55:12:56         media: autoselect (100baseTX) status: active         supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT /UTP <full-duplex> 10baseT/UTP 100baseTX <hw-loopback> lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7         inet6 ::1 prefixlen 128         inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552 faith0: flags=8000<MULTICAST> mtu 1500

IP Version 6 (IPV6)

Various groups, such as the KAME project (http://www.kame.net), have been working recently on incorporating support for the next generation of IP (version 6, or IPv6) into FreeBSD. IPv6 provides a 128-bit address space, with addresses effectively four times the size in IPv4 (the current version). The result is address space for 3.4x10^38 hostsa number that we're unlikely to reach anytime soon, to say the least. Also included in IPv6 are a number of other enhancements, such as built-in encryption and authentication, connection differentiation (with flow labels), complete auto-configurability of hosts, and the abandonment of several outdated parts of IPv4 that are no longer used.

IPv6 is catching on very, very slowly. Networks are expensive to build, and retrofitting them to be IPv6-compliant generally means replacing all existing equipment with newer, more expensive, less-mature hardware. Very few companies are willing to take that plunge just yet. But in the meantime, FreeBSD has full support for IPv6 and can take advantage of the various network resources currently available for IPv6.

Networking at the Ethernet Level

Every host is uniquely identified on the local network not by its IP address (which has no meaning at the Ethernet level), but by what's variously called the physical address, the hardware address, the Ethernet address, or the Media Access Controller (MAC) address. Every network interface device has a MAC address programmed into it at the factorya unique one, taking a form such as 00:01:02:55:12:56. The MAC address is theoretically supposed to be useful as a "fingerprint" identifier for an Ethernet card (and, thereby, a computer) because no two Ethernet cards in the world ideally share one. (This doesn't work out in practice, though, because MAC addresses can be forged.) There is no routing mechanism for a MAC address as there is for an IP address. It operates entirely at the physical link level on a LAN and can't be forwarded by a router.

ARP, the Address Resolution Protocol, is what maps IP addresses to MAC addresses. If your application wants to send a packet to the IP address 10.5.6.100, it sends the packet down the stack to the link layer. There, the stack consults the ARP cache, an OS-level table where known mappings between IP addresses and MAC addresses are stored. If the stack has never sent a packet to 10.5.6.100 before, that address won't be in the ARP table, and the TCP/IP stack must then perform an ARP query.

The ARP query is a broadcast packet, addressed to all Ethernet cards on the LAN (by setting the destination MAC address to ff:ff:ff:ff:ff:ff, or all bytes equal to 255, as with a broadcast IP address). The packet's payload is the IP address the stack is trying to look up: 10.5.6.100. Every machine on the network receives this packet, but only the machine with the IP address being sought replies, telling the sender what the recipient's MAC address is. After the stack receives the reply packet, its IP address and MAC address go into the sender's ARP cache for future use. The packet is then sent by the sending machine's TCP/IP stack onto the network destined for the intended recipient's MAC address only.

Note

Earlier in the chapter, we talked a little bit about how switches keep their own internal ARP caches. Now that you know how ARP works, you can see how switches can keep track of which hosts are found on which ports through the use of ARP. A switch performs its own ARP queries to determine where to find a host to which it must send a packet it has received. After it adds that ARP information to its own cache, it can direct future traffic to that destination address more quickly.

Routing Between Networks Using ARP and MAC Addresses

ARP is very efficient for figuring out which packets should go where on a LAN; but what if the machine you're sending the packet to isn't on the same network as the sender? Well, that's where routers come into play. A router receives and replies to ARP packets like any other host. When a router looks up its IP address bindings to see whether it should reply to the ARP packet, however, it finds that its internal routes are set up to send everything except traffic destined for the LAN it manages out onto the WAN toward the next upstream router. The router's TCP/IP stack sees this as a claim that the router has all nonlocal IP addresses bound to its Ethernet card on the LAN. As far as the router is concerned, it is the computer you're looking for, and it replies to the ARP as though it were.

The following steps are involved in a packet's journey from one host to another across the Internet:

• A host wants to send a packet to a host with an IP address that's on a remote network, so it sends an ARP request for the machine with that IP address.

• The local gateway router, which has all nonlocal IP addresses bound to its MAC address, replies that it is the destination host.

• The sending host's Ethernet card sends the packet to the router.

• The router alters the sender MAC address in the packet's headers to match its own MAC address and then forwards the packet on over the WAN.

• The next router on the WAN receives the packet and performs a similar operation, setting the sending MAC address to its own and forwarding it on, until it reaches a router with a specific routing rule for the IP network that contains the destination host.

• The final router receives the packet, determines from the destination IP address and its own netmask that the packet is destined for a machine on its own network, and uses ARP to find out which machine the recipient is.

• The recipient host replies to the router with its own MAC address.

• The router alters the packet's recipient MAC address to match that of the recipient host and then sends the packet directly over the LAN.

Checking ARP Cache Contents with the arp Command

ARP is handled transparently by applications and the TCP/IP stack; you'll probably never have to actually initiate ARP commands by yourself. However, there are some occasions when you'll need to tweak the ARP cache. You can check the contents of the cache by using the arp -a command:

# arp -a w001.sjc-ca.dsl.cnc.net (64.41.131.1) at 0:0:c5:7c:7:f0 [ethernet] w013.sjc-ca.dsl.cnc.net (64.41.131.13) at 0:30:65:a4:9a:5e [ethernet] w063.sjc-ca.dsl.cnc.net (64.41.131.63) at ff:ff:ff:ff:ff:ff permanent [ethernet]

Entries in the ARP cache do time out after a while, but there are times when you might need to clear the cache manually. Someone on the network might install a new Ethernet card in his machine and bind the old IP address to the new MAC address, which can make it unreachable if the old combination is still in your cache. You can delete cache entries by name, by IP address, or all at once (with -a):

# arp -d w001.sjc-ca.dsl.cnc.net # arp -d 64.41.131.13 # arp -d a

Note

The arp command can be a useful tool for tracking down rogue DHCP servers that give out incorrect IP information to hosts on a dynamically allocated network. If your host gets a bad IP address, enter the arp -a command to find out the MAC address of the DHCP server. A well-managed network has all machines cataloged by their MAC addresses, so you can look up the offending machine from the output of arp. Even if a MAC catalog is not available, the MAC address can help you narrow down your search for an offending machineusing the first three segments of the address string, MAC addresses are keyed to particular Ethernet card manufacturers, which might lead you to a particular brand of computer.