Wireless LAN Fundamentals: Mobility

Layer 3 Roaming

Layer 3 mobility is a superset of Layer 2 mobility. An 802.11 client must perform a Layer 2 roam, including AP discovery, before it can begin a Layer 3 roam. This section focuses on issues surrounding Layer 3 roaming, specifically with the IP Protocol and Mobile IP extensions (RFC 2002). It covers the following topics:

• Roaming between roaming domains

• A Mobile IP overview

Roaming Between Roaming Domains

As previously discussed, a roaming domain is defined as APs that are in the same broadcast domain and configured with the same SSID. Stated another way, a client can only roam between APs in the same VLAN and with the same SSID. As WLAN deployments expand within an organization, roaming domains might need to scale beyond a single Layer 2 VLAN.

Consider the following scenario: Company A has a four-story building in which it has deployed a WLAN. The initial deployment was small, and the WLAN was a single Class C subnet for the entire building. This setup created a roaming domain across all four floors of the building. As time progressed, the number of users increased to the point that the subnet is full, and performance is degrading because of increased broadcast traffic.

Company A decides to follow its desktop subnet model and use a single subnet per floor for the WLAN. This setup introduces complications because now the roaming domains are restricted to a floor, not the entire building as before. With the new subnet model in place, application persistence when roaming across floors is lost. The application most impacted is Company A's wireless VoIP devices. As users move between the floors (and subnets) on their wireless phones, they drop their calls when they roam. Figure 5-8 illustrates this scenario. In this figure, an 802.11 VoIP phone is connected to a wired VoIP phone. As the user roams from AP1 on Subnet 10 to AP2 on Subnet 20, the session drops because the roaming user is now on a different subnet.

Figure 5-8 Roaming Between Subnets

Mobile IP Overview

The scenario described for Company A is common. Many applications require persistent connections and drop their sessions as a result of inter-VLAN roaming. To provide session persistence, you need a mechanism to allow a station to maintain the same Layer 3 address while roaming throughout a multi-VLAN network. Mobile IP provides such a mechanism, and it is the standards-based, vendor-interoperable solution to Layer 3 roaming for WLANs.

A Mobile IP–enabled network has these key components:

• Mobile node (MN)—The MN is the roaming station.

• Home agent (HA)—The HA exists on routers or Layer 3 switches and ensures that a roaming MN receives its IP packets.

• Foreign agent (FA)—The FA exists on router or Layer 3 switches and aids the MN notifying the HA of the new MN location by receiving packets from the HA destined for the MN.

• Care-of address (CoA)—The CoA is a locally attached router that receives packets sent by the HA, destined for the MN.

• Co-located care-of address (CCoA)—A CoA that exists on the mobile node itself.

Roaming in a Mobile IP–aware network involves the following steps:

1. A station is on its home subnet if the station's IP address belongs to the subnet of the HA.

2. As the MN roams to a foreign subnet, the MN detects the presence of the FA and registers with the FA or with the MN CCoA.

3. The FA or MN CCoA communicates with the HA and establishes a tunnel between the HA and a CoA for the MN.

4. Packets destined to the MN are sent to the HA (via normal IP routing), as shown in Figure 5-9.

5. The HA forwards the packets via the tunnel to the MN.

6. Any packets the MN transmits are sent via the FA as if the MN were local on the subnet, as shown in Figure 5-10. (A "reverse tunnel" mode is available when the edge routers use ingress packet filtering.)

This summary provides a brief overview of the three main phases of Mobile IP:

• Agent discovery

• Registration

• Tunneling

The following sections highlight each phase.

Figure 5-9 Packet Transmission to a Roaming MN

Agent Discovery

A roaming MN must determine that it is on a foreign subnet in a timely manner to minimize delay to running applications. HAs and FAs advertise their services by using the Internet Control Message Protocol (ICMP) Router Discovery Protocol (collectively known as IRDP) messages to send agent advertisements. As the MN establishes connectivity to the subnet it roams to, it listens for the periodic IRDP packets. The packets are sent to either the all-host multicast address (224.0.0.1) or the limited broadcast address (255.255.255.255). The IRDP packets are not sent to the subnet-specific broadcast address because the MN might not be aware of the subnet it has roamed to. In addition to periodic agent advertisements, an MN can solicit for advertisements after it detects that its interface has changed.

Figure 5-10 Packet Transmission from a Roaming MN

The agent advertisement contains two fields that allow the MN to determine whether it has roamed to a new subnet:

• The lifetime field from the agent advertisement

• The prefix-length extension

The lifetime field provides a time value that an agent advertisement is valid for. If no new advertisement has been received before the lifetime reaches zero, the MN should attempt to discover a new agent.

The prefix-length extension indicates the network address value of the advertising agent. A change in prefix length (indicating a change in network address or subnet) shows the MN it should attempt to discover a new agent.

Upon determining it is on a foreign subnet, the MN gleans the CoA from the agent advertise-ment. The CoA can take two forms:

• The address of the FA.

• CCoA (Note that the CCoA is not advertised by the FA, but it is probably acquired by the MN as a Dynamic Host Configuration Protocol [DHCP] option.)

A CoA pointing to the FA forces the FA (usually the subnet router) to handle Mobile IP administration for all foreign MNs on the subnet in addition to handling packet-forwarding duties. The benefit to this situation is that only a single tunnel is required from the HA to each unique FA.

