An Adaptation Model for Mobile IPv6 support in lowPANs
draft-silva-6lowpan-mipv6-00

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 12, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

Real deployments of wireless sensor networks (WSN) are rare, and virtually all have considerable limitations when node mobility is concerned. On one hand, research in WSNs tends to favour complex multi-hop routing protocols and, on the other hand, IP and mobility are considered too demanding for these environments. In this document we contradict this general belief by proposing an adaptation model for Mobile IPv6 in 6lowPANs.

Table of Contents

1.  Introduction
2.  Mobile IPv6 main issues for lowPANs
    2.1.  Routing
    2.2.  Data
    2.3.  Handover
3.  Conventions
4.  Overview
5.  LowPAN adaptation Layer
    5.1.  MIPv6 Header Compression
    5.2.  Mobility Message Compression
        5.2.1.  Binding Refresh Request
        5.2.2.  Home Test Init
        5.2.3.  Care-of Test Init
        5.2.4.  Home Test
        5.2.5.  Care-of Test
        5.2.6.  Binding Update
        5.2.7.  Biding Acknowledge
        5.2.8.  Binding Error
    5.3.  Mobility Options
        5.3.1.  Pad1
        5.3.2.  PadN
        5.3.3.  Binding Refresh Advice
        5.3.4.  Alternate Care-of Address
        5.3.5.  Nonces Indices
        5.3.6.  Binding Authorization Data
6.  Definitions
7.  Security Considerations
8.  IANA Considerations
9.  Contributors
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Change Log
Appendix B.  Open Issues

1.  Introduction

MobilieIPv6 or only MIPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) is the native support of Mobile IP, firstly developed for IPv4, in IPv6. The main goal of Mobile IP is to allow mobile nodes to move between heterogeneous networks maintaining the connectivity. Such process aims also to be completely transparent at the transport and upper layers.

Based on L2 Handover, concept inherited from Cellular Networks, Mobile IP introduced L3 Handover and specific mechanisms to support it. Those mechanisms required new entities within each network, to control the overall process. A set of agents, tables and control messages were introduced and originated the first Mobile IP version.

The first version of Mobile IP introduced the concept of Home Agent, Foreign Agent, Correspondent Node, Mobile Node, Care of Address and Mobility Binding Tables. The Home Agent is the local entity responsible for the Mobile Nodes management. Maintaining a Binding Cache it registers the information of all local nodes that are currently connected to foreign networks. The Foreign Agent also maintains an updated table, containing the visitors' list. Each time a Mobile Node (MN) is connected to a foreign network, a care-of-address is associated to it.

Due to the potential of IPv6, the Mobile IP version for this new release was optimised and natively integrated. Firstly, since IPv6 supports stateless and stateful address configuration associated to Neighbour Discovery mechanisms, the existence of a Foreign Agent became unnecessary. Such role is now played by the Mobile Node, which triggers and controls the entire handoff process. One of the multiple Care-of Addresses is marked as primary, therefore, guaranteeing access from more than one network in the range. Considering that each Care-of Address has a lifetime associated to it, in some cases the Mobile Node is able to receive from multiple Addresses, since they are active. Such capability is known as Smooth-HandOff.

MIPv6 also brings the ability to natively deal with the routing questions providing new features as the Return Routability as well as the use of security mechanisms in all protocol communications (IPSec).

The mobility of nodes in lowPANs, is a behaviour that directly inherit from the characteristics of nodes. Nodes are small, battery powered and able to communicate wirelessly, which means that they are portable. Consequently, nodes are easily deployed on mobile bodies, like humans or vehicles, becoming in mobile nodes. Many applications consider the use of nodes on mobile bodies, like for instance in battlefields, rescues or cities monitoring systems, using buses or other vehicles. Therefore, the mobility support in lowPANs is crucial to the success of critical and non-critical mobility dependent applications.

Considering the actual state of MIPv6 and the necessitation of mobility support in lowPANs, this document presents an adaptation model to integrate MIPv6 in 6lowPAN. MIPv6 is defined by specific messages, each one with a specific format. Such format can be compressed and coded, following the same rules used to adapt IPv6 packet to IEEE802.5.4 frames, presented in RFC 4944 [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.). The objective is to guarantee a controlled latency in the presence of mobility. Hence, a micro MIPv6 version for lowPANs is demanding.

