[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                            R. Silva, Ed.
Internet-Draft                                          J. Sa Silva, Ed.
Intended status: Historic                          University of Coimbra
Expires: November 12, 2009                                  May 11, 2009


         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



Silva & Sa Silva        Expires November 12, 2009               [Page 1]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   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.





































Silva & Sa Silva        Expires November 12, 2009               [Page 2]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


Table of Contents

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















Silva & Sa Silva        Expires November 12, 2009               [Page 3]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


1.  Introduction

   MobilieIPv6 or only MIPv6 [RFC3775] 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



Silva & Sa Silva        Expires November 12, 2009               [Page 4]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   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].  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



Silva & Sa Silva        Expires November 12, 2009               [Page 5]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   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



Silva & Sa Silva        Expires November 12, 2009               [Page 6]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   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].

4.  Overview

5.  LowPAN adaptation Layer

   Mobile IPv6 headers suffers a similar restriction as the IPv6 headers
   in lowPANS.  RFC4944 [RFC4944] 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.







Silva & Sa Silva        Expires November 12, 2009               [Page 7]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


5.1.  MIPv6 Header Compression

   The Mobility Header defined in the RFC3775 [RFC3775] 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                          .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: Mobility Header.

   o  8 bits - Payload Proto = Identifies the Next Header.

   o  8 bits - Header Len = Identifies the length of the Mobility Header
      in unit of 8 octets.

   o  8 bits - MH Type = Identifies the particular mobility message.

   o  8 bits - Reserved

   o  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:

   o  Payload Proto is coded into 2 bits, as defined by 6lowPAN in
      RFC4944 [RFC4944].

   o  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.

   o  MH Type could be coded in 3 bits, but we choose 4 bits to give an
      higher range.




Silva & Sa Silva        Expires November 12, 2009               [Page 8]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   o  Reserved can be remove.

   o  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 |
             +---+---+---+---+---+---+---+---+

                   Figure 2: Mobility Header Compressed

   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] of MIPv6.

          +-------------------------------+--------------------+
          | Message#                      | Mobile Header Type |
          +-------------------------------+--------------------+
          | Binding Refresh Request (BRR) |          0         |
          | Home Test Init (HoTI)         |          1         |
          | Care-of Test Init (CoTI)      |          2         |
          | Home Test (HoT)               |          3         |
          | Care-of Test (CoT)            |          4         |
          | Binding Update (BU)           |          5         |
          | Binding Acknowledge (BA)      |          6         |
          | Binding Error                 |          7         |
          +-------------------------------+--------------------+




Silva & Sa Silva        Expires November 12, 2009               [Page 9]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


                        Table 1: Mobility Messages

   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:

   o  16 bits Reserved.

   o  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] is presented in the next figure.



















Silva & Sa Silva        Expires November 12, 2009              [Page 10]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


                          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                      .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: HoTI Message format

   [Granjal2008] [Granjal2008] 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                    |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


                     Figure 4: HoTI Message compressed



Silva & Sa Silva        Expires November 12, 2009              [Page 11]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


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                      .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5: HoT Message format

   o  16bits Home Nonce Index - is used to be echoed back by the MN in
      the Binding Update.

   o  64bits Home Init Cookie - contains the cookie sent in the Home
      Test init message.

   o  64bits Home Keygen Token - contains the keygen token generated ans
      used in the router routability.

   o  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:




Silva & Sa Silva        Expires November 12, 2009              [Page 12]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   o  Home Nonce Index reduced to 8 bits.

   o  Home init Cookie removed - Not necessary to be sent again.

   o  Home Keygen Token reduced to 16 bits.

   o  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                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                       Figure 6: HoTC Message format

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:












Silva & Sa Silva        Expires November 12, 2009              [Page 13]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


                          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                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 7: BU Message format

   o  16 bits - Sequence = used to sequence BU messages and to link to
      the correspondent Binding Acknowledge.

   o  1 bit - A = set 1 to require a Binding Acknowledge.

   o  1 bit - H = set 1 to indicate that the receiver must act as its
      Home Agent.

   o  1 bit - L = set 1 to indicate that both Link-local addresses, home
      and mobile, have the same Interface Identifier.

   o  1 bit - K = used to IPSec control and only valid for BU to the
      Home Agent.

   o  12 bits - Reserved.

   o  16 bits - Lifetime = The number of time units remaining before the
      binding expires. (time unit = 4 s)

   o  Variable-length (multiple of 8 octets) of Mobility Options.

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

   o  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.



Silva & Sa Silva        Expires November 12, 2009              [Page 14]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   o  A remains equal.

   o  H remains equal.

   o  L remains equal.

   o  K is removed since IPSec is not defined in lowPANs neither its
      support is guaranteed [Granjal2008].

   o  Reserved is removed.

   o  LifeTime is reduced to 8 bits only and time units increased to 8
      seconds (at this stage).

   o  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           |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                       Figure 8: BUC Message format

   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.






Silva & Sa Silva        Expires November 12, 2009              [Page 15]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


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] such
   message is composed by the following fields:

   o  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)

   o  1 bit - K = used to IPSec control and only valid for BU to the
      Home Agent.

   o  7 bits - Reserved = not used.

   o  16 bits - Sequence = copied from the Binding Update message and
      used to link both.

   o  16 bits - Lifetime = the granted lifetime from which the node (HA
      or CN) should retain the binding cache entry.

   o  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                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 9: BA Message format

   In order to compress this structure and based on the lowPANs



