[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-paakkonen-nemo-prefix-delegation) 00 01 02

Network Mobility                                              P. Thubert
Internet-Draft                                                     Cisco
Expires: February 22, 2008                                  TJ. Kniveton
                                                                   Nokia
                                                         August 21, 2007


                    Mobile Network Prefix Delegation
                draft-ietf-nemo-prefix-delegation-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 February 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This paper extends the Nemo Basic Support [7] for a Mobile Router to
   synchronize its Mobile Network Prefixes with its Home Agents and
   obtain new ones dynamically.  The proposed prefix delegation
   mechanism is agnostic to the way the back end is implemented; it
   enables bootstrapping, resynchronization at binding creation or after
   a loss of states (eg MR reboot), MNP Renumbering, and configuration
   checking for loop avoidance.



Thubert & Kniveton      Expires February 22, 2008               [Page 1]


Internet-Draft                   NEMO-PD                     August 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivation for a NEMO prefix delegation  . . . . . . . . . . .  3
     2.1.  Configuration management . . . . . . . . . . . . . . . . .  4
     2.2.  Provisioning . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Renumbering  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  The NEMO bootstrap problem . . . . . . . . . . . . . . . .  5
     2.5.  Local Mobility Management  . . . . . . . . . . . . . . . .  5
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Which capabilities?  . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  Prefix Request capability  . . . . . . . . . . . . . .  6
       4.1.2.  Full prefix list capability for HA . . . . . . . . . .  6
       4.1.3.  Full prefix list capability for MR . . . . . . . . . .  7
     4.2.  Rationale for new Binding options  . . . . . . . . . . . .  7
     4.3.  Rationale for a new bit in the BU  . . . . . . . . . . . .  7
     4.4.  Why not Alternate standard based solutions?  . . . . . . .  7
   5.  Terminology and concepts . . . . . . . . . . . . . . . . . . .  9
   6.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  New mobility Headers . . . . . . . . . . . . . . . . . . . 10
     6.2.  New Prefix Status bit  . . . . . . . . . . . . . . . . . . 10
     6.3.  Prefix lease duration  . . . . . . . . . . . . . . . . . . 10
     6.4.  Renumbering  . . . . . . . . . . . . . . . . . . . . . . . 11
     6.5.  backward compatibility . . . . . . . . . . . . . . . . . . 11
     6.6.  PD flow  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Binding Update . . . . . . . . . . . . . . . . . . . . . . 12
     7.2.  Binding Acknowledgement  . . . . . . . . . . . . . . . . . 13
     7.3.  Mobile Network Prefix option . . . . . . . . . . . . . . . 14
     7.4.  Mobile Network Prefix request option . . . . . . . . . . . 15
     7.5.  Mobile Network Prefix Confirm option . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     11.1. Normative Reference  . . . . . . . . . . . . . . . . . . . 20
     11.2. Informative Reference  . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22











Thubert & Kniveton      Expires February 22, 2008               [Page 2]


Internet-Draft                   NEMO-PD                     August 2007


1.  Introduction

   The reader of that document is expected to be familiar with both the
   Mobile IPv6 [6] and NEMO Basic Support [7] documents.  As such, it is
   well-understood that neither protocol provides the means for
   provisioning the Mobile Nodes and Routers with essential parameters
   such as Home Address and Home Network.

   The process by which a router obtains a prefix dynamically is called
   prefix delegation.  In the NEMO context, the prefix is managed by an
   authority that owns the Home Network and subnets it into MNPs that it
   assigns to the MRs.  An MNP can be preassigned to the associated MR
   (e.g. manually or automatically with a provisionning system), or
   assigned dynamically by a server such as a DHCP Prefix Delegation
   server.

   As prescribed by [7], the HA checks whether a MR is authorized for
   the MNPs it claims as part of the NEMO Binding Update with the
   explicit prefix option.  Also, MNPs have to belong to an aggregation
   that is permanently advertised by the HA to the routing
   infrastruture.  Consequently, there is a strong relationship between
   the HA that the MR registers to and the prefixes it claims with the
   registration, and it makes sense for the HA to participate actively
   to the delegation process as well.

   [7] standardizes an interface between a Mobile Router and its Home
   Agent, as well as an interface between Home Agents.  The protocol is
   agnostic as to how the back end is implemented in terms of AAA,
   provisioning, or routing between the HAs and their IGP, and enables
   various forms of deployment, as described in [12].

   In a same fashion, this document extends [7] for a Mobile Router to
   obtain its Mobile Network Prefix dynamically from its Home Agent,
   with no assumption about the specific back-end implementation for
   prefix management and service authorization.