2.  Mobile IPv6 main issues for lowPANs

2.1.  Routing

When it is assigned a new primary Care-of Address, Mobile Nodes must notice that, sending a Binding Update message, to the Home Agent and in some cases to the Correspondent Node(s). As defined by the standard, the communication between the Correspondent Node and the Mobile Node can be done by tunnelling, through the Home Agent, or directly. Tunneling makes use of proxy Neighbour Discovery to intercept the IPv6 packets whose destination is the MN and encapsulate them with the CoA, IPv6-in-IPv6. Whereas this process is efficient, it can lead to the triangulation problem and high latency. Therefore, in order to avoid such problems, other approaches have appeared promoting the direct communication between MN and CN. To support it, the Correspondent Node must maintain a Mobility Binding Table and the MN must send the Binding Update messages not only to the Home Agent but also to the CN. Independently of the target, each Binding Update message must also be secured through IPSec ESP in transport mode.

To provide a more secure communication, avoiding triangulation, MIPv6 also introduces "Return Routeability". Return Routeability is performed during the handover and reaches both, HoA and CN, at the same instant. The objective is to secure that CN knows exactly to each MN it is talking to, and through each path the MN is available. Hence, when assigned a new primary CoA, MN sends a Binding Update to the Home Agent, a Home-Test Init (HoTI) to the CN via HA and a Care-of Test Init (CoTI) directly to the CN. When the CN receives both messages, HoTI and CoTI, it generates two keygen tokens based on a pre-generated key(random number of 20 octets) and a pre-generated nonce (random octet string with any length), namely: home keygentoken and care-of keygentoken, respectively. Then, via the same paths, CN sends back the generated keygen tokens in Home Test (HoT) and Care-of Test (CoT) messages, respectively. When MN receives both, HoT and CoT, it computes a binding message key (bmK) to sign the Binding Update message that it then sends directly to the CN. Finally, CN checks the signature, updates the Mobility Binding Table and sends back a Binding Acknowledgement. All this messages are new extensions in the IPv6 packet header. This process is too complex for use in lowPANs. The used messages and the security mechanism are too heavy and MUST be adapted.

2.2.  Data

Mobility Binding Tables, previously mentioned, are the most important data structures in the Mobile IP protocol. Every Home Agent maintains one, as well as some of the Correspondent Nodes (when bidirectional tunnelling is used CNs do not need to be aware about nodes mobility, therefore they do not need to maintain a Mobility Binding Table). Each entry of a Mobility Binding Table is composed by the Home Address, the principal Care-of Address, the remaining lifetime, a flag indicating whether or not this entry is a home registration, the maximum value of the sequence number received in the last message of correspondent to the respective entry and usage information about the same.

Home Agent also maintains a Home Agent List, where it is listed all Home Agents on the link. Each entry has a link-local IP address, one or more global IP addresses, the remaining lifetime and the preference level for that home agent (higher means better). Such list is useful when the Home Agent receives a Dynamic Home Agent Address Discovery message. In that case the Home Agent replies with a Home Agent Address Discovery Reply message containing the list of Home Agent on the link. This mechanism is useful when Mobile Nodes do not know the address of an available Home Agent on the link. When the reply message is received, Mobile Nodes try to send the Binding Update for the list entry with higher preference. If a Binding Acknowledgment is not received, the Mobile Node will try each one of the other entries.

Mobile Nodes maintain a Binding Cache too, known as Binding Update List, where each entry corresponds to the last Binding Update message sent per target (CN or HA). Each entry contains the IP address of the destination, the Care-of Address sent, the initial and remaining lifetime (when this value became zero the entry is removed), the maximum value of the sequence number, the time it was sent, the state of any retransmission needed and a flag specifying whether or not future BU message should be sent. Besides, in the cases that Return Routeability is in use the same entry must have: the time the last HoTI and CoTI were sent, the state of any retransmission needed for this return routability, the cookies used in HoTI and CoTI and also the Home and Care-of Keygen tokens, as well as the Home and Care-of nonce indices received.

