The Internet Protocol (IP) | IPv4

Ethernet defines how devices can be physically connected. But users do not know the Ethernet addresses of the devices providing the services they wish to use. More intelligence is needed to separate out the physical addressing, replacing it with logical addressing that an administrator can decide on, and allow multiple physical networks to be connected. The Internet Protocol (IP) defines how this addressing and packet formatting is to occur.

IP was originally specified in RFC 791 and expanded upon later, and comes in two versions: version 4 (IPv4) and version 6 (IPv6). The two main concepts for IP are the IP addressand IP frame.

IPv4

IPv4 is the version used most often on the Internet today, by a wide margin. IPv4 uses a four-byte address written out as dotted decimal numbers, such as 192.168.0.1. These addresses are given out by an international agency in blocks for large organizations to use. Generally, individual IP addresses are provided to organizations by their Internet service providers. Ranges of addresses tend to be specified using the slash notation. For example, 192.168.0.0/16 means that the upper 16 bits are what was written, and the rest are within the range defined by allowing the remaining lower bits to be set to any value.

Of the 32-bit address space, some of the addresses have special meanings. The 127.0.0.0/8 address range is for loopback networking, and, when used as a destination, are kept internally to the machine that is doing the sending. This allows an IP device to send packets to itself. The 169.254.0.0/16 range is for link-local addresses, meaning that their use cannot extend past the Ethernet switching network they are used on. In addition, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are all private addresses. These are the addresses most commonly used in voice mobility networks within the enterprise. They are not valid on the public Internet itself, but are designed for private networks based on IP. The 224.0.0.0/4 network is used for multicast traffic: each address is a different multicast group. Finally, the 255.255.255.255 address is the link-local broadcast address, meant to go out to all devices on the Ethernet switching network (and using the FF:FF:FF:FF:FF:FF Ethernet broadcast address for the underlying packet).

IPv4 runs on Ethernet by setting the Ethernet type to 0×0800. The IP packet has a header and payload, as shown in Table 1.

Table 1: IPv4 Packet Format

Table 2: The Version/Header Length Field

	Version	Header Length
Bit	0-3	4-7

The Version/Header Length field is specified in Table 2. For IPv4, the version is always 4. The header length measures how long the header is (up to the data field), in four-byte increments. The Type of Service/Diffserv Code Point (TOS/DSCP) field is used to specify the quality-of-service properties of the packet. The Total Length measures the entire length of the packet, and will come into play with fragmentation. The Identification field is used to track which fragments belong to the same overall packet; between separate packets, most devices tend to increment this by one, although this is not required. The Fragment field specifies what the offset is for this fragment in the entire packet. The TTL (Time To Live) field is used for forwarding, and specifies how many times this packet can be forwarded before it is dropped. The Protocol field specifies what higher-layer protocol is used on top of IP for this packet. The Header Checksum is a literal one's complement 16-bit sum of the header of the packet, and is used to detect if the underlying network flips a bit by mistake. (The Ethernet CRC is adequate for that purpose, so this field, although always set and always checked, is not terribly useful.) Finally, to the interesting information. The Source and Destination fields hold the IP addresses of the originator and final destination of this packet. The header ends here, and is followed by the next protocol's headers or data. This entire set of bytes is the payload of the underling Ethernet frame.

IP is designed to be relayed, or forwarded, between computers, across different network segments, and across the world if needed. This is the major distinction for IP, as it hasallowed the Internet to be constructed from an assembly of smaller networks. The idea is that any IP-connected device that has multiple links can forward messages if configured to do so. Each link has its own IP address, as required. When an packet comes in for an IP address that is not that of the machine (how that happens will be mentioned in a moment), the device will look up a routing table to find out where the next machine is that this packet needs to go to. IP forwarding works on the concept of longest-prefix matching. Because there are too many IP addresses for a machine to know about, and because the IP address space tends to be organized in ranges, the forwarding device (arouter in this context) looks up a series of routing rules that it has configured. Each routing rule is set up as a network prefix (as specifiable by slash notation), and the IP address of a machine that is on one of the links the router has. This address is the next hop. Because a destination address might match more than one rule, the one rule that matches the most leading bits-the longest prefix-will win, and that next hop will be used.

This concept of next hops explains why a router or machine may get a packet for a different destination IP address than it uses for itself. If another machine is set up to forward packets to it—and any machine can be set up to forward to any other, without restriction, so long as both are on the same switching network—then the first machine will get packets for other devices. The concept of prefix routing makes sense when you think of most enterprise routers. Enterprises, all but the largest, usually have a limited number of address ranges that are used locally. All of the rest, every other one, is out on the Internet. Connecting the enterprise to the Internet is one Internet router. The enterprise routers thus need only to have forwarding rules for the address ranges that they have in the enterprise, plus one route, called a default route, that tells the IP address of the Internet router. This default route uses a 0.0.0.0/0 prefix, meaning that every address matches, because the prefix is trivially short. Therefore, longest-prefix matching ensures that the default route matches last. Nonrouters will normally only have this default route, because they will not forward other devices' traffic. In this way, locally generated traffic is forwarded, even when other traffic will not be. The final bit of information to know is that not all traffic is forwarded on to next hops. Each link into the system has not only an IP address but asubnet mask, or a prefix that specifies what other IP addresses are directly on that link. For example, using the same slash notation, 192.168.10.20/24 states that the IP address of the link is 192.168.10.20, and all IP addresses starting with 192.168.10 are directly on the link, and do not need to be routed to the next hop. Those direct-link addresses belong to the same subnet. Every time the frame is forwarded, the TTL is reduced by one. Once it hits zero, the packet is dropped, rather than forwarded. Nothing else is modified while the packet is forwarded—the source and destination addresses are always those of the originator and the final destination of the packet.

