07 June 2017

Mobile IPv6

IP is the prevalent standard for communications on the Internet. An IP address is used to route a packet from a source to a destination, possibly via intermediate routers. IP was designed at a time when computers remain at fixed location. An Internet address implicitly specifies a computer’s physical location.

The proliferation of mobile devices coupled with mobility proved that IP is incapable of supporting seamless mobility. An IP address can no longer be used to determine the location of a destination node, therefore, IP had to be extended to incorporate mobility support. Mobile IPv6 is a protocol that allows a mobile node to move from one network to another without losing its connection.

Most Internet traffic uses TCP connection, which is defined by the combination of IP address and port number at both endpoints. If any of these number changes, the communication is disrupted and has to be re-established. If a mobile node connects to a different access point to the network, it needs a new IP address.

Mobile IP allows a mobile node to move to a different connection point without changing its IP address by assigning the node two IP addresses, namely a home address (static and does not change) and a care-of address (changes depending on the network the mobile node is currently attached to). The handover is handled at the network layer.

Definition of Terms

  • A mobile node (MN) can change its point of attachment from one link to another while still being reachable via its home address.
  • A correspondent node (CN) is a peer node that is communicating with a mobile node. It could be mobile or stationary.
  • A mobile node is associated with a home network, which has a network prefix matching that of the mobile nodes’ home address.
  • A home address is a global unicast address assigned to a mobile node. It is used as the permanent address for this MN and is within the MN's home link. Regular routing mechanisms deliver packets to the home address.
  • A home subnet prefix is the IP subnet prefix corresponding to a MN's home address.
  • A home link is the link on which a mobile node's home subnet prefix is defined.
  • A foreign subnet prefix is any IP subnet prefix other than the MN's home subnet prefix.
  • A foreign link is any link other than the MN's home link.
  • A care-of address is a global unicast address for the MN while it is in a foreign network (away from home). The subnet prefix of the care-of address is the foreign subnet prefix. A MN may have multiple care-of addresses. The one registered with its home agent is the primary care-of address.
  • A home agent (HA) is a router on the MN 's home link with which the MN has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined for the MN 's home address, encapsulates them and tunnels them to the MN 's registered care-of address.
  • A binding associates a MN's home address with its care-of address along with the remaining lifetime of the association.
  • A registration is the process during which a MN sends a binding update to its HA or a CN, causing a binding for the mobile node to be registered. The registration with a MN is called correspondent registration.
  • A binding authorization — a registration with a CN needs to be authorized to allow the recipient to ensure that the sender has the right to specify a new binding.
  • A return routability procedure authorizes registrations by using a cryptographic token exchange.
  • A keygen token is a number supplied by a CN in the return routability procedure to enable the MN to compute the necessary binding management key for authorizing a binding update.
  • A nonce is a random number used internally by the CN to create keygen tokens in the return routability procedure. The nonce is not specific to a MN and is kept secret within the CN.
  • A nonce index is used to indicate which nonces have been used when creating keygen token values without revealing the nonces themselves.

How Mobile IPv6 Works

As long as a MN is at home, it receives packets through regular IP routing mechanisms and behaves like any other regular IP host. When the MN is away from home and on a foreign link, it is assigned a care-of address by the foreign network through regular IPv6 mechanisms, such as stateless auto-configuration of DHCPv6 when connecting to the new link.

The MN registers its care-of address with a router on its home link, i.e., the HA.

  • To register its care-of address, the MN sends a binding update message to its HA.
  • The HA responds with a binding acknowledgement.
  • A MN can also sends a registration to a CN directly.

There are 2 ways for MN and CN to communicate.

  • Bidirectional tunnelling: This mode doesn't require the CN to support Mobile IPv6 and works without correspondent registration. Packets from the CN are sent to the HA, which encapsulates them in IPv6 and sends them to the MN's care-of address. Packets from the MN are sent through the reverse tunnel to the HA, which forwards them to the CN using regular routing mechanisms.
  • Route optimization: MN and CN can communicate directly, without going through the HA. The MN registers its care-of address with the CN using correspondent registration and this binding is authorized through the return routability procedure. The CN uses a special routing header (type 2) when it sends packets to the MN directly. The MN uses the Home Address option when sending packets to the CN. Advantage: packets don't have to go through the HA — possible to use the shortest available path between MN and CN.

