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

Versions: 00 01

Network-Based Mobility Extensions                            J. Korhonen
(Netext)                                                  Renesas Mobile
Internet-Draft                                             T. Savolainen
Intended status: Standards Track                                   Nokia
Expires: January 30, 2014                                  S. Gundavelli
                                                                   Cisco
                                                           July 29, 2013


         Local Prefix Lifetime Management for Proxy Mobile IPv6
                 draft-korhonen-dmm-local-prefix-01.txt

Abstract

   This specification defines a protocol extension to Proxy Mobile IPv6
   that enables prefix lifetime management for locally assigned prefixes
   within a Proxy Mobile IPv6 domain.  A locally assigned prefix is
   managed by a Mobile Access Gateway and is always topologically
   anchored to the Mobile Access Gateway within the Proxy Mobile IPv6
   domain.

Requirements Language

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 30, 2014.

Copyright Notice

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



Korhonen, et al.        Expires January 30, 2014                [Page 1]


Internet-Draft           Local Prefix Management               July 2013


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Mobility Options . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Mobile Access Gateway Operation  . . . . . . . . . . . . . . .  6
     4.1.  Extensions to Binding Update List Entry Data Structure . .  6
     4.2.  Local Prefix/Address Assignment  . . . . . . . . . . . . .  7
     4.3.  Local Use of Prefixes/Addresses  . . . . . . . . . . . . .  7
     4.4.  Local Prefixes/Addresses Management  . . . . . . . . . . .  7
       4.4.1.  Deprecating Prefixes/Addresses . . . . . . . . . . . .  7
       4.4.2.  Temporary Tunneling Between Mobile Access Gateways . .  8
       4.4.3.  Informing a Mobile Node of an Inoperable
               Prefix/Address . . . . . . . . . . . . . . . . . . . .  8
   5.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . .  8
     5.1.  Extensions to Binding Cache Entry Data Structure . . . . .  8
     5.2.  Local Prefix/Address Context Transfer  . . . . . . . . . .  8
     5.3.  Local Prefixes/Addresses Management  . . . . . . . . . . .  9
   6.  Signaling Flow Examples  . . . . . . . . . . . . . . . . . . .  9
     6.1.  Stateless Address AutoConfiguration Example  . . . . . . .  9
     6.2.  Stateful Address Configuration Example . . . . . . . . . . 11
   7.  Configuration Objects  . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15











Korhonen, et al.        Expires January 30, 2014                [Page 2]


Internet-Draft           Local Prefix Management               July 2013


1.  Introduction

   This specification defines a protocol extension to Proxy Mobile IPv6
   (PMIPv6) [RFC5213] that enables prefix/address lifetime management
   for locally assigned prefixes/addresses within a PMIPv6 domain.  A
   prefix/address locally assigned to the mobile node (MN) is managed by
   a specific Mobile Access Gateway (MAG) and is always topologically
   anchored to that MAG within the PMIPv6 domain.  The protocol
   extension essentially defines a context transfer mechanism that
   allows for a source MAG to inform a target MAG about locally assigned
   prefixes/addresses during the handover.

   After a handover, the prefixes/addresses from the source MAG are
   topologically in an incorrect location when the mobile node (MN) is
   attached to the target MAG.  The context transfer mechanism defined
   in this specification can implicitly serve as a trigger to create a
   temporary tunneling (read, localized routing) between MAGs for the
   period prefixes/addresses from the source MAG are used under the
   target MAG.

   Additionally, using the context transfer information the target MAG
   can take required actions to deprecate those prefixes/addresses that
   belong to the source MAG.  The specified mechanism is a complementary
   for Simple Procedures for Detecting Network Attachment in IPv6 (DNA)
   [RFC6059].  Explicit network side prefix/address deprecation is
   useful in situations, for instance, when the MN does not implement
   DNA or there is a need to trigger DHCPv6 Reconfigure procedure
   [RFC3315] when the MN attaches to the target MAG.

      [Discussion: it is to be verified whether the existing PMIPv6
      Localized Routing protocol [RFC6705] with small enhancements is
      appropriate for the temporary tunneling between MAGs for the
      purpose this specification has.]

   Locally assigned prefixes/addresses that are topologically anchored
   to the MAG allow for optimized access to local resources near the
   MAG.  This, of course, assumes the MAG is able to route certain
   traffic locally bypassing the PMIPv6 tunnel, and the MN is able to
   detect which prefixes/addresses are local or have mobility
   [I-D.korhonen-6man-prefix-properties][I-D.bhandari-dhc-class-based-pr
   efix].