2.  Motivation for a NEMO prefix delegation

   A number of reasons plead for adding this capability to the NEMO
   Basic Support [7].

   Mainly, there is an unanswered question as to how a MR could be
   dynamically assigned its prefix.  In a situation where a site has
   many MRs, it may be impractical to assign the prefixes statically in
   the non-volatile memory of the MR.  Consequently, a mechanism for the
   HA to assign the prefix, similar to how a MN can bootstrap its Home
   Address, would be desirable.



Thubert & Kniveton      Expires February 22, 2008               [Page 3]


Internet-Draft                   NEMO-PD                     August 2007


2.1.  Configuration management

   The Implicit Mode of the NEMO Basic Support 'externalizes' the
   configuration of the MNPs in a MR and its HA.  In the example of a
   static configuration, both side are initially provisioned with the
   association between the MRs and their MNPs, and maintain matching
   states between them.

   The failure to configure and maintain these matching states overtime
   ends up in routing loops and unreachable prefixes.  Tools for
   synchronizing MNPs in runtime would be a valuable addition to [7].

2.2.  Provisioning

   In practice, provisioning both sides manually is error-prone and
   should be avoided.  It can not be taken for granted, either, that in
   all cases, a provisioning system can be deployed with the capability
   to configure both the Mobile Router and the back-end in a
   transactional manner.  Consequently, it appears necessary to provide
   a way to configure one side only, and have the other side learn from
   it in a trusted fashion and with no additional manual intervention.

   The Explicit Prefix mode enables a flow where the configuration of
   that association is not centralized at the HA but distributed to all
   the MRs.  In the other hand, the HA is required to validate that the
   MR has been authorized for the MNPs it claims and then again, some
   level of information duplication might occur.

   In the general case, it may be easier to manage the prefix
   attribution in a centralized manner and have the MRs learn their
   prefixes dynamically.

2.3.  Renumbering

   The concept of lifetime is one core idea with IPv6.  Nothing is
   eternal.  Overtime, it might be desirable to modify the configuration
   of the MNPs.  This task, called renumbering, is especially difficult
   for Mobile Routers when they are geographically distributed and can
   not be readily made available to the administrators.

   It is thus desirable to extend the NEMO Basic Support [7] with a
   renumbering mechanism.  In particular, it makes sense to provide that
   extension within the prefix delegation mechanism, since the
   operations that take place are similar.







Thubert & Kniveton      Expires February 22, 2008               [Page 4]


Internet-Draft                   NEMO-PD                     August 2007


2.4.  The NEMO bootstrap problem

   The NEMO Basic Support [7] expects a Mobile Router to be provisioned
   with some information in order to start up - Home Network or Home
   Agent address, Home Address, Mobile Network Prefixes, security
   tokens, etc...

   In some situations, it may be impractical to actually provision all
   this information into the router at deployment time, and some of it
   has to be obtained dynamically when a system boots up, possibly
   through manually keying by the final user.

   It is absolutely required to reduce such manual keying of information
   to the bare minimum, for instance a Network Access Identifier [8]
   transported in the Mobile Node Identifier Option for Mobile IPv6 [9].
   And while NEMO can benefit from the MIP6 effort on the bootstrap
   problem (as described in the MIP6 bootstrap problem statement
   document [11]) for most parameters, the dynamic provisionning of
   Mobile Network Prefix(es) is not considered by MIPv6.

2.5.  Local Mobility Management

   In turn, the bootstrap problem is linked to the Local Mobility
   Management problem; some LMM solutions such as HMIP deploy regional
   Home Agents from which bootstrap information has to be obtained when
   moving into their area of coverage; as opposed to the initial
   bootstrap problem which occurs at the first startup of a device and
   may not happen again for an extensive period of time, LMM is tied to
   movement, and could be quite frequent.