Mobile IPv6 supports multiple home agents. MNs learn about the reconfiguration of its home link or HA's IP address change through Dynamic Home Agent Address Discovery.

Mobile IPv6 Protocol

Mobility Header and Mobility Messages

The mobility header (MH) is an extension header used by MN, CN and HA. It is used in all messages related to establishing and maintaining bindings.

The value of the Payload Proto field is set to 59, which means "no next header". It is meant for use in future extensions. The MH Type field identifies the type of Mobility Message.

Mobility Message Type
Value Message Type Description
0 Binding Refresh Request Sent by CN requesting the MN to update its binding
1 Home Test Init Sent by the MN to initiate the Return Routability Procedure and request a Home Keygen token from a CN. Sent to the CN through the tunnel via HA.
2 Care-of Test Init Sent b the MN to initiate the Return Routability Procedure and request a keygen token from a CN. Sent to CN directly.
3 Home Test Message Response to the HOme Test Init Message. Sent from the CN to MN. Contains a cookie and a Home Keygen token for the authorization in the Return Routability Process. Sent through the tunnel via HA.
4 Care-of Test Message Response to the Care-of Test Init message. Sent to from CN to MN. Contains cookie and a Care-of Keygen token for the authorization in the Return Routability Procedure. Sent to the MN directly.
5 Binding Update Sent by MN to notify a change of its care-of address.
6 Binding Ack Sent as acknowledgement for receipt of a Binding Update message.
7 Binding Error Sent by CN to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding. The status can have to following values:
1 - unknown binding for Home Address Destination option
2 - unrecognized MH type value
8 Fast Binding Update Identical to binding update message, only with slightly different processing rules.
9 Fast Binding Ack Sent as acknowledgement for receipt of a Fast Binding Update message.
10 Fast Neighbour Advertisement Sent by MN to announce itself to its new access router.

Binding Update Message
The MN uses this message to inform its HA or CN about its new care-of address. It is also used to extend the lifetime of an existing binding.

The Sequence Number is used by the receiving node for sequencing Binding Updates. The sending node uses it to verify whether a Binding Acknowledgement received corresponds to its Binding Update. The A-bit is set by the MN if it expects an acknowledgment in respond to its Binding Update.

The MN sets the H-bit in order to request the receiver to act as its HA. It is only possible if the receiver is on the MN's home link.

The L-bit is set only if the home address has the same Interface Identifier as the MN's link-local address.

The K-bit is valid only in Binding Updates sent to the HA. The K-bit is set if the IPsec security association should survive when MN moves to another network, otherwise, it is set to 0. CNs ignore the K-bit.

The M-bit identifies Local Binding Updates sent to a local HA called Mobile Anchor Point (MAP), which is used to improve Mobile IPv6 handover performance, obtain efficient routing between MN and CN within the same geographical area, and to achieve location privacy.

The Lifetime field shows in four-second units how long the care-of address binding is valid. If the value is 0, the receiver must delete the entry in its Binding Cache. In this case, the MN is on its home link and the care-of address is the same as its home address.

Binding Acknowledgement
This must be sent if the A-bit in the Binding Update message is set to confirm receipt of a Binding Update.

If the A-bit is not set:

  • The Binding Acknowledgement is sent only if there is a problem in the Binding Update.
  • If the receiver accepts the binding Update, no acknowledgement is sent.

The Status field indicates the status of the Binding update. Values between 0 to 127 indicate the binding has been accepted; values above 128 indicate it is not accepted.

The K-bit is important only for binding between MN and HA (refer to Binding Update message).

The value of Sequence Number is copied from Sequence Number of the Binding Update message.

For the duration specified in the Lifetime field, the HA and CN keeps the entry for this binding in its Binding Cache. In a Binding Acknowledgement indicates that the binding is not accepted, the Lifetime value is not specified.

Mobile IPv6 Communications

Binding Cache

Every CN and HA maintains a Binding Cache for each of its global IPv6 address, which lists all mobile nodes for which it has a binding. If it wants to send data to a destination, it searches its Binding Cache and the Destination Cache for an address. A Binding Cache contains the following information:

  • Home address of the MN — this field determines the destination address when sending a packet,
  • Care-of address of the MN,
  • Lifetime value of the binding,
  • A flag indicating whether this entry is a home registration entry — present only on a node that acts as an HA,
  • Max value of the Sequence Number field of all previous Binding Updates received for this home address,
  • Information on the use of this entry.