Once again, lowPANs do not need to store so much information and data structures MUST be reduced.

2.3.  Handover

MobileIPv6 aims to perform the handoff as fast and as efficiently as the application requires. However, for real time applications, the handover latency can be insupportable. To overcome that some extensions were defined as alternatives to support Fast Handovers for MIPv6. The main idea is to start the L3 handover before the end of the L2 handover. To do that, MN should perform both almost at the same time. Another issue related with handover latency is the time required by the Duplicate Address Detection (DAD). After obtained the CoA, nodes should check if there are duplicate addresses in that subnet. However, it is done using Multiple Neighbour Solicitations and it would take at least 1 second. Return Routability, even secure and technically efficient, also requires the double of the time needed to perform a simple tunnelling. These questions have been approached and handover latency is a question that needs to be carefully analysed.

3.  Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

4.  Overview

5.  LowPAN adaptation Layer

Mobile IPv6 headers suffers a similar restriction as the IPv6 headers in lowPANS. RFC4944 [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.) defines that bits 5 and 6 identifies the next header. However, only UDP, TCP and ICMP were considering, being the remaining options carried in line. Hence, to identify the MIPv6 next header, 6lowPAN in the best case, will provide a HC1 with 3 bytes, being the Next Header field an uncompressed field.Independently of how HC1 signals the existence and type of the Next Header, in this point we present the first proposal for compression and encoding of the Mobility Header and respective messages.

5.1.  MIPv6 Header Compression

The Mobility Header defined in the RFC3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) is presented in figure 1

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto |   Header Len  |     MH Type   |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Checksum             |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
.                                                               .
.                         Message Data                          .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 8 bits - Payload Proto = Identifies the Next Header.
• 8 bits - Header Len = Identifies the length of the Mobility Header in unit of 8 octets.
• 8 bits - MH Type = Identifies the particular mobility message.
• 8 bits - Reserved
• 16 bits - Checksum = contains the checksum of the Mobility Header.

In order to make it compatible with WSNs, fields must be compressed. Hence, our proposal defines that:

• Payload Proto is coded into 2 bits, as defined by 6lowPAN in RFC4944 [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.).
• Header Len is coded in one bit:
  • 0: means that it was deleted and the entire length imported from layer 2.
  • 1: means that it is carried in line.
• MH Type could be coded in 3 bits, but we choose 4 bits to give an higher range.
• Reserved can be remove.
• Checksum is coded in one bit:
  • 0: included in the packet checksum.
  • 1: means carried in line.

With 2 bits of Payload Proto plus, 1 bit of Header Lenght, plus 4 bits of MH Type and plus 1 bit of Checksum, we are able to compress the 48 original bits to 8bits. Figure 2 presents the compressed Mobility Header, which we called 6lowPAN_MHC (Mobility Header Compressed).

                      1                   2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     MHC       |  Non-Compressed fields follow...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |
 |                  |
 |                     |
 |                        |
 |                           |
 | 0   1   2   3   4   5   6   7 |
 +---+---+---+---+---+---+---+---+
 |   PP  | L |    MH Type    | C |
 +---+---+---+---+---+---+---+---+

The field Mobility Header Type is used to identify the mobility message. The next table presents each message and the respective type value, as defined in RFC3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) of MIPv6.

Each message type has its own defined fields, which must also be compressed. The next sections will approach each message type and present our proposal to compress each one.

5.2.  Mobility Message Compression

5.2.1.  Binding Refresh Request

Binding Refresh Request (BRR) messages are used by Correspondent Nodes to request a refresh for a specific binding cache entry that stills active on deleting (eg. the entry lifetime expires but the binding stills active). BRR messages do not add any further field in the mobility header, however it defines the Message Data as follow:

• 16 bits Reserved.
• Variable-length (multiple of 8 octets) of Mobility Options.

Considering the limitations of lowPANs we propose delete the Reserved field.The Mobility Option field is approached later in this document. Hence, BRR messages are identified only by the Mobile Header Type and, eventually, followed by any Mobility Option.

5.2.2.  Home Test Init