3.  Requirements

   There is thus a need for a Mobile Router to obtain dynamically one or
   more MNPs, linked to the HA that the MR binds with.

   Since the process may be used as part of a mobility scenario, there
   is also a need to optimize the delegation flow by limiting the number
   of protocol exchanges that take place for delegation and
   registration.

   Since the initial configuration may be erroneous or may need to
   evolve overtime, there is a need to manage the MNPs on a Mobile
   Router.  This includes initial setting up, and synchronizing
   overtime.






Thubert & Kniveton      Expires February 22, 2008               [Page 5]


Internet-Draft                   NEMO-PD                     August 2007


4.  Rationale

   This section details the rationale behind some of the design
   decisions that lead to this solution.

4.1.  Which capabilities?

4.1.1.  Prefix Request capability

   The minimum capability that could be envisionned for a NEMO Prefix
   Delegation mechanism is for a MR to request for a new prefix in a
   Binding Update and for the HA to provide the prefix as part of the
   Binding Acknowledgement.  Then the Mobile Router installs the newly
   obtained prefix on the interface that needs it, and moves forward in
   implicit or explicit mode.

4.1.2.  Full prefix list capability for HA

   The capability to request a new prefix is sufficient in a basic
   delegation flow where a MR that is already bound and -hopefully-
   synchronized with its HA in terms of prefix ownership; it is also
   required in some bootstrapping and renumbering flows; but it is
   hardly sufficient in order to synchronize the MR and the HA states
   regarding MNPs:

   Bootstrapping:  At bootstrapping time, the MR needs the list of all
      the prefixes that are attributed in order to populate its
      interfaces.  Asking them one by one and having to make a
      distinction between already allocated prefixes versus dynamic
      allocation would make the flow much more complex.

   Expired prefixes:  That list is also needed for a MR in order to
      synchronize its current configuration with that of the HA.  In
      particular, it is used for a MR to discover when the HA does not
      have the associated states in place for one of its MNPs.  This may
      happen for some configuration error or because the prefix has
      expired, and the only way to know is if the prefix is missing in a
      full list of all prefixes by the HA.

   Newly allocated prefixes:  Finally, the list is needed for a MR to
      learn new prefixes that would be attributed in runtime, and to
      install those prefixes on its interfaces.  Once the new prefixes
      are installed, it is required that the MR confirms its use of the
      prefixes so that the HA can set up routing in a loopfree fashion.

   So the capability for a HA to list all the prefixes for a MR is
   needed for the MR to realize that the HA is missing some states and
   eventually to try to get the missing prefixes in explicit mode.  This



Thubert & Kniveton      Expires February 22, 2008               [Page 6]


Internet-Draft                   NEMO-PD                     August 2007


   may happen on demand by the MR (e.g. at bootstrap time or binding
   creation time), or whenever the HA needs to communicate about a
   change, such as a shortened or expired MNP lifetime.

4.1.3.  Full prefix list capability for MR

   So the capability for a HA to list all the prefixes is not sufficient
   is the HA is not the repository of that knowledge.  It might be
   simpler for the MR to dump its own list of prefixes and have the HA
   check the list, even for implicit prefixes.

4.2.  Rationale for new Binding options

   Associated to the capability to request a new prefix, it seems
   relevant to specify whether the prefix is for implicit or explicit
   mode, or if its lifetime is limited with that of the binding cache or
   not.  Other fields such as the prefix length are needed as well.  In
   order to convey that information, an optional field is needed in the
   BU.

   It is not desirable to extend the existing NEMO MNP option, which
   carries a prefix that is not needed, though.  As a result, we propose
   a new option type, the MNP request option.

   Associated to the capability for a HA to list all the prefixes for a
   MR, one critical information is needed, that would not fit in the
   NEMO MNP option.  Again, we propose a new option for the Binding
   Acknowledgement, the MNP confirm option.