Silva & Sa Silva        Expires November 12, 2009              [Page 16]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   requirements, we firstly propose the redefinition of the available
   Status.  The RFC3775 [RFC3775] defines 14 Status resumed in the next
   table.

            +-----------------------------------------+-------+
            | Status                                  | Value |
            +-----------------------------------------+-------+
            | Binding Update Accepted (BRR)           |   0   |
            | Accepted but prefix discovery necessary |   1   |
            | Reason Unspecified                      |  128  |
            | Adminsitratively Prohibited             |  129  |
            | Insufficient Resources                  |  130  |
            | Home registration not supported         |  131  |
            | Not home subnet                         |  132  |
            | Not home agent for this mobile node     |  133  |
            | Duplicate Address Detection failed      |  134  |
            | Sequence Number out of window           |  135  |
            | Expired home nonce index                |  136  |
            | Expired care-of nonce index             |  137  |
            | Expired nonce                           |  138  |
            | Registration type change disallowed     |  139  |
            +-----------------------------------------+-------+

                    Table 2: Binding Acknowlede Status

   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.












Silva & Sa Silva        Expires November 12, 2009              [Page 17]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


            +-----------------------------------------+-------+
            | Status                                  | Value |
            +-----------------------------------------+-------+
            | Binding Update Accepted (BRR)           |   0   |
            | Accepted but prefix discovery necessary |   1   |
            | Expired home nonce index                |   2   |
            | Expired care-of nonce index             |   3   |
            | Expired nonce                           |   4   |
            | Reason Unspecified                      |   5   |
            | Not defined                             |   6   |
            | Not defined                             |   7   |
            +-----------------------------------------+-------+

               Table 3: Compressed Binding Acknowlede Status

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

   o  Status - 3 bits.

   o  K - removed for the same reason of the BU messages.

   o  Reserved - removed.

   o  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.

   o  LifeTime is reduced to 8 bits only and time units increased to 8
      seconds (at this stage).

   o  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.









Silva & Sa Silva        Expires November 12, 2009              [Page 18]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


                          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             |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                       Figure 10: BUC Message format

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                      .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: Binding Error Message format

   The original version defines the message as follow:



Silva & Sa Silva        Expires November 12, 2009              [Page 19]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   o  8 bits - Status:

      *  1 - Unknown Binding for Home Address destination option

      *  2 - Unrecognized MH Type value.

   o  8 bits - Reserved

   o  128 bits - Home Address

   o  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] defines 6
   mobility options presented next.

                   +----------------------------+------+
                   | Name                       | Type |
                   +----------------------------+------+
                   | Pad1                       |   0  |
                   | PadN                       |   1  |
                   | Binding Refresh Advice     |   2  |
                   | Alternate Care-of Address  |   3  |
                   | Nonce Indices              |   4  |
                   | Binding Authorization Data |   5  |
                   +----------------------------+------+

                         Table 4: Mobility Options

   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.







Silva & Sa Silva        Expires November 12, 2009              [Page 20]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -


                  Figure 12: PadN Mobility Option format

   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        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 13: Binding Refresh Advice Mobility Option format

   The field refresh interval is a 16bits integer, representing the



Silva & Sa Silva        Expires November 12, 2009              [Page 21]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   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.|
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 14: PadN Mobility Option compressed format

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                 |
     +                                                               +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 15: Alternate Care-of Address Mobility Option format

   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:






Silva & Sa Silva        Expires November 12, 2009              [Page 22]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


                                      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      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 16: Nonce Indices Mobility Option format

   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 |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 17: Nonce Indices Mobility Option compressed format

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] 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                        |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 18: Binding Authorization Data - Mobility Option format

   The Authenticator is calculated through a formula described in the
   RFC.  Its original length is 96 bits which is too long for lowPANs.



Silva & Sa Silva        Expires November 12, 2009              [Page 23]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


   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

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]      McCloghrie, K., Ed., Perkins, D., Ed., and J.
                  Schoenwaelder, Ed., "Structure of Management
                  Information Version 2 (SMIv2)", STD 58, RFC 2578,
                  April 1999.

   [RFC2579]      McCloghrie, K., Ed., Perkins, D., Ed., and J.
                  Schoenwaelder, Ed., "Textual Conventions for SMIv2",
                  STD 58, RFC 2579, April 1999.

   [RFC2580]      McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                  "Conformance Statements for SMIv2", STD 58, RFC 2580,
                  April 1999.

   [RFC3775]      Johnson, D., Perkins, C., and J. Arkko, "Mobility
                  Support in IPv6", RFC 3775, June 2004.

   [RFC4944]      Montenegro, G., Kushalnagar, N., Hui, J., and D.
                  Culler, "Transmission of IPv6 Packets over IEEE
                  802.15.4 Networks", RFC 4944, September 2007.

   [Granjal2008]  Granjal, J., Silva, R., Sa Silva, J., and E. Monteiro,
                  "Why is IPSec a viable option for wireless sensor
                  networks", Wireless and Sensor Networks Security ,
                  2008.



Silva & Sa Silva        Expires November 12, 2009              [Page 24]


Internet-Draft           Mobile IPv6 for lowPANs                May 2009


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

   Ricardo Nuno Mendao da Silva (editor)
   University of Coimbra
   Department of Informatics Engineering, Faculty of Sciences and Technology, Polo II 3030-290
   Coimbra
   Portugal

   Phone:
   EMail: rnsilva@dei.uc.pt


   Jorge Miguel Sa Silva (editor)
   University of Coimbra
   Department of Informatics Engineering, Faculty of Sciences and Technology, Polo II 3030-290
   Coimbra
   Portugal

   Phone:
   EMail: sasilva@dei.uc.pt















Silva & Sa Silva        Expires November 12, 2009              [Page 25]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/