Binding Update List
Each MN maintains a Binding Update List. It is an entry for each Binding Update that the MN has sent to its HA and CNs for which the lifetime hasn't expired. If it has sent more than one Binding Update, only the last message with the highest Sequence Number is listed.

The list contains the following information:

  • IPv6 address of the node to which the Binding Update was sent,
  • Home address for which the Binding Update has been sent,
  • Care-of address specified in the Binding update,
  • Lifetime value indicated in the update,
  • Remaining lifetime for the binding,
  • Highest use Sequence Number for the binding,
  • Time when the Binding Update was sent,
  • State of any retransmission required,
  • A flag indicating whether further Binding updates have to be sent to this destination.

Return Routability Procedure
This procedure allows a CN to detect whether the MN is reachable at its care-of address as well as its home address. Route optimization can only be used after this has been successfully proven.

If an MN can be reached at both addresses, that means it is on a foreign link and has a valid registration for the home address — this reduces the risk that the Binding Update is a security attack. Only after a successful Return Routability test does the CN accept Binding Updates from the MN and sends packets to the MN's care-of address directly.

The message flow for the Return Routability Procedure:

  • MN sends a Home Test Init message (MH type 1) via HA to the CN. This message contains a Home Init Cookie, which is used by the CN to learn the MN's home address.
  • MN sends a Care-of Test Init message (MH type 2) to the CN, which contains a Care-of Init Cookie. This is sent directly to the CN and is used by CN to learn the MN's care-of address.
  • CN replies to the Home Test Init message with a Home Test message (MH type 3) sent via HA, which contains the Home Init Cookie, Home Keygen Token and Home Nonce Index. The MN can now generate a Home Keygen Token.
  • CN replies to the Care-of Test Init message with a Care-of Test message (MH type 4) sent to the MN's care-of address. It contains the Care-of Init Cookie, Care-of Keygen Token and the Care-of Nonce Index. The MN can now generate a Care-of Keygen Token.

Once the MN receives the Home Test and Care-of Test messages, the Return Routability Procedure is completed.

The MN hashes the two tokens and creates a 20-byte Management Key, which is also known to the CN that generated the two tokens. The key is used by the MN to secure the Binding Update to the CN. Upon successful security check, the CN accepts the Binding Update since the MN has proven that it is reachable on both the home and care-of addresses contained in the Binding Update.

Home Agent Operation

When the MN is away from home, the HA intercepts all packets destined to the MN and tunnels them to the MN's care-of address using Proxy Neighbour Discovery.

Proxy Neighbour Discovery
In order to intercept packets for an MN, the HA pretends to be the MN. The HA sends Neighbour Advertisements to the All-nodes Multicast Address, providing its own link-layer address as link-layer address for the MN's home address.

The Neighbour Discovery (ND) message contains:

  • HA address as the source address,
  • The Target Address field in the ND message is the MN's IPv6 address,
  • A Target Link-layer Address option carrying the HA's link-layer address,
  • The Router flag is set to zero,
  • The Override flag is set and all nodes on the link updates their Neighbour Caches and store the link-layer address.

Now all packets on this link intended for the MN will be received by the HA, which acts as a proxy for the MN. It inspects all Neighbour Solicitations and verify whether the Target Address field corresponds to a Home Registration entry in its Binding Cache. If yes, it replies with a Neighbour Advertisement indicating its own link-layer address as the link-layer address for the MN.

Bidirectional Tunnelling
The HA uses an IPv6 tunnel to forward packets destined to the MN's home address. It inserts an additional IPv6 header, called the Tunnel header. The source address in the Tunnel header is the HA's IPv6 address; the destination address is the MN's primary care-of address. The MN processes the Tunnel header and forwards the decapsulated packet internally to the upper layer protocols and application.

In order to receive multicast packets when away from home, the MN must register for these group memberships:

  • The MN registers with local routers on the Home Link using its care-of address so that it can receive multicast packets directly. This membership does not survive if the MN moves to another foreign network.
  • The MN can register for multicast group memberships on its Home Link by sending Multicast Listener Discovery (MLD) registrations to its HA, which in turn, forwards multicast packets to the MN using the tunnel. This works no matter how many times the MN changes the network.

These packets are not forwarded to the MN:

  • Packets sent to the MN's link layer address. These packets are answered with an ICMPv6 Destination Unreachable message.
  • Multicast packets sent to a link-local, site-local or organisation-local scope.