2.  Solution Overview

   The protocol solution in this specification is targeted to the
   following use case and illustrated in Figure 1.  Additional use cases
   outside the IP mobility domain are discussed extensively in



Korhonen, et al.        Expires January 30, 2014                [Page 3]


Internet-Draft           Local Prefix Management               July 2013


   [I-D.lepape-6man-prefix-metadata].

   o  A MN is assigned with multiple prefixes that it uses to configure
      multiple IPv6 addresses.

   o  Some of the prefixes/addresses assigned to the MN are anchored at
      the Local Mobility Anchor (LMA) and provide mobility within the
      PMIPv6 domain.

   o  Some of the prefixes/addresses assigned to the MN are local to the
      MAG the MN is currently attached to.  These prefixes/addresses
      provide mobility only in a limited area, for example, within the
      layer-2 domain under the MAG control.

   o  When the MN moves from a MAG (i.e., a source MAG) to another MAG
      (i.e., a target MAG), the prefixes/addresses anchored to the LMA
      remain but the prefixes/addresses anchored to a MAG will change.
      The prefixes/addresses are topologically only valid under the MAG
      they are anchored to.

   o  If DHCPv6 is used for configuring addresses to the MN, then the
      DHCPv6 server is collocated in the LMA.


      +----------------------> Internet
      |                           ^
      |                           :    mobility
      |                           |   (Prefix_z)
      |                        +-----+
      |                        | LMA |
      |                        +-----+
    +---+     +---+               |              +---+
    |rtr|     |CNx|               |              |CNy|
    +---+     +---+               |              +---+
      |         |                 |                |
   ---+---------+------+ +--------+--------+ +-----+-----
         local         | |                 | |     local
        network        | |                 | |    network
       (Prefix_x)     +---+               +---+  (Prefix_y)
                      |src|   temporary   |tgt|
                      |MAG|===============|MAG|
                      +---+     tunnel    +---+
                        :                  :
                      +--+                +--+
                      |MN|--------------->|MN|
                      +--+    handover    +--+

      Figure 1: Local services provided topologically close to a MAG



Korhonen, et al.        Expires January 30, 2014                [Page 4]


Internet-Draft           Local Prefix Management               July 2013


   In order to provide a mechanism for a source MAG to inform the target
   MAG about prefixes the MN might have configured and that are
   topologically valid only under the source MAG, there is a need for a
   context transfer of locally assigned prefix/address information
   between MAGs.  This specification extends both the PMIPv6 signaling
   and the Binding Cache in the LMA with a local prefix/address
   information.

   During the Proxy Binding Update (PBU) and the Proxy Binding
   Acknowledgement (PBA) exchange, MAGs and the LMA inform each other
   about locally assigned prefixes/addresses.  Using that information, a
   target MAG can do the following two things:

   o  Make sure the prefixes/addresses from the source MAG get
      deprecated and eventually invalidated using some mechanism (that
      essentially does not require end host stack changes).

   o  Optionally create of a temporary tunnel between the source and the
      target MAG, and setting up the required host routes for routing
      addresses belonging to the source MAG back and forth until the
      addresses become invalid.


3.  Mobility Options

   A MAG uses the Local Prefix mobility option (LPO) to inform the LMA
   of the IPv6 prefix/address and its valid lifetime (see [RFC4861] and
   [RFC3315]) that shall be locally assigned to a MN.  After a handover
   an LMA uses the option to inform a target MAG of the IPv6 prefix/
   address that was assigned to a MN by the previous MAG.  The Local
   Prefix option has an alignment of 4n.  There can be zero or more LPOs
   in a PUB and in a PBA.

    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=TBD1    |   Length=22   | Prefix Length |R|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Valid Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    Local Prefix/address                       |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Local Prefix Mobility Option



Korhonen, et al.        Expires January 30, 2014                [Page 5]