Because IP runs on top of Ethernet, there must be a way to map IP addresses to Ethernet addresses. Every IP address has an Ethernet address—that of the Ethernet device the IP address was assigned to. When a sender needs to send out an IP packet, and it has used its forwarding logic to figure out which link the next hop or final destination is on, the sender needs to use a resolution protocol to ask the devices on the network for which one has the IP address it needs. The protocol is called the Address Resolution Protocol(ARP). ARP runs on a different Ethernet protocol type 0×0806. The idea is that each sender maintains an ARP cache. This cache stores the Ethernet address that is known for a given IP address. The cache is updated whenever another device sends a packet to the first one, as the Ethernet source address is assumed to be bound to the IP source address, so long as that IP address is on the same subnet. However, if the cache does not have an address mapping that is needed, the sender will send an ARP request to the network. These ARP requests are broadcasted using Ethernet, and any device that receives the ARP request and has that IP address is required to respond, unicast to the ARP sender, acknowledging the binding with another ARP message. The format of an ARP message is shown in Table 3.

Table 3: ARP Message Format

For Ethernet networks, the Hardware Type is always 1, and the Protocol Type is always 0×800. The Hardware size is the length of the Ethernet address, 6. The Protocol Size is the length of the IP address, 4. There are two opcodes: 1 is for a request, and 2 is for a reply. Finally, the addresses state the mapping that is requested or being answered for. When a machine requests to find out which other device has an IP address, it will send its Ethernet and IP addresses as Sender, and the IP address it is looking for as Target, with the Target Ethernet set to 0. The respondent will fill in its Ethernet and IP address as sender, the original requester's Ethernet and IP as target, and then send the response back.

With ARP, the binding of IP addresses to Ethernet addresses can be dynamic and changing.

Earlier, the concept of fragmentation was alluded to. IP provides a service that lets a packet be split across a number of smaller packets. The reason for this is that IP is meant to be carried over a wide variety of link-layer technologies, not just Ethernet, and those technologies may have a different maximum payload size. To make sure that a packet that is of a valid length that is sent in one network can arrive safely at the other, the concept of fragmentation was introduced. The router, or sender who has a packet which is too large, and which does not already have the "Do Not Fragment" bit in its Fragment field set, will divide the packet into two or more smaller ones, each with a copy of the original IP header.

The data fields will be the individual segments, with the offset of the first byte of the data field from the start of the original (or reassembled) packet being given in the Fragment field. The fragments are sent over the network, and the receiver is required to reassemble all of the fragments before sending it up to the higher layers. The receiver knows that it has reached the end of the fragment chain by looking at the "More Fragment" bit in the Fragment field. The last fragment will not have that bit set. All fragments of an original packet share that packet's original Identification field. The maximum size of an IP packet, including all headers, is 65,535 bytes.

IP, like most other packet networking technologies, makes no guarantees as to whether a packet will arrive at its destination. Packets may arrive with arbitrary delays, and may even come out of order (although this is to be discouraged). This best-effort delivery guarantee-the network will try, but will not commit resources up front-is key to IP's success. It, unfortunately, also runs counter to the goals of voice.

Clearly, IPv4 is the bread-and-butter protocol for voice mobility. What was presented here was a brief, high-level survey, and readers are encouraged to fill any major gaps in understanding before undertaking major roles in voice mobility networks.

Internet Protocol Security (IPsec)

The work on the IP security suite protocol (IPsec) is carried out in the ipsec working group (www.ietf.org/html.charters/ipsec-charter.html) in the security area of the IETF. We strongly recommend Kaufman and Newman (1999) if you would like a detailed treatment of the subject and its business applications.

RFC 2401 defines the design goal of the IP security (IPsec) protocol as the means to provision interoperable, high-quality, cryptography-based security for both versions of IP protocol—IPv4 and IPv6. In a nutshell, the IPsec suite provides privacy (through encryption) and authentication services at the IP layer (which, among other things, means that application and transport security as well as data link layer security are outside of the scope of the IPsec suite). The services provided by the suite include access control, connectionless integrity, confidentiality, and protection against replays (that is, reuse of snooped messages).

To provide these services, first, two traffic security protocols are defined:

§  Authentication Header (AH) (RFC 2402). Provides connectionless integrity, data origin authentication, and an (optional) antireplay service.