4.3.  Rationale for a new bit in the BU

   A single bit in the BU is enough for a MR to request a full list of
   prefixes from the HA, if we do not need a filter of any sort????

   It is important that the HA set that bit in its full list of prefixes
   in order to differentiate between an empty list (there's no prefix
   for that MR) and no list (HA is not providing a list in that BA).

4.4.  Why not Alternate standard based solutions?

   Proposing a new, specific solution might seem irrelevant when a
   standard, generic mechanism already exist, in this case the DHCPv6
   Prefix Delegation.  In fact, it is possible for the Home Agent to act
   as a DHCPv6PD Delegating Router.  This solution presents the
   advantage of reusing existing standard flows from RFC3633 [4].

   Yet, in a deployment where the MNPs are preassigned to the MR, a AAA
   server, interfacing with the HA, and eventually coupled with a



Thubert & Kniveton      Expires February 22, 2008               [Page 7]


Internet-Draft                   NEMO-PD                     August 2007


   provisioning system in its back end, can provide the required service
   for assigning and authorizing the prefixes to the MRs; in such a
   case, the value of implementing a DHCPv6PD server is highly arguable.
   It is more generic to let the HA handle the backend interfaces on
   behalf of the MR and expose a consistent NEMO interface for all
   deployments.

   In more details, a DHCPv6PD based solution presents a number of
   inconveniences:

   Delegating Router:  A collocated Delegating Router function may not
      be available for all implementation of NEMO Home Agent.  In
      particular, some implementations are server based.

   Operational overhead:  Depending on the mechanism that is used to
      attribute the MNPs to the MRs, the Delegating function, even if
      available, might be a costly overhead.  Rather, an embedded, back-
      end agnostic flow might be a desirable option.

   Movement overhead:  Some flows, for instance local mobility
      management, might require a prefix delegation as part of the
      handling of the movement.  Segregating the delegation from the
      binding adds a round trip delay to the recovery from the movement.

   Binding Lifetime:  It might be useful to associate implicitly the
      lifetime of a delegated prefix with that of the binding.  This
      pleads for a design that places the Home Agent function in the
      flow by construction.

   Authentication Mechanism:  While NEMO basic Support protects its own
      flows, there is no mandate to secure the tunneled packets.

   Back-end interaction:  If a prefix is attributed to a MR for a
      duration that exceeds that of its binding, this information needs
      to be shared with all HAs, at least for authorization purposes.
      This requires a specific backend integration that does not exist
      in the Prefix Delegation Function, for instance via a AAA server.














Thubert & Kniveton      Expires February 22, 2008               [Page 8]


Internet-Draft                   NEMO-PD                     August 2007


5.  Terminology and concepts

   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 RFC2119 [1].

   Most of the mobility related terms used in this document are defined
   in the Mobility Related Terminology document [5] and in the mobile
   IPv6 specification [6].

   Additionally, some terms were created or extended for NEMO.  These
   specific terms are defined in the Mobile Network Terminology document
   [10]

   This draft introduces the following definitions:

   Mobile Network Prefix Request (MNPReq) Option:  A new optional field
      in the MIP6 Mobility Header for use with the binding Update
      message, as described further in this document.  This field is set
      by a MR to request the delegation of a new prefix as a Mobile
      Network Prefix.

   Mobile Network Prefix Confirm (MNPConf) Option:  A new optional field
      in the MIP6 Mobility Header for use with the binding
      Acknowledgement message, as described further in this document.

   transient prefix:  A prefix that is attributed to a Mobile Router in
      association with a binding cache entry.  If the BCE is removed,
      the prefix is freed.

   Persistent prefix:  A prefix that is attributed to a Mobile Router
      for a period of time that does not depend on the existence of a
      binding cache entry.


















Thubert & Kniveton      Expires February 22, 2008               [Page 9]


Internet-Draft                   NEMO-PD                     August 2007


6.  Overview

6.1.  New mobility Headers

   This paper introduces a new option to the MIP6 Mobility Header, for
   use with the binding Update message, the Mobile Network Prefix
   Request Option.  A MR may include one or more MNPReq option(s) in a
   Binding Update message at any time, in order to obtain additional
   prefixes.

   This paper introduces another new option to the MIP6 Mobility Header,
   for use with the binding Acknowledgement message, the Mobile Network
   Prefix Confirm Option.  An HA will include one or more MNPConf
   option(s) in a Binding Acknowledgement message, either in response to
   a Mobile Network Prefix Request Option, or for its own purposes, for
   instance in order inform a MR of a change about the lifetime of an
   MNP.