A CoA that is temporarily assigned to the MN places the Mobile IP administrative burden on the MN and forces the HA to establish a unique tunnel to each roaming MN. Figure 5-11 contrasts these two methods.

Figure 5-11 Contrast Between MN and CoA

MN Registration

After the MN establishes a CoA and local mobility agent (either HA or FA), the registration process begins. The registration process securely creates a mobility binding on the FA and HA to facilitate the forwarding of packets to the MN. The registration process is as follows and is illustrated in Figure 5-11:

1. The MN sends a registration request to the FA. If the MN has a CCoA, this step is skipped.

2. The FA processes the registration request and forwards the request to the HA.

3. The HA accepts or declines the registration and sends a registration reply to the FA.

4. The FA processes the registration reply and relays it to the MN.

Figure 5-12 The Mobile IP Registration Process

The registration request contains the following fields:

• Simultaneous bindings—The MN can request that the HA retain bindings to prior CoAs.

• Broadcast packets—The MN can request that the HA forward any broadcast packets which it receives on the home subnet.

• Decapsulation by MN—The MN may request to decapsulate tunneled packets itself. This option is only selected when the MN has a CCoA.

• Minimal encapsulation—The MN can request that the HA use minimal encapsulation to tunnel packets (RFC 2004).

• Generic Routing Encapsulation (GRE)—The MN can request that the HA use GRE encapsulation to tunnel packets.

• Reverse tunneling—The MN can request that its egress packets be tunneled back to the HA to forward to the destination.

• Lifetime—This field indicates the remaining time before the registration expires.

• Home address—This field indicates the IP address of the MN.

• HA—This field is the IP address of the MN's HA.

• CoA—This field is the IP address of the CoA and the termination point of the tunnel.

• Identification—This field is a 64-bit nonce used for sequencing registration requests and replies and preventing replay attacks on the registration packets.

• Extensions—A number of extensions are available yet not required for registration.

The registration reply contains the following fields:

• Code—This field is the result of the registration request. Table 5-1 contains the result values for this field.

• Lifetime—This field is the number of seconds remaining before the registration expires.

• Home address—This field is the IP address of the MN.

• HA—This field is the IP address of the HA.

• Identification—The contents of the field vary depending on the message-authentication mechanism used to process the registration request.

• Extensions—A number of extensions are available but not required for registration.

Table 5-1 Registration Code Field Values

The Mobile IP standard requires that some keyed message-authentication mechanism protect the registration messages between the MN and the HA (messages between the FA and HA can be authenticated but usually are not) and optionally allows messages between the MN and FA to also be protected. By default, the Hashed Message Authentication Codes with Message Digest version 5 (HMAC-MD5) is enabled. The HA must share a secret value with the MN, either statically configured or centrally stored on an authentication, authorization, and accounting (AAA) server. Figure 5-13 illustrates how the message authentication process is calculated.

Figure 5-13 Securing Registration Messages

Other security issues might impact how you deploy Mobile IP in your network. If source address filtering checks (RFC 2827) are enabled on FA routers, the forwarding of packets from the MN via the FA cannot occur. The FA ingress interface can filter for only valid source IP addresses to prevent unauthorized devices from penetrating the network. This filtering poses an issue for MNs because they transmit packets with their home-network IP address, and as a result, all transmitted frames are dropped at the FA router.

To circumvent this issue, you must enable reverse tunneling. Reverse tunneling adds slightly to the administrative overhead for the CoA and HA but allows Mobile IP operation in a secured network.

Tunneling

Tunneling is synonymous with encapsulation. Tunneling allows two disparate networks to connect directly to one another when they normally would not or when they are physically disjointed. This capability is key for Mobile IP because tunneling is what allows the HA to bypass normal routing rules and forward packets to the MN.

A tunnel requires two endpoints: an entry point and an exit point. The entry point encapsulates the tunneled packets within another IP header. The new IP header might include some other parameters, but the basic function of the encapsulation header is to direct the packet to the tunnel endpoint. A packet received by the tunnel endpoint is stripped of the encapsulation header and forwarded to the MN. Figure 5-14 illustrates the packet-tunneling process.

Figure 5-14 IP Packet Encapsulation

Mobile IP supports a few tunneling mechanisms:

• IP in IP encapsulation

• Minimal encapsulation

• GRE

IP in IP encapsulation is the only mandatory tunneling type in the Mobile IP specification, but the use of GRE and minimal encapsulation is common because each has slightly different impacts on the network that you can use to determine which best suits your requirements.

Some networks implement RFC 2827 filtering on their distribution router interfaces that only allow packets from a valid source network through. For example, a router interface has network 10.0.0.0/24 (IPs 10.0.0.1 through 10.0.0.254). An MN with a home address on 192.168.10.1 would not be able to send packets across the router because 192.168.10.1 is not in the 10.0.0.0/24 subnet. For the MN to send packets in this case, the FA must forward the packets back to the home subnet via the HA. Figure 5-15 illustrates this scenario. Reverse tunneling does incur additional packet overhead and application latency, but it facilitates the use of RFC 2827 filtering to maintain network security.

Figure 5-15 Reverse Tunneling