Internet-Draft           Local Prefix Management               July 2013


   Type:

      Set to TBD1.

   Length:

      The length of the Local Prefix mobility option in octets,
      excluding the Option Type and Length fields.  The length is set to
      22.

   Prefix Length:

      The prefix length of the local IPv6 prefix.  Valid prefix lengths
      are between 1 and 128.  In case of an IPv6 address the prefix
      length is 128.

   'R':

      Set to 1 if the sender of the LPO wants the receiver to deprecate/
      invalidate/remove the prefix/address.  Otherwise set to 0.

   Reserved:

      This field is reserved for future use.  MUST be set to zero by the
      sender and ignored by the receiver.

   Valid Lifetime:

      The valid lifetime of the IPv6 prefix/address.  The value follows
      the valid lifetime semantics of Prefix Information Option
      [RFC4861] and OPTION_IAADDR option [RFC3315].

   Local Prefix/address:

      The locally assigned IPv6 prefix/address.


4.  Mobile Access Gateway Operation

4.1.  Extensions to Binding Update List Entry Data Structure

   The Binding Update List Entry (BULE) data structure for each MN's
   mobility binding with its LMA is extended with zero or more locally
   assigned IPv6 prefix/address, and its lifetime information.







Korhonen, et al.        Expires January 30, 2014                [Page 6]


Internet-Draft           Local Prefix Management               July 2013


4.2.  Local Prefix/Address Assignment

   A MAG maintains a pool of locally usable prefixes/addresses.  If the
   'EnableLocalPrefixManagement' configuration object is set to TRUE,
   then the MAG assigns one or more local prefixes/addresses to the MN
   during the initial attach.  Essentially the MAG adds new Local Prefix
   Mobility Options into the Proxy Binding Update (PBU) message, and
   eventually advertises those prefixes to the MN when using Stateless
   Address AutoConfiguration (SLAAC).

4.3.  Local Use of Prefixes/Addresses

   The local prefixes/addresses are topologically anchored to the MAG,
   and do not really provide mobility in a same level as PMIPv6 provides
   for Home Network Prefixes (HNP) anchored to the LMA.  This
   specification also requires the MAG is provided with a functionality
   that certain traffic can bypass the PMIPv6 tunnel in the MAG.  Such
   functionality is already hinted in [RFC5213] Section 6.10.3.
   However, this specification further assumes the local corresponded
   nodes do not need to be directly on the access link connected to the
   MAG.  They can be any number of IP hops away.

   There is no restriction on the scope of the local prefixes/addresses.
   A MN could use local addresses to the MAG as its source address to
   access the Internet, assuming local addresses have a global scope.
   Similarly, the MN could use the home address anchored to the LMA to
   reach local destinations around the MAG.

4.4.  Local Prefixes/Addresses Management

   After a MN has moved from a source MAG to a target MAG as a result of
   a handover, the MN might be configured with prefixes/addresses that
   topologically belong to the source MAG.  In this case, the target MAG
   may purposely need to deprecate and invalidate or otherwise handle
   prefixes/addresses that are topologically in a wrong place (i.e., are
   anchored to the source MAG).  We could assume that the DNA [RFC6059]
   handles this but explicit actions by the target MAG make sure that
   MNs without DNA support are also covered.

4.4.1.  Deprecating Prefixes/Addresses

   A target MAG receives information of prefixes/addresses that are not
   valid under the target MAG in LPOs included in a PBA from a LMA.  If
   SLAAC is used to configure addresses to a MN, then the target MAG
   SHOULD deprecate prefixes from the source MAG by sending a Router
   Advertisement with a Prefix Information Option (PIO) and set at least
   the preferred lifetime to zero (0).  The valid lifetime is set to
   value received in the corresponding LPO.  If e.g.  SeND [RFC3971] is



Korhonen, et al.        Expires January 30, 2014                [Page 7]


Internet-Draft           Local Prefix Management               July 2013


   used, then the valid lifetime can also be set to zero (0).

4.4.2.  Temporary Tunneling Between Mobile Access Gateways

   During the handover from a source MAG to a target MAG, it might not
   be possible to make the MN to discard all addresses in use that
   belong to the source MAG.  This is the case, for example, when the MN
   does not implement the DNA functionality and the valid lifetime of
   the prefixes is still greater than zero.  In this case, it would be
   beneficial to establish a temporary tunnel for the local addresses
   from the source MAG to the target MAG for the period the valid
   lifetime of the prefixes expires.  The temporary tunnel would be
   removed immediately when valid lifetime of the local prefix from the
   source MAG expires.  Whether the target MAG initiates the creation of
   the temporary tunnel between MAGs is controlled by the
   'EnableTemporaryLocalizedRouting' configuration object.

   [Discussion: it is to be verified whether [RFC6705] is usable for
   this purpose and whether it has to be extended to cover the above use
   case or do we need to develop a new one.]