6.2.  New Prefix Status bit

   This paper finally introduces a new bit to the MIP6 Binding Update
   and Binding Acknowledgement, the Prefix Status bit.  A MR may include
   the Prefix Status bit in a binding Update message at any time, either
   in order to get its initial configuration, or to check whether its
   current configuration matches that of the Home Agent - which might be
   particularily useful in implicit mode.  When the Prefix Status bit is
   set in the BU, the Acknowledge bit MUST be set as well.

   The HA MAY set the Prefix Status bit in the Binding Acknowledgement
   even if it was not set by the MR in the Binding Update; the other way
   around, if the Prefix Status bit was set in the BU, then the HA MUST
   echo it in the BA.  When setting the Prefix Status bit, the HA also
   lists all the prefixes associated to that Mobile Router using Mobile
   Network Prefix Confirm options.

6.3.  Prefix lease duration

   A prefix may be obtained for the duration of the binding; in this
   case, the prefix is called 'transient'.  On the other hand, a prefix
   can be assigned to a MR for a duration that is independent of a BCE
   lifecycle, and that is controlled externally by the HA administrator;
   in that case, the prefix is called 'persistent'.

   A flag in the MNPReq option indicates the expectation of the MR in
   terms of persistence for the requested prefix.  If the HA can not
   fulfill that expectation, it must reject the binding with a negative
   status.




Thubert & Kniveton      Expires February 22, 2008              [Page 10]


Internet-Draft                   NEMO-PD                     August 2007


   The lease of a transient prefix expires with the MR Binding Cache
   Entry; as a result, transient prefixes can be managed internally by a
   HA, for instance using a local pool that forms an aggregation owned
   by the HA.

   One the other hand, some of the information about a persistent prefix
   has to be shared between the HAs in a Home Network and the back end
   systems that enable the authorization.  This is required to allow a
   Mobile Router to rebind, with the same persistent prefixes, to a
   different Home Agent, after a period of inactivity.

   It is possible to assign a persistent prefix dynamically at the time
   of the delegation; but the persistent mode also enables the
   preassignment of an MNP to an MR, for instance by provisionning a AAA
   server with the necessary information for each Mobile Router.

6.4.  Renumbering

   It is possible to redeploy the persistent prefix space, for instance
   if Home is being renumbered, or if a dynamically attributed prefix
   has not been bound for a long period of time.  In that case, the HA
   rejects a new binding as the routing states can not be set up, and
   the MR has to request one or more new persistent prefix(es).

6.5.  backward compatibility

   An HA that would not support this extension will ignore the
   unrecognized option.  Else, if the HA supports this draft, and if a
   binding update with the MNPReq option can be accepted per the NEMO
   basic support checkings:

6.6.  PD flow

   When a MR needs an additional prefix to populate an interface, it
   adds an MNPreq option to its Binding update message.

   If the HA can obtain the required prefix for that MR, it operates
   following the NEMO basic support, either in Implicit Mode, or in
   explicit mode using the prefixes as if they were received with the
   BU.  This includes setting up the routing states and responding with
   a positive or a negative status.

   If the routing states are established correctly and the HA responds
   with a positive status, then the HA adds the prefix list to the
   binding ack message.

   From that point on, both the MR and the HA operate as prescribed by
   the NEMO basic standard, either in implicit or in explicit mode.



Thubert & Kniveton      Expires February 22, 2008              [Page 11]


Internet-Draft                   NEMO-PD                     August 2007


7.  Message Formats

7.1.  Binding Update

   A new flag (S) is included in the Binding Update to indicate to the
   Home Agent that the MR wishes to get the full list of all prefixes
   that are already assigned to it.  The rest of the Binding Update
   format remains the same as defined in [7].

   When the (S) bit is set, the (R) and and (A) bits MUST be set as
   well.


                            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|M|R|S|    Reserved     |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 1: Binding Update

   Prefix Status (S)  The Prefix Status (S) bit is set by a MR to
      request the full list of all prefixes that are already assigned to
      it


