§  Encapsulating Security Payload (ESP) (RFC 2406). Provides one of the two sets of services:

1.  Confidentiality and limited traffic flow confidentiality.

2.  Integrity, data origin authentication, and an antireplay service.

Each of these protocols can be used in either transport mode (where transport protocols are protected) or tunnel mode (where the IP itself is protected). Tunnel mode is particularly important to VPN services in connection with IPIP (RFC 2003).

Second, algorithms for encryption and authentication as well as automatic key management schemes (such as RFC 2408 and RFC 2409) are defined, each in a separate RFC. The informational RFC 2411 provides guidelines for specifying new encryption and authentication algorithms and explains the interrelationship of all the protocols and algorithms in the IPsec suite.

The interrelationship of the elements of the IPsec architecture is demonstrated in Figure 1. The ESP and AH protocol documents cover the packet format and general issues of these protocols. They also define the default and mandatory values (as, for example, specified in RFC 2407) that are fed into the domain of interpretation (DOI) document, which deals with assigned values. The ESP protocols can use various encryption algorithms (for example, those specified by RFC 2405 and RFC 2451) as well as authentication algorithms (for example, those specified by RFC 2403 and RFC 2404). The authentication algorithms are also used by the AH protocol.

Figure 1: IPsec architecture.

Source: RFC 2411.

Both the encryption and authentication algorithms may also specify values for the DOI (for example, the values that identify these algorithms). Finally, the key management documents specify the IETF standards-track key management schemes, which also define the values for DOI. The IPsec DOI also supports negotiation of IP compression (as specified in RFC 2393); this function may be necessary because the encryption of IP payload prevents compression at lower layers. For example, a message containing a string of 50 octets filled with 0s could have been successfully compressed to something much smaller than 50 octets had it not been for the encryption, which—by design—not only changed 0s to other values but also eliminated the pattern.

Overall, IPsec provides security services at the IP layer by selecting (1) appropriate security protocols, (2) algorithms to be used with these protocols, and (3) appropriate cryptographic keys. The major function of the Internet Key Exchange (IKE) protocol (RFC 2409) is to establish and manage security associations (SAs), a function supported by both AH and ESP.

The concept of SAs is fundamental to IPsec. RFC 2401 defines an SA as a simplex connection that affords security services to the traffic carried by it. These services can be afforded by either AH or ESP, but in the case where both are to be employed, two SAs need to be established. An SA is uniquely identified by the following triplet:

1.  Security parameter index (SPI).

2.  IP destination address. Although this can in principle also be a broadcast or multicast address, only the unicast address is presently supported by the IPsec management mechanism.

3.  Security protocol identifier (that is, AH or ESP).

RFC 2401 defines two types of SAs—transport mode SA and tunnel mode SA—to support the AH and ESP modes of operation, respectively. As Figure 2 demonstrates, the transport mode SA is an association between two hosts. The double arrows are used only to indicate the nodes between which the SAs are established, not to imply by any means that that the SAs are duplex! The tunnel mode SA, however, may be established between:

§  Two security gateways. A security gateway is defined in RFC 2401 as an intermediate system that acts as the communications interface between two networks.

§  A host and a security gateway.

§  Two hosts.

Figure 2: Two types of security associations (SAs).

Any SA that supports tunneling (that is, an SA between a host and a security gateway or two security gateways) must be a tunnel mode SA, but an SA between two hosts may be either a transport mode SA or tunnel mode SA. The modes define the order and selection of appropriate headers. RFC 2401 provides several interesting examples of how SAs can be combined to satisfy complex, nesting security policies, and introduces into the model the notions of the security policy database (which specifies the policies that determine the disposition of IP traffic) and the security association database (which specifies the parameters of each active SA). Finally, RFC 2401 studies four cases of security associations, of which the fourth—depicted in Figure 3—is specifically relevant to the topic of dial-in access to an enterprise network. 

Figure 3: Remote host reaching an enterprise server.

Source: RFC 2401, Case 4.

In Figure 3, a remote host (dialing into an access concentrator) uses the Internet to reach an enterprise’s firewall (a security gateway) and then a particular host (a server). Only tunnel mode is required for an SA between the remote host and the firewall, while an SA between the remote host and the server can be either a transport or tunnel mode SA.

We have mentioned how IPsec standards relate to access and, particularly, VPNs, but so far we have not said anything about IPsec’s relation to IP telephony. The general feeling in the IP telephony community^[2] is that AH and ESP can be used in a standalone IP telephone, but the complexities of key exchange through IKE and the Internet Security Association and Key Management Protocol (ISAKMP) are too much to be handled by a client in a small standalone telephone.

Kaufman and Newman (1999) report that “early generations of IPsec products have proven to be suboptimal for many VoIP installations” and recommend deploying IPsec and voice over Internet Protocol (VoIP) separately and “experiment[ing] with integration only when you have debugged both installations.” In addition to technical reasons, the same monograph brings up an important regulatory consideration: In some circumstances, there are regulations that restrict voice encryption.