4.4.3.  Informing a Mobile Node of an Inoperable Prefix/Address

   If tunneling between MAGs as described in Section 4.4.2 is not an
   option, then the target MAG SHOULD respond to all IP packets a MN
   originates with an address belonging to the source MAG with an ICMPv6
   error Destination Unreachable Message and set the Code to 5 (Source
   address failed ingress/egress policy) [RFC4443].  The configuration
   SHOULD remain active until the valid lifetime received from the
   corresponding LPO expires.


5.  Local Mobility Anchor Operation

5.1.  Extensions to Binding Cache Entry Data Structure

   The Binding Cache Entry (BCE) data structure for each currently
   registered MN is extended with zero or more locally assigned IPv6
   prefix/address and its valid lifetime pairs.  The prefix/address in
   the Local Prefix mobility option MUST NOT be used as a BCE look up
   key.

5.2.  Local Prefix/Address Context Transfer

   The operation of the LMA is fairly simple.  When the LMA received a
   PBU and the BCE for the MN has no prior knowledge of a local prefix/
   address information learned from the received LPO option, then the
   LMA:



Korhonen, et al.        Expires January 30, 2014                [Page 8]


Internet-Draft           Local Prefix Management               July 2013


   o  Records the prefix/address into the BCE.

   o  Records the valid lifetime of the prefix/address into the BCE.

   o  Echoes the prefix/address, the valid lifetime and 'R' set to 0
      information back to the MAG in the LPO option included in the PBA.

   If the BCE for the MN has existing local prefix/address information
   learned from the received LPO option, then the LMA:

   o  Records the new prefix/address into the BCE.

   o  Records the new valid lifetime of the prefix/address into the BCE.

   o  Returns the old prefix/address, the valid lifetime and 'R' set to
      1 information back to the MAG in the LPO option included in the
      PBA.

5.3.  Local Prefixes/Addresses Management

   After a MN has moved from a source MAG to a target MAG as a result of
   a handover, the MN might be configured with prefixes/addresses that
   topologically belong to the source MAG.  If DHCPv6 was used to
   configure addresses to the MN, then the LMA SHOULD initiate the
   DHCPv6 Reconfigure procedure towards the MN immediately after sending
   the PBA to the target MAG.  If SLAAC was used to configure addresses
   to the MN, then the LMA does not need to do anything beyond what has
   already been done in Section 5.2.


6.  Signaling Flow Examples

6.1.  Stateless Address AutoConfiguration Example

   Figure 3 shows example PMIPv6 signaling for the initial attachment to
   the PMIPv6 domain and a handover with locally assigned prefixes and
   when the stateless autoconfiguration (SLAAC) [RFC4862] is used for
   configuring addresses.

   In the following figure 'PIO' stands for Prefix Information Option
   [RFC4861] in a Router Advertisement, 'p' means the preferred lifetime
   in a PIO, and 'v' means the valid lifetime in a PIO. 'lp1' stands for
   local prefix 1 and 'lt1' for its valid lifetime.  Similarly 'lp2'
   stands for local prefix 2 and 'lt2" for its valid lifetime. 'lp1' is
   different from 'lp2'.






Korhonen, et al.        Expires January 30, 2014                [Page 9]