Home Test Init (HoTI) is used to initiate the return routability procedure, requesting a Home Keygen Token from the Correspondent Node. To request that, Mobile Node must generate a Home Init Cookie, which is a random 64 bits values. To send it, the original message defined in the RFC3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) is presented in the next figure.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Home Init Cookie                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                         Mobility Options                      .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Granjal2008] [Granjal2008] (Granjal, J., Silva, R., Sa Silva, J., and E. Monteiro, “Why is IPSec a viable option for wireless sensor networks,” 2008.) presented a study about the viability of IPSec in WSNs. The same study concluded that the conventional algorithms are not supported in limited devices. Although supported by some Wireless Sensor Nodes, the memory constrains limits its general implementation. Therefore, it is not suitable to use 64 bits keys in WSNs. Hence, we propose the use of 16bits keys, as maximum. Besides, Mobility Options SHOULD not be considered at this level. If so, Mobility Options must be Type-Length-Value (TLV) but in a compressed mode, defined later in this document.

Home Test Init Compressed (HoTIC) has the follow format:

                      1                   2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           HoTIC               |  Non-Compressed fields follow...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |
 |                                    |
 |                                          |
 |                                               |
 |                                                    |
 |                                                         |
 | 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5 |
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 |                    Home Init Cookie 16bits	                 |
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

5.2.3.  Care-of Test Init

Care-of Test Init (CoTI) has the same objective of HoTI, however is sent via a different path. The original format is equal to HoTI format as well as the compressed proposal.

5.2.4.  Home Test

Home Test (HoT) message is the response of Correspondent Nodes to the Home Test Init message. The format of this message is the follow.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |        Home Nonce Index       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Home Init Cookie                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                        Home Keygen Token                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                         Mobility Options                      .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 16bits Home Nonce Index - is used to be echoed back by the MN in the Binding Update.
• 64bits Home Init Cookie - contains the cookie sent in the Home Test init message.
• 64bits Home Keygen Token - contains the keygen token generated ans used in the router routability.
• Variable-length - Mobility Options.

Based on the same constrain mentioned in the Home Test Init case, we propose the reduction of 64 bits keys to 16 bits. Our proposal for Home Test compressed (HoTC) is the follow:

• Home Nonce Index reduced to 8 bits.
• Home init Cookie removed - Not necessary to be sent again.
• Home Keygen Token reduced to 16 bits.
• Mobility Options - suppressed.

Compressed from 144 bits (w/o options) to 24 bits the HoTC format is presented in the next figure.

                      1                   2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     HoTC                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                 |
 |                                                      |
 |                                                          |
 |                                                              |
 |                                                                  |
 | 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1  2  3|
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |   Home Nonce Ind.     |         Home Keygen Token                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

5.2.5.  Care-of Test

Care-of Test (CoT) has the same format of HoT, changing only the field's names to Care-of Nonce and Care-of Keygen Token. The same compression proposed for HoT is proposed for CoT. The compressed version of CoT is called CoTC.

5.2.6.  Binding Update

Binding Update messages are used to notify other nodes about new care-of addresses. Defined in RFC 3775 its format is the follow:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |          Sequence #           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|         Reserved      |           Lifetime            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Mobility Options                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 16 bits - Sequence = used to sequence BU messages and to link to the correspondent Binding Acknowledge.
• 1 bit - A = set 1 to require a Binding Acknowledge.
• 1 bit - H = set 1 to indicate that the receiver must act as its Home Agent.
• 1 bit - L = set 1 to indicate that both Link-local addresses, home and mobile, have the same Interface Identifier.
• 1 bit - K = used to IPSec control and only valid for BU to the Home Agent.
• 12 bits - Reserved.
• 16 bits - Lifetime = The number of time units remaining before the binding expires. (time unit = 4 s)
• Variable-length (multiple of 8 octets) of Mobility Options.

In order to compress Binding Update messages, taking in consideration the limitations, we propose:

• Sequence number reduced to 5 bits, allowing:
• directly a sequence of 32 messages.
• the codification of each combination.
• the application of mathematic formula to achieve higher sequences on demand.
• A remains equal.
• H remains equal.
• L remains equal.
• K is removed since IPSec is not defined in lowPANs neither its support is guaranteed [Granjal2008] (Granjal, J., Silva, R., Sa Silva, J., and E. Monteiro, “Why is IPSec a viable option for wireless sensor networks,” 2008.).
• Reserved is removed.
• LifeTime is reduced to 8 bits only and time units increased to 8 seconds (at this stage).
• Mobility Options are approached separately and presented later in this document.

Hence, based on these approach our proposal for Binding Update messages (without considering Mobility Options), entitled BUC, compresses the message from 48 bits to 16 bits. Figure 8 shows the result.

                     1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              BUC              |  Non-Compressed fields follow...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
|                                    |
|                                        |
|                                             |
|                                                   |
|                                                        |
|                                                             |
| 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|        Sequence       | A | H | L |        LifeTime           |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

The field LifeTime could be differently coded, more compressed or calculated on demand, however we believed that a tradeoff between the cost of sending a few bytes and the cost of compute it on demand must be found. Future evaluation will prove this question.

5.2.7.  Biding Acknowledge

Binding Acknowledge message are used to notify the reception of a Binding Update message. As defined in the RFC3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) such message is composed by the following fields:

• 8 bits - Status:
• Values less than 128 means that BU was accepted. (0 and 1 assigned)
• Values greater than or equal to 128 means than an error occurred. (assigned from 128 to 139)
• 1 bit - K = used to IPSec control and only valid for BU to the Home Agent.
• 7 bits - Reserved = not used.
• 16 bits - Sequence = copied from the Binding Update message and used to link both.
• 16 bits - Lifetime = the granted lifetime from which the node (HA or CN) should retain the binding cache entry.
• Variable-length - Mobility Options = in BA messages future options can be defined. The RFC mentions the 'Binding Authorization Data Option' and the 'Binding Refresh Advice Option.'

The next figure presents the Binding Acknowledge fields.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |      Status   |K|  Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Sequence#         |          Lifetime             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Mobility Options                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In order to compress this structure and based on the lowPANs requirements, we firstly propose the redefinition of the available Status. The RFC3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) defines 14 Status resumed in the next table.

LowPAN requirements and capabilities are different from conventional networks. Consequently, some of this status are not presented in such networks. For instance, the message 133 could be sent by several nodes reached by the same anycast address. In that case, it is not useful when the network and particularly the Mobile Node would be flooded with several messages. To avoid this type of problems, we propose that Mobile Nodes, when request a Binding Acknowledge, define a time limit to receive it. Thus, if any error occurs, the Mobile Node will not receive any acknowledge. When the time is expired, the MN will know that an error happened without the need to receive any message. At this stage we propose to keep only status 0 and 1 for success, and status 136, 137 and 138 for questions related to return routeability. Hence, we propose to resume this field to 3 bits, allowing a maximum of 8 status, presented in the next table.

Therefore, our version of Binding Acknowledge message for lowPANs, proposes:

• Status - 3 bits.
• K - removed for the same reason of the BU messages.
• Reserved - removed.
• Sequence number reduced to 5 bits, allowing:
• directly a sequence of 32 messages.
• the codification of each combination.
• the application of mathematic formula to achieve higher sequences on demand.
• LifeTime is reduced to 8 bits only and time units increased to 8 seconds (at this stage).
• Mobility Options are not defined here.

With this proposal the Compressed version of Binding Acknowledge (BAC) messages is constituted by 16 bits instead of the 48 bits (without considering the mobility options) of the conventional solution. The next figure resumes de BAC message.

                      1                   2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    BAC        |  Non-Compressed fields follow...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |
 |                                    |
 |                                         |
 |                                               |
 |                                                     |
 |                                                          |
 | 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5 |
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 |   Status  |     Sequence      |          LifeTime             |
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

5.2.8.  Binding Error

The Binding Error Message is used by the Correspondent Node, for instance to report any error related with the Home Address destination, in the case that no binding entry is registered. The format of this message is presented in the next figure.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |       Status  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                          Home Address                         |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                         Mobility Options                      .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The original version defines the message as follow:

• 8 bits - Status:
• 1 - Unknown Binding for Home Address destination option
• 2 - Unrecognized MH Type value.
• 8 bits - Reserved
• 128 bits - Home Address
• Variable length - Mobility Options