Packets sent through the Reverse Tunnel from the MN to the HA are decapsulated by the HA and forwarded to their destinations through regular routing mechanisms. When the HA itself sends data to the MN, it behaves like a regular CN, which means it doesn't use the tunnel, but inserts a Routing Header type 2 that carries the MN's Home address.

Mobile Node Operation

When the MN is away from home, for each communication, it chooses whether to use its home address or care-of address. Applications and processes above the IP layer usually communicate using the MN's home address. If a communication is to survive when MN moves to another network, the home address must be used. For certain communications (e.g. Neighbour Discovery), the MN can use its care-of address without Mobile IPv6 functionality — just as a regular unicast address.

Route Optimization in Detail
Route optimization is used when a MN communicates with a CN for which there is a binding. The MN checks its Binding Update List for an entry of its home address for the CN — this verifies whether the CN can process the Home Address Destination Option. Then it checks the Binding Update List for the following:

  • Whether the Source Address it wants to use corresponds to the Home Address in the entry,
  • Whether the Destination Address it wants to use corresponds to the address of the CN in the entry,
  • Whether its current care-of address is listed as in this entry,
  • Whether the binding is valid and the lifetime is greater than zero.

If all requirements are met, the MN knows that the CN has a valid Binding Cache entry. A packet sent by the MN to the CN contains the following information:

  • The source address field in the IPv6 header contains the care-of address,
  • The packet carries a Destination Options header with a Home Address option containing the MN's home address.

When the CN receives the packet, it copies the home address from the Destinations Options header into the Source Address field of the IPv6 header before processing and sending the packet to the upper layer protocols and applications. To the upper layers and applications, it looks like the packet was sent from the MN's home address.

When the CN wants to send data to an MN, it checks its Binding Cache for an entry for the destination. If an entry exists, it inserts a Routing Header type 2.

When the CN replies:

  • The Destination Address in the IPv6 header contains the MN's care-of address,
  • The packet contains a Routing Header type 2. The address field in the Routing Header contains the MN's home address.

When the MN receives the reply, it exchanges the address in the Destination Address field with the home address copied from the Routing Header, reduces the Segments Left field in the Routing Header to from one to zero, and processes the packets internally to the upper layer protocols and applications. Again, to the upper layers and applications, it looks like the packet was sent to the MN's home address.

Communication with Bidirectional Tunnelling
If the MN wants to communicate with a CN for which it doesn't have a binding, it uses the Reverse Tunnelling mechanism. The packet is sent through the tunnel via the HA. The source address in the original packet contains the MN's home address and the CN's address is the destination address. The packet is encapsulated in another IPv6 header carrying the MN's care-of address in the Source Address field and the HA's IPv6 address in the destination field. The HA processes the first header and forwards the original packet to the CN.

Movement Detection
An MN detects that it has moved to another network using the Neighbour Unreachability Detection (NUD). Using NUD, the MN detects when its default router is no longer available, in which case the MN tries to find a new default router. It performs Duplicate Address Detection (DAD) for its link-local addresses, chooses a new default router based on the Router Advertisements (RAs), and builds new care-of addresses based on the Router prefixes advertised.

When the new addresses are initialized, it performs a Binding Update with its HA and then with all CNs for which it has bindings.

New routers advertising new prefixes is not necessarily a sign that the MN is in a new network — there may be a new router or a prefix change in the current network. Procedures are in place to prevent an MN from unnecessarily updating all bindings when it has not moved to another network.

  • If the MN receives RAs from new routers with new prefixes but its default router is still reachable, it will not perform any Binding Updates. It uses NUD to detect whether its default router is still available.
  • RAs can carry an Advertisement Interval Option, which allows the MN to detect whether this router is still available based on the comparison on the interval in different RAs.
  • If the default router does not reply to a Neighbour Solicitation, the MN should perform a Multicast Router Solicitation.

Returning Home
When the MN detects that it is back on its home link, it sends a Binding Update to the HA to inform the HA that it has returned and the HA no longer has to forward packets through the tunnel.

  • The Acknowledge bit and the Home Registration bits are set,
  • The Lifetime field is set to 0,
  • The care-of address must be the same as the home address,
  • The Source address in the IPv6 header must be the home address of the MN.

No comments:

Post a Comment

IEEE 802.15.4e Standard

Low reliability, unbounded packet delays and no protection against interference and fading are among the limitations of the IEEE 802.15.4 ...