Internet-Draft           Local Prefix Management               July 2013


       [MN]            [MAG_1]          [MAG_2]           [LMA]
         |                |                |                |
         |--- Rtr Sol --->|                |                |
         |                |                |                |
         |        MAG_1 assigns local      |                |
         |        IPv6 prefix lp1          |                |
         |                |                |                |
         |                |--- PBU ------------------------>|
         |                |    LPO=lp1/lt1/R=0,             |
         |                |    HNP=0,      |          LMA records
         |                |    HI=1, ...   |          lp1/lt1, assigns
         |                |                |          HNP pref
         |                |                |                |
         |                |<-- PBA -------------------------|
         |                |    LPO=lp1/lt1/R=0,             |
         |<-- Rtr Adv ----|    HNP=pref, ...                |
         |    PIO=pref,   |                |                |
         |    PIO=lp1/p=lt1/v=lt1  (new)   |                |
         |                |                |                |
                    .... handover takes place ....
         |                |                |                |
         |--- Rtr Sol -------------------->|                |
         |                |                |                |
         |                |        MAG_2 assigns local      |
         |                |        IPv6 prefix lp2          |
         |                |                |                |
         |                |                |--- PBU ------->|
         |                |                |    LPO=lp2/lt2/R=0,
         |                |                |    HNP=0, HI=3,|
         |                |                |    ...         |
         |                |                |         lp2 != lp1, thus
         |                |                |         LMA records
         |                |                |         lp2/lt2, returns
         |                |                |         previous lp1/lt1
         |                |                |                |
         |                |                |<-- PBA --------|
         |<-- Rtr Adv ---------------------|    LPO=lp1/lt1/R=1,
         |    PIO=pref,   |                |    HNP=pref, ...
         |    PIO=lp2/p=lt2/v=lt2, (new)   |                |
         |    PIO=lp1/p=0/v=lt1    (old)   |                |
         |                |                |                |

     Figure 3: Local prefix assignment and lifetime management example
                                using SLAAC







Korhonen, et al.        Expires January 30, 2014               [Page 10]


Internet-Draft           Local Prefix Management               July 2013


6.2.  Stateful Address Configuration Example

   Figure 4 shows example PMIPv6 signaling for the initial attachment to
   the PMIPv6 domain with locally assigned prefixes and when the
   stateful address configuration (DHCPv6) is used for configuring
   addresses.

   In the following figures 'p' means the preferred lifetime in an IA_TA
   or IA_NA, and 'v' means the valid lifetime in an IA_TA or IA_NA
   respectively.  Also, 'la1' stands for local address 1 and 'lt1' for
   its valid lifetime.  Similarly 'la2' stands for local address 2 and
   'lt2" for its valid lifetime. 'la1' is different from 'la2'.  The
   'IA_xA' stands for either IA_TA or IA_NA.

       [MN]         [MAG_1/Relay]      [DHCPv6-S ~ ~ ~ ~ ~ LMA]
         |                |                |                |
         |--- Rtr Sol --->|                |                |
         |                |                |                |
         |        MAG_1 assigns local      |                |
         |        IPv6 address la1         |                |
         |                |                |                |
         |                |--- PBU ------------------------>|
         |                |    LPO=la1/R=0,|                |
         |                |    HNP=0,      |          LMA records
         |                |    HI=1, ...   |          la1, assigns
         |                |                |          HNP pref
         |                |                |                |
         |                |<-- PBA -------------------------|
         |<-- Rtr Adv ----|    LPO=la1/lt1/R=0,             |
         |    M=1, ...    |    HNP=pref,   |                |
         |                |    ...         |                |
         |                |                |                |
         |--- Solicit --->| Relay adds     |                |
         |                | link-addr=pref |                |
         |                |                |                |
         |                |--- Relay-f --->| DHCPv6 server  |
         |                |                | adds IA_xA with|
         |                |                |   la1/p=lt1/v=lt1,
         |                |                |   HoA based on pref,
         |                |                | Reconfigure Accept,
         |                |                | ...            |
         |                |<-- Relay-r ----|                |
         |<--- Advert or -|                |                |
         |     Reply      |                |                |
         |                |                |                |
         | ... DHCPv6 negotiation may continue...
         |                |                |                |




Korhonen, et al.        Expires January 30, 2014               [Page 11]


Internet-Draft           Local Prefix Management               July 2013


      Figure 4: Local prefix assignment example using stateful DHCPv6

   Figure 5 shows example PMIPv6 signaling for a handover with locally
   assigned prefixes and when the stateful address configuration
   (DHCPv6) is used for configuring addresses.

       [MN]         [MAG_2/Relay]      [DHCPv6-S ~ ~ ~ ~ ~ LMA]
         |                |                |                |
                    .... handover takes place ....
         |                |                |                |
       [ |--- Rtr Sol --->| ]              |                |
         |                |                |                |
         |        MAG_2 assigns local      |                |
         |        IPv6 address la2         |                |
         |                |                |                |
         |                |--- PBU ------------------------>|
         |                |    LPO=la2/lt2/R=0,             |
         |                |    HNP=0,      |         la2 != la1, thus
         |                |    HI=3, ...   |         LMA records
         |                |                |         la2/lt2, returns
         |                |                |       previous la1/lt1/R=1
         |                |                |                |
         |                |<-- PBA -------------------------|
       [ |<-- Rtr Adv ----| ]  LPO=la1/lt1/R=1,             |
         |    M=1, ...    |    HNP=pref,   |                |
         |                |    ...         |                |
         |                |                |                |
         |<-- Reconfigure ----------------------------------|
         |    IA_xA,      |                |                |
         |    ...         |                |                |
         |                |                |                |
         |--- Renew --------------------------------------->|
         |    IA_xA with  |                |                |
         |      HoA,      |                |    DHCPv6 server
         |      la1,      |                |    adds IA_xA with
         |    ...         |                |       la1/p=0/v=0,
         |                |                |       la2/p=lt2/v=lt2,
         |                |                |       HoA,     |
         |                |                |    ...         |
         |                |                |                |
         |<-- Reply ----------------------------------------|
         |    ...         |                |                |
         |                |                |                |

   Figure 5: Local prefix change example using stateful DHCPv6 during a
                                 handover





Korhonen, et al.        Expires January 30, 2014               [Page 12]


Internet-Draft           Local Prefix Management               July 2013


7.  Configuration Objects

   This specification defines two configuration objects.

   EnableLocalPrefixManagement

      This configuration object is available in both a MAG and in a LMA.
      When set to TRUE (i.e., enabled), the PMIPv6 node enables the
      local IPv6 prefix/address lifetime management functionality.  The
      default value is FALSE (i.e., disabled).

   EnableTemporaryLocalizedRouting

      This configuration object is available in both a MAG and in a LMA.
      When set to TRUE (i.e., enabled), the MAG or the LMA MAY initiate
      the localized routing (tunnel) [RFC6705] for the period locally
      meaningful prefixes from the previous MAG are still valid.  The
      default value is FALSE (i.e., disabled).


8.  Security Considerations

   The security considerationf for the Proxy Mobile IPv6 [RFC5213]
   apply.  Furthermore, generic security threats regarding the address/
   prefix ownership also apply [RFC3971].  An attacker can make use of
   unprotected Router Advertisements to interfere the address selection
   the MN does and in that way hijact traffic.  This requires that the
   attacker is albe to gain access to the same link the victim host is.

      [Editor's Note: security considerations to be imporved.]


9.  IANA Considerations

   One new mobility options for the use with PMIPv6 is defined in the
   [RFC6275] "Mobility Options" registry.  The mobility option is
   defined in Section 3:

      Local Prefix Mobility Option is set to   TBD1


10.  Acknowledgements

   We ack.


11.  References




Korhonen, et al.        Expires January 30, 2014               [Page 13]


Internet-Draft           Local Prefix Management               July 2013


11.1.  Normative References

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

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

11.2.  Informative References

   [I-D.bhandari-dhc-class-based-prefix]
              Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
              Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
              based prefix", draft-bhandari-dhc-class-based-prefix-05
              (work in progress), July 2013.

   [I-D.korhonen-6man-prefix-properties]
              Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
              Liu, "IPv6 Prefix Properties",
              draft-korhonen-6man-prefix-properties-02 (work in
              progress), July 2013.

   [I-D.lepape-6man-prefix-metadata]
              Pape, M., Systems, C., and I. Farrer, "IPv6 Prefix Meta-
              data and Usage", draft-lepape-6man-prefix-metadata-00
              (work in progress), July 2013.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.




Korhonen, et al.        Expires January 30, 2014               [Page 14]


Internet-Draft           Local Prefix Management               July 2013


   [RFC6059]  Krishnan, S. and G. Daley, "Simple Procedures for
              Detecting Network Attachment in IPv6", RFC 6059,
              November 2010.

   [RFC6705]  Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6",
              RFC 6705, September 2012.


Authors' Addresses

   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24
   FIN-00180 Helsinki
   Finland

   Email: jouni.nospam@gmail.com


   Teemu Savolainen
   Nokia
   Hermiankatu 12 D
   FI-33720 Tampere
   FINLAND

   Email: teemu.savolainen@nokia.com


   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com















Korhonen, et al.        Expires January 30, 2014               [Page 15]


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