Home > Articles > Cisco Network Technology > Wireless/Optical/High Speed > Wireless LAN Fundamentals: Mobility

Wireless LAN Fundamentals: Mobility

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jan 9, 2004.

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 8Figure 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 9Figure 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 10Figure 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 11Figure 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 12Figure 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

Code Value

Source

Explanation

0

HA

Registration accepted

1

HA

Registration accepted, but simultaneous bindings not accepted

64

FA

Reason unspecified

65

FA

Administratively prohibited

66

FA

Insufficient resources

67

FA

MN failed authentication

68

FA

HA failed authentication

69

FA

Requested lifetime too long

70

FA

Poorly formed request

71

FA

Poorly formed reply

72

FA

Requested encapsulation unavailable

73

FA

Reserved and unavailable

77

FA

Invalid CoA

78

FA

Registration timeout

80

FA

Home network unreachable (ICMP error received)

81

FA

HA host unreachable (ICMP error received)

82

FA

HA port unreachable (ICMP error received)

88

FA

HA unreachable (other ICMP error received)

128

HA

Reason unspecified

129

HA

Administratively prohibited

130

HA

Insufficient resources

131

HA

MN failed authentication

132

HA

FA failed authentication

133

HA

Registration identification mismatch

134

HA

Poorly formed request

135

HA

Too many simultaneous mobility bindings

136

HA

Unknown HA address


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 13Figure 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 14Figure 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 15Figure 5-15 Reverse Tunneling

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020