For this type of message we won't propose any change. The reserved field could be removed as well as the Status field reduced. However, the Home Address MUST be sent anyway and probably PadN options would be necessary.

This message format MUST be discussed in future.

5.3.  Mobility Options

Mobility Options allow a flexible extension of packets. Mobility messages can have zero, one or more options. Each Option must follow the Type-Length-Value (TLV) format. The RFC3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) defines 6 mobility options presented next.

Firstly we propose to suppress the Option length field (from the TLV format), since we can obtain the entire message length from layer 2 and consequently check if there are mobility options or not.The next subsections approach each defined type deeply, proposing possible compressions.

5.3.1.  Pad1

Since we are dealing with bits and not bytes we propose a dynamic Pad1. Instead of having one fixed byte of length, Pad1 can have from 1 to 8 bits of length. Thus, its propose remains almost the same, which means that it is responsible for maintaining the message length in octets. Since we compressed most of the messages, it is not guaranteed that all of them are mutliple of 8. Therefore, Pad1 must be used to guarantee it. If more than one octect is needed we propose to use Pad1 to regulate the first byte and PadN to set the remain message.

5.3.2.  PadN

For more than 1 octet we SHOULD use PadN. PadN follows the TLV format, being the "option data" ignored. The original option format is the follow:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -
|    Type=1     |     Length    |   Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -

We do not propose any change for PadN since its obective is to insert octets of padding in the Mobility Option area of a mobility message.

5.3.3.  Binding Refresh Advice

Binding Refresh Advice option can only be sent with a Binding Acknowledgment from the Home Agent to the Mobile Node, in a response of a home registration. It indicates the remaining lifetime of that registration. The original format is the follow:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |    Type=2     |     Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Refresh Interval        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The field refresh interval is a 16bits integer, representing the remaining lifetime in units of 4 seconds each. Accomplishing with our previous proposals, this field should be compressed to 8bits of 8 seconds each unit.

Therefore, considering the suppression of the length field, the compressed format of this message is the follow:

                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=2      |Refresh interv.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.4.  Alternate Care-of Address

This option is used to indicate in a Binding Update message an alternate Care-of Address for that used as source address. The format of this option is the follow:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |     Type =3   |     Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Alternate Care-of Address                 |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We do not propose any compression for this type of option.

5.3.5.  Nonces Indices

Home Nonce and Care-of Nonce indexes as mentioned when compressed HoT and CoT are used to be echoed back in the Binding Update message. Therefore, both are echoed back as a mobility option, whose original format is the follow:

			         1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |   Type=4      |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Home Nonce Index      |      Care-of Nonce Index      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As proposed in HoTC and CoTC, both indexes should be compressed to 8 bits. Considering the suppression of the option length field, the compressed format of this option is presented in the next figure.

			         1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=4      |   Home Nonce  | Care-of Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.6.  Binding Authorization Data

The Binding Authorization Data is the signature used by Mobile Nodes to sign the Binding Updates in order to make sure that they are the right senders. The content of this cryptographic signature is calculated in the context of return routability, and makes use of the nonces created by the Correspondent Node and sent in the HoT and CoT. The format of this message, as defined in the RFC3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) is the follow:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |   Type = 5    | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                          Authenticator                        |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Authenticator is calculated through a formula described in the RFC. Its original length is 96 bits which is too long for lowPANs. In a future step we aim to propose a simpler formula and reduce the authenticator length.

6.  Definitions

7.  Security Considerations

Security is implicity in MIPv6. IPSec mechanisms MUST be provided to guarantee the reliability of the adaptation model and consequently the network security.

8.  IANA Considerations

This memo includes no request to IANA.

9.  Contributors

10.  References

10.1. Normative References

10.2. Informative References

Appendix A.  Change Log

This optional section should be removed before the internet draft is submitted to the IESG for publication as an RFC.

Note to RFC Editor: please remove this appendix before publication as an RFC.

Appendix B.  Open Issues

The main content of this document aims to be discussed. The compression and codification of fields must be well evaluated. The authors are open to all contributions.

Authors' Addresses