Thubert & Kniveton      Expires February 22, 2008              [Page 12]


Internet-Draft                   NEMO-PD                     August 2007


7.2.  Binding Acknowledgement

   A new flag (S) is included in the Binding Acknowledgement to indicate
   to the Mobile Router that the Home Agent provides the full list of
   all prefixes that are already assigned to the MR.  The rest of the
   Binding Acknowledgement format remains the same as defined in [7].

   When the (S) bit is set, the (R) bit MUST be set as well.


        0                   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|R|S|Reserved |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Sequence #            |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                     Figure 2: Binding Acknowledgement

   Prefix Status (S)  The Prefix Status (S) bit is set by a HA to
      indicate that it provides the full list of all prefixes that are
      already assigned to the MR.




















Thubert & Kniveton      Expires February 22, 2008              [Page 13]


Internet-Draft                   NEMO-PD                     August 2007


7.3.  Mobile Network Prefix option

   New flags are included in the Mobile Network Prefix option defined in
   [7].  This allows the option to cover all the prefixes owned by the
   MR, including those that are managed using the implicit prefix mode.


        0                   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     |   Length      |P|I|D|Reserved1| Prefix Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                   Mobile Network Prefix                       +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





                  Figure 3: Mobile Network Prefix option

   The new flags introduced by this specification are:

   Persistent (P)  The (P) bit is set if the prefix is expexted to be
      persistently assigned to the MR.

   Implicit (I)  The (I) bit is set if the prefix is expexted to be
      assigned to and routed via the MR even if the prefix is not listed
      in explicit mode BU.

   Delegated (D)  The (D) bit is set if the prefix was obtained using a
      the Delagation Mechanism as described in this specification.  It
      is used to acknowledge that a previously delegated prefix is
      actually installed and routable via the Mobile Router.











Thubert & Kniveton      Expires February 22, 2008              [Page 14]


Internet-Draft                   NEMO-PD                     August 2007


7.4.  Mobile Network Prefix request option

   This new option is included in the Binding Update to indicate to the
   Home Agent that the MR wishes to get a new prefix assigned to it for
   use as a MNP.

   When this option is present, the (S) MAY be set as well in the BU in
   order to get the full list of all prefixes.



        0                   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      |    Length     | Prefix Length |P|I| Reserved1 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     CorID                     |   Reserved2   | Prefix type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



              Figure 4: Mobile Network Prefix request option

   Type  TBA

   Length  8 bit unsigned integer indicating the length in octets of the
      option excluding the type and length fields.  Set to 6.

   Prefix Length  8 bit unsigned integer indicating the prefix length of
      the IPv6 prefix contained in the option.

   Persistent (P)  The (P) bit is set if the prefix that is requested to
      expected to be persistently assigned to the MR.

   Implicit (I)  The (I) bit is set if the prefix that is requested to
      expected to be assigned to, and routed via the MR, even if the
      prefix is not listed in explicit mode BU.

   CorId  A Correlator that is set by the MR in order to associate a MNP
      request with the prefix given in the confirm.  There can be at
      most one active prefix associated with each Correlator.  This
      mechanism ensure the unicity of the allocation of a prefix, should
      aither the BU or the BA be lost in the way.

   Prefix Type  Indicates the type of prefix that is requested:






Thubert & Kniveton      Expires February 22, 2008              [Page 15]


Internet-Draft                   NEMO-PD                     August 2007


      0  None Specified

      2  Unique Local

      3  Global














































Thubert & Kniveton      Expires February 22, 2008              [Page 16]


Internet-Draft                   NEMO-PD                     August 2007


7.5.  Mobile Network Prefix Confirm option

   This new option is included in the Binding Update to indicate to the
   Home Agent that the MR wishes to get a new prefix assigned to it for
   use as a MNP.

   When this option is present, the (S) MAY be set as well in the BU in
   order to get the full list of all prefixes.



        0                   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      |    Length     | Prefix Length |P|I|D|Reserved1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     CorID                     |   Reserved2   | Prefix type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Valid Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                   Mobile Network Prefix                       +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




              Figure 5: Mobile Network Prefix Confirm option

   Type  TBA

   Length  8 bit unsigned integer indicating the length in octets of the
      option excluding the type and length fields.  Set to 26.

   Prefix Length  8 bit unsigned integer indicating the prefix length of
      the IPv6 prefix contained in the option.

   Persistent (P)  The (P) bit is set if the prefix is persistently
      assigned to the MR.







Thubert & Kniveton      Expires February 22, 2008              [Page 17]


Internet-Draft                   NEMO-PD                     August 2007


   Implicit (I)  The (I) bit is set if the prefix is assigned to and
      routed via the MR even if the prefix is not listed in explicit
      mode BU.

   Delegated (D)  The (D) bit is set if the prefix was obtained using a
      the Delagation Mechanism as described in this specification.

   CorId  If the (D) bit is set, the Correlator that was set by the MR
      in an MNPReq and this option contains the prefix that is being
      delegated in response to that Request.  If the (D) bit is not set,
      the Correlator value is defined by the HA.

   Prefix Type  Indicates the type of prefix that is requested:

      0  None Specified

      2  Unique Local

      3  Global

   Valid Lifetime  32-bit unsigned integer.  The length of time in
      seconds (relative to the time the packet is sent) that the prefix
      is valid for being installed on an MR ingress interface.  A value
      of all one bits (0xffffffff) represents infinity.  The Valid
      Lifetime is also used by RFC2461 [2] and RFC2462 [3], and must be
      used in the RAs sent over the MR ingress interface for that
      prefix.

   Mobile Network Prefix  A 16 byte field contains the Mobile Network
      Prefix.





















Thubert & Kniveton      Expires February 22, 2008              [Page 18]


Internet-Draft                   NEMO-PD                     August 2007


8.  Security Considerations

   This protocol extension is protected by the mechanisms defined for
   Mobile IPv6 and NEMO Basic Support.  It is designed for use between a
   Home Agent and a Mobile Router, so the threats introduced by the
   Route Optimization process do not apply.


9.  IANA Considerations

   The specification requires the following allocations from IANA:

      The Mobile Network Prefix Request option described in Section 7.4
      requires a new option type.  This option is included in the
      Mobility header described in Mobile IPv6 [6] .

      The Mobile Network Prefix Confirm option described in Section 7.5
      requires a new option type.  This option is included in the
      Mobility header described in Mobile IPv6 [6].


10.  Acknowledgements

   The authors wish to thank:

   Pekka Paakkonen and Juhani Latvakoski from VTT Electronics for their
   initial work on the matter.  Hesham Soliman for his suggestion to
   couple PD with NAI.























Thubert & Kniveton      Expires February 22, 2008              [Page 19]


Internet-Draft                   NEMO-PD                     August 2007


11.  References

11.1.  Normative Reference

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

   [2]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [3]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [4]   Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633,
         December 2003.

   [5]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

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

   [7]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

   [8]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
         Access Identifier", RFC 4282, December 2005.

   [9]   Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
         "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
         RFC 4283, November 2005.

   [10]  Ernst, T. and H-Y. Lach, "Network Mobility Support
         Terminology", RFC 4885, July 2007.

11.2.  Informative Reference

   [11]  Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
         Mobile IPv6 (MIPv6)", RFC 4640, September 2006.

   [12]  Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
         Mobility Home Network Models", RFC 4887, July 2007.







Thubert & Kniveton      Expires February 22, 2008              [Page 20]


Internet-Draft                   NEMO-PD                     August 2007


Authors' Addresses

   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Phone: +33 4 97 23 26 34
   Email: pthubert@cisco.com


   T.J. Kniveton
   Nokia, Inc.
   313 Fairchild Dr.
   Building B-223
   Mountain View  94043
   USA

   Phone: +1 650 625 2025
   Email: tj@kniveton.com




























Thubert & Kniveton      Expires February 22, 2008              [Page 21]


Internet-Draft                   NEMO-PD                     August 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Thubert & Kniveton      Expires February 22, 2008              [Page 22]


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