    Internet Engineering Task Force (IETF)                       S. Krishnan
    Request for Comments: 6705                                      Ericsson
    Category: Standards Track                                      R. Koodli
    ISSN: 2070-1721                                            Cisco Systems
                                                                 P. Loureiro
                                                                         NEC
                                                                       Q. Wu
                                                                      Huawei
                                                                    A. Dutta
                                                                      NIKSUN
                                                              September 2012

                    Localized Routing for Proxy Mobile IPv6

    Abstract

       Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
       protocol that enables IP mobility for a host without requiring its
       participation in any mobility-related signaling.  PMIPv6 requires all
       communications to go through the local mobility anchor.  As this can
       be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs)
       attached to the same or different Mobile Access Gateways (MAGs) to
       route traffic by using localized forwarding or a direct tunnel
       between the gateways.  This document proposes initiation,
       utilization, and termination mechanisms for localized routing between
       mobile access gateways within a proxy mobile IPv6 domain.  It defines
       two new signaling messages, Localized Routing Initiation (LRI) and
       Local Routing Acknowledgment (LRA), that are used to realize this
       mechanism.

    Status of This Memo

       This is an Internet Standards Track document.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by
       the Internet Engineering Steering Group (IESG).  Further
       information on Internet Standards is available in Section 2 of
       RFC 5741.

       Information about the current status of this document, any
       errata, and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6705.

    Krishnan, et al.             Standards Track                    [Page 1]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    Copyright Notice

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

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (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. Conventions Used in This Document ...............................3
       3. Initiation of Localized Routing .................................3
          3.1. MAG Behavior ...............................................4
          3.2. LMA Behavior ...............................................4
       4. Teardown of Localized Routing ...................................4
       5. Scenario A11: Two MNs Attached to the Same MAG and LMA ..........4
          5.1. Handover Considerations ....................................6
       6. Scenario A21: Two MNs Attached to Different MAGs but the
          Same LMA ........................................................7
          6.1. Handover Considerations ....................................9
          6.2. Tunneling between the MAGs .................................9
       7. Scenario A12: Two MNs Attached to the Same MAG with
          Different LMAs .................................................10
          7.1. Handover Considerations ...................................12
       8. Scenario A22: Two MNs Attached to Different MAGs with
          Different LMAs .................................................13
       9. IPv4 Support in Localized Routing ..............................13
       10. Message Formats ...............................................13
          10.1. Localized Routing Initiation (LRI) .......................14
          10.2. Localized Routing Acknowledgment (LRA) ...................15
       11. New Mobility Option ...........................................16
          11.1. MAG IPv6 Address .........................................16
       12. Configuration Variables .......................................17
       13. Security Considerations .......................................17
       14. IANA Considerations ...........................................17
       15. Contributors ..................................................18
       16. Acknowledgments ...............................................18
       17. References ....................................................19
          17.1. Normative References .....................................19
          17.2. Informative References ...................................19

    Krishnan, et al.             Standards Track                    [Page 2]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    1.  Introduction

       Proxy Mobile IPv6 [RFC5213] describes the protocol operations to
       maintain reachability and session persistence for a Mobile Node (MN)
       without the explicit participation from the MN in signaling
       operations at the Internet Protocol (IP) layer.  In order to
       facilitate such network-based mobility, the PMIPv6 protocol defines a
       Mobile Access Gateway (MAG), which acts as a proxy for the Mobile
       IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA), which
       acts similar to a Home Agent.  The LMA and the MAG establish a
       bidirectional tunnel for forwarding all data traffic belonging to the
       Mobile Nodes.  In the case where both endpoints are located in the
       same PMIPv6 domain, this can be suboptimal and result in increased
       delay and congestion in the network.  Moreover, it increases
       transport costs and traffic load at the LMA.

       To overcome these issues, localized routing can be used to allow
       nodes attached to the same or different MAGs to directly exchange
       traffic by using localized forwarding or a direct tunnel between the
       gateways.  [RFC6279] defines the problem statement for PMIPv6
       localized routing.  This document describes a solution for PMIPv6
       localized routing between two MNs in the same PMIPv6 domain.  The
       protocol specified here assumes that each MN is attached to a MAG and
       that each MN's MAG has established a binding for the attached MN at
       its selected LMA according to [RFC5213].  The protocol builds on the
       scenarios defined in [RFC6279].

    2.  Conventions Used in This Document

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

       This document also uses the terminology defined in Section 2 of
       [RFC6279].

    3.  Initiation of Localized Routing

       Since the traffic to be localized passes through both the LMA and the
       MAGs, it is possible, at least in some scenarios, for either of them
       to initiate Localized Routing (LR).  In order to eliminate ambiguity,
       the protocol described in this document selects the initiator of LR
       based on the rules below.

    Krishnan, et al.             Standards Track                    [Page 3]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    3.1.  MAG Behavior

       The MAG MUST initiate LR if both of the communicating MNs are
       attached to it and the MNs are anchored at different LMAs.  The MAG
       MUST NOT initiate LR in any other case.

    3.2.  LMA Behavior

       The LMA MUST initiate LR if both of the communicating MNs are
       anchored to it.  The LMA MUST NOT initiate LR in any other case.

    4.  Teardown of Localized Routing

       The use of localized routing is not persistent.  Localized routing
       has a defined lifetime as specified by the initiator; upon expiry,
       the forwarding MUST revert to using bidirectional tunneling.  When
       localized routing ceases, the corresponding Localized Routing Entries
       (LREs) MUST be removed.

       If the initiator of LR wishes to terminate localized routing before
       the expiry of the lifetime specified in the LRI message, it MUST do
       so by sending a new LRI message with the lifetime set to zero.

    5.  Scenario A11: Two MNs Attached to the Same MAG and LMA

       In this scenario, the two Mobile Nodes involved in communication are
       attached to a single MAG and both are anchored at the same LMA as
       shown in Figure 1.

                                     Internet
                                        :
                                        |
                                        |
                                     +-----+
                                     | LMA |
                                     +-----+
                                        |
                                        |
                                        |
                                     +-----+
                                     | MAG |
                                     +-----+
                                      :   :
                                   +---+ +---+
                                   |MN1| |MN2|
                                   +---+ +---+

                                     Figure 1

    Krishnan, et al.             Standards Track                    [Page 4]

    RFC 6705                PMIPv6 Localized Routing          September 2012

       The LMA initiates a localized routing session by detecting traffic
       between two MNs attached to the same MAG.  The exact traffic
       identification mechanism is not specified in this document and is
       left open for implementations and specific deployments.  An example
       trigger could be that an application-layer signaling entity detects
       the possibility of localized routing and notifies the LMA about the
       two endpoints, and the LMA determines that the two endpoints are
       attached to the same MAG.  Such a trigger mechanism offers localized
       routing at the granularity of an individual application session,
       providing flexibility in usage.  It is also possible that one of the
       mobility entities (LMA or MAG) could decide to initiate localized
       routing based on configured policy.  Please note that a MAG
       implementing the protocol specified in this document will not
       dynamically initiate LR in the same LMA case (i.e., by sending an
       LRI), but can statically initiate LR based on the
       EnableMAGLocalRouting configuration variable specified in [RFC5213].

          +----+      +----+      +----+          +----+
          |MN1 |      |MN2 |      |MAG1|          |LMA |
          +----+      +----+      +----+          +----+
            |           |           |               |
            |         data          |     data      |
            |<--------------------->|<------------->|
            |           |           |               |
            |           |    data   |     data      |
            |           |<--------->|<------------->|
            |           |           |          LR decision
            |           |           |  LRI(Opt1)    |
            |           |           |<--------------|
            |           |           |               |
            |           |           |  LRA(Opt2)    |
            |           |           |-------------->|
            |           |           |               |
            |        data           |               |
            |<--------------------->|               |
            |           |           |               |
            |           |   data    |               |
            |           |<--------->|               |
            |           |           |               |
            |           |           |               |

          Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
          Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP

          where U is the flag defined in Section 10.2.

                                     Figure 2

    Krishnan, et al.             Standards Track                    [Page 5]

    RFC 6705                PMIPv6 Localized Routing          September 2012

       After detecting a possibility for localized routing, the LMA SHOULD
       construct an LRI message that is used to signal the intent to
       initiate localized routing and to convey parameters for the same.
       This is a Mobility Header message and it MUST contain the MN-
       Identifier (MN-ID) and the Home Network Prefix (HNP) (as Mobility
       Header options) for each of the MNs involved.  The LMA MUST then send
       the LRI message to the MAG (MAG1) where the two MNs are attached.
       The initiation of the LR procedure is shown in Figure 2.

       The MAG (MAG1) MUST verify the attachment status of the two MNs
       locally by checking the binding cache.  The MAG MUST then verify if
       the EnableMAGLocalRouting flag is set to 1.  If it is not, the MAG
       has not been configured to allow localized routing, and it MUST
       reject the LRI and MUST send an LRA with Status code "Localized
       Routing Not Allowed".  Please note that this does not update behavior
       specified in [RFC5213] but merely implements the LMA enforcement
       specified in Section 6.10.3 of [RFC5213].  If the MAG is configured
       to allow localized routing, it MUST then create LREs for each
       direction of the communication between the two MNs.  The exact form
       of the forwarding entries is left for the implementations to decide;
       however, they SHOULD contain the HNP corresponding to the destination
       IP address and a next-hop identifier (e.g., the layer-2 address of
       the next hop).  These LREs MUST override the Binding Update List
       (BUL) entries for the specific HNPs identified in the LRI message.
       Hence, all traffic matching the HNPs is forwarded locally.

       If the MAG is unable to deliver packets using the LREs, it is
       possible that one of the MNs is no longer attached to the MAG.
       Hence, the MAG MUST fall back to using the BUL entry, and the LMA
       MUST forward the received packets using its Binding Cache Entry
       (BCE).

       After processing the LRI message, the MAG MUST respond with a Local
       Routing Acknowledgment (LRA) message.  This Mobility Header message
       MUST also include the MN-ID and the HNP for each of the communicating
       MNs, as well as an appropriate Status code indicating the outcome of
       LRI processing.  Status code 0 indicates localized routing was
       successfully offered by the MAG.  Any other value for Status code
       indicates the reason for the failure to offer localized routing
       service.  When Status code is 0, the LMA sets a flag in the BCE
       corresponding to the HNPs to record that localized routing is in
       progress for that HNP.

    5.1.  Handover Considerations

       If one of the MNs, say MN1, detaches from the MAG and attaches to
       another MAG (say nMAG), the localized routing state needs to be
       re-established. When the LMA receives the PBU from nMAG for MN1, it

    Krishnan, et al.             Standards Track                    [Page 6]

    RFC 6705                PMIPv6 Localized Routing          September 2012

       will see that localized routing is active for MN1.  The LMA MUST
       hence initiate LR at nMAG and update the LR state of pMAG.  After the
       handover completes, LR will resemble Scenario A21.  The pMAG MUST
       follow the forwarding rules described in Section 6.10.5 of [RFC5213]
       and decide that it will no longer perform LR for MN1.

    6.  Scenario A21: Two MNs Attached to Different MAGs but the Same LMA

       The LMA may choose to support local forwarding to Mobile Nodes
       attached to two different MAGs within a single PMIPv6 domain.

                                     Internet
                                        :
                                        |
                                        |
                                     +-----+
                                     | LMA |
                                     +-----+
                                        |
                                        |
                                   +----+-----+
                                   |          |
                                +----+     +----+
                                |MAG1|     |MAG2|
                                +----+     +----+
                                  :           :
                                +---+       +---+
                                |MN1|       |MN2|
                                +---+       +---+

                                     Figure 3

       As earlier, the LMA initiates LR as a response to some trigger
       mechanism.  In this case, however, it MUST send two separate LRI
       messages to the two MAGs.  In addition to the MN-ID and the HNP
       options, each LRI message MUST contain the IP address of the
       counterpart MAG.  When the MAG IP address option is present, each MAG
       MUST create a local forwarding entry such that the packets for the MN
       attached to the remote MAG are sent over a tunnel associated with
       that remote MAG.  The tunnel between the MAGs is assumed to be
       established following the considerations mentioned in Section 6.2.

    Krishnan, et al.             Standards Track                    [Page 7]

    RFC 6705                PMIPv6 Localized Routing          September 2012

          +----+      +----+      +----+      +----+        +----+
          |MN1 |      |MN2 |      |MAG1|      |MAG2|        |LMA |
          +----+      +----+      +----+      +----+        +----+
            |           |           |           |             |
            |        data           |          data           |
            |<--------------------->|<----------------------->|
            |           |           |           |             |
            |           |         data          |    data     |
            |           |<--------------------->|<----------->|
            |           |           |           |             |
            |           |           |           |             |
            |           |           |       LRI(Opt1)         |
            |           |           |<------------------------|
            |           |           |           |             |
            |           |           |           |  LRI(Opt2)  |
            |           |           |           |<------------|
            |           |           |           |             |
            |           |           |        LRA(Opt3)        |
            |           |           |------------------------>|
            |           |           |           |             |
            |           |           |           |   LRA(Opt4) |
            |           |           |           |------------>|
            |           |           |           |             |
            |           |           |           |             |
            |           |           |           |             |
            |        data           |    data   |             |
            |<--------------------->|<--------->|             |
            |           |           |           |             |
            |           |         data          |             |
            |           |<--------------------->|             |
            |           |           |           |             |
            |           |           |           |             |

          Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address
          Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address
          Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address
          Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address

          where U is the flag defined in Section 10.2.

                                     Figure 4

       In this case, each MAG responds to the LRI with an LRA message.  All
       subsequent packets are routed between the MAGs locally, without
       traversing the LMA.  If one of the MAGs (say MAG1) responds with a
       successful LRA (Status value is zero) and the other (say MAG2)

    Krishnan, et al.             Standards Track                    [Page 8]

    RFC 6705                PMIPv6 Localized Routing          September 2012

       responds with an error (Status value is non-zero), LR will still be
       performed in one direction (MN1->MAG1->MAG2->MN2), but the packets
       flowing the other way will take the LMA path
       (MN2->MAG2->LMA->MAG1->MN1).

       The protocol does not require any synchronization between the MAGs
       before local forwarding begins.  Each MAG begins its local forwarding
       independent of the other.

       No synchronization between the MAGs is required because each MAG
       initiates LR in one direction.  After the LMA instructs MAG1 to
       initiate LR, packets from MN1 to MN2 will take the path
       MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path
       MN2->MAG2->LMA->MAG1->MN1 until the LMA instructs MAG2 to initiate LR
       as well.  A MAG will forward a packet towards either another MAG or
       its own LMA; therefore, there would be no duplication of packets.

    6.1.  Handover Considerations

       If one of the MNs, say MN1, detaches from its current MAG (in this
       case MAG1) and attaches to another MAG (say nMAG1), the localized
       routing state needs to be re-established.  When the LMA receives the
       PBU from nMAG1 for MN1, it will see that localized routing is active
       for MN1.  The LMA MUST then initiate LR at nMAG1 and update the LR
       state of MAG2 to use nMAG1 instead of MAG1.

    6.2.  Tunneling between the MAGs

       In order to support localized routing, both MAGs SHOULD support the
       following encapsulation modes for the user packets, which are also
       defined for the tunnel between the LMA and MAG:

       o  IPv4-or-IPv6-over-IPv6 [RFC5844]

       o  IPv4-or-IPv6-over-IPv4 [RFC5844]

       o  IPv4-or-IPv6-over-IPv4-UDP [RFC5844]

       o  TLV-header UDP tunneling [RFC5845]

       o  Generic Routing Encapsulation (GRE) tunneling with or without GRE
          key(s) [RFC5845]

       MAG1 and MAG2 MUST use the same tunneling mechanism for the data
       traffic tunneled between them.  The encapsulation mode to be employed
       SHOULD be configurable.  It is RECOMMENDED that:

    Krishnan, et al.             Standards Track                    [Page 9]

    RFC 6705                PMIPv6 Localized Routing          September 2012

       1.  As the default behavior, the inter-MAG tunnel uses the same
           encapsulation mechanism as that being used for the PMIPv6 tunnel
           between the LMA and the MAGs.  MAG1 and MAG2 automatically start
           using the same encapsulation mechanism without a need for a
           special configuration on the MAGs or a dynamic tunneling
           mechanism negotiation between them.

       2.  Configuration on the MAGs can override the default mechanism
           specified in Option 1 above.  MAG1 and MAG2 MUST be configured
           with the same mechanism, and this configuration is most likely to
           be uniform throughout the PMIPv6 domain.  If the packets on the
           PMIPv6 tunnel cannot be uniquely mapped onto the configured
           inter-MAG tunnel, this scenario is not applicable, and Option 3
           below SHOULD directly be applied.

       3.  An implicit or explicit tunnel negotiation mechanism between the
           MAGs can override the default mechanism specified in Option 1
           above.  The employed tunnel negotiation mechanism is outside the
           scope of this document.

    7.  Scenario A12: Two MNs Attached to the Same MAG with Different LMAs

       In this scenario, both the MNs are attached to the same MAG, but are
       anchored at two different LMAs.  MN1 is anchored at LMA1, and MN2 is
       anchored at LMA2.  Note that the two LMAs are part of the same
       Provider Domain.
                                     Internet
                               :                  :
                               +------------------+
                               |                  |
                            +----+              +----+
                            |LMA1|              |LMA2|
                            +----+              +----+
                               |                  |
                               |                  |
                               +------------------+
                                        |
                                        |
                                        |
                                     +-----+
                                     | MAG |
                                     +-----+
                                      :   :
                                   +---+ +---+
                                   |MN1| |MN2|
                                   +---+ +---+

                                     Figure 5

    Krishnan, et al.             Standards Track                   [Page 10]

    RFC 6705                PMIPv6 Localized Routing          September 2012

       Hence, neither LMA has a means to determine that the two Mobile Nodes
       are attached to the same MAG.  Only the MAG can possibly determine
       that the two Mobile Nodes involved in communication are attached to
       it.  Therefore, localized routing MUST be initiated by the MAG.

       The MAG sends an LRI message containing the MN-ID, HNP, and the
       counterpart LMA address to each LMA.  Each LMA makes a decision to
       support local forwarding independently based on configured policy for
       the corresponding LMA.  Each LMA MUST respond to the LRI message with
       an LRA message.  If the initiation of LR on the LMA was successful,
       the Status value in the received LRA would be set to zero.  After the
       MAG receives both the LRA messages, each with the Status value set to
       zero (success) from the two different LMAs, the MAG will conclude
       that it can provide local forwarding support for the two Mobile
       Nodes.

    Krishnan, et al.             Standards Track                   [Page 11]

    RFC 6705                PMIPv6 Localized Routing          September 2012

          +----+      +----+      +----+      +----+        +----+
          |MN1 |      |MN2 |      |MAG |      |LMA1|        |LMA2|
          +----+      +----+      +----+      +----+        +----+
            |           |           |           |             |
            |        data           |   data    |    data     |
            |<--------------------->|<--------->|<----------->|
            |           |           |           |             |
            |           |   data    |          data           |
            |           |<--------->|<----------------------->|
            |           |           |           |             |
            |           |           |           |             |
            |           |           | LRI(Opt1) |             |
            |           |           |---------->|             |
            |           |           |           |             |
            |           |           |        LRI(Opt2)        |
            |           |           |------------------------>|
            |           |           |           |             |
            |           |           | LRA(Opt3) |             |
            |           |           |<----------|             |
            |           |           |           |             |
            |           |           |        LRA(Opt4)        |
            |           |           |<------------------------|
            |           |           |           |             |
            |           |           |           |             |
            |           |           |           |             |
            |        data           |           |             |
            |<--------------------->|           |             |
            |           |           |           |             |
            |           |    data   |           |             |
            |           |<--------->|           |             |
            |           |           |           |             |
            |           |           |           |             |

          Opt1: MN1-ID,MN1-HNP
          Opt2: MN2-ID,MN2-HNP
          Opt3: U=0,MN1-ID,MN1-HNP
          Opt4: U=0,MN2-ID,MN2-HNP

          where U is the flag defined in Section 10.2.

                                     Figure 6

    7.1.  Handover Considerations

       If one of the MNs, say MN1, detaches from its current MAG (in this
       case MAG1) and attaches to another MAG (say nMAG1), the current MAG
       MUST immediately stop using the LRE and MUST send all packets
       originated by the other MN (MN2) towards its LMA (in this case LMA2).

    Krishnan, et al.             Standards Track                   [Page 12]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    8.  Scenario A22: Two MNs Attached to Different MAGs with Different LMAs

       This scenario will not be covered in this document since PMIPv6 does
       not define any form of inter-LMA communication.  When a supported
       scenario, such as Scenario A12, morphs into Scenario A22, the node
       that initiated the localized routing session MUST tear it down in
       order to prevent lasting packet loss.  This can result in transient
       packet loss when routing switches between the localized path into the
       normal path through the LMAs.  In applications that are loss
       sensitive, this can lead to observable service disruptions.  In
       deployments where Scenario A22 is possible, the use of localized
       routing is NOT RECOMMENDED when packet-loss-sensitive applications
       are in use.

    9.  IPv4 Support in Localized Routing

       PMIPv6 MNs can use an IPv4 Home Address (HoA) as described in
       [RFC5844].  In order to support the setup and maintenance of
       localized routes for these IPv4 HoAs in PMIPv6, the MAGs MUST add the
       IPv4 HoAs into their LREs.  The MAGs MUST also support encapsulation
       of IPv4 packets as described in [RFC5844].  The localized routing
       protocol messages MUST include an IPv4 HoA option in their signaling
       messages in order to support IPv4 addresses for localized routing.

       If the transport network between the PMIPv6 entities involved in
       localized routing is IPv4-only, the LRI and LRA messages MUST be
       encapsulated similar to the PBU/PBA messages as specified in
       [RFC5844].  The encapsulation mode used SHOULD be identical to the
       one used to transport PBU and PBA messages.

    10.  Message Formats

       The localized routing messages use two new Mobility Header types (17
       and 18).  The LRI message requests creation or deletion of the
       localized routing state, and the LRA message acknowledges the
       creation or deletion of such localized routing state.

    Krishnan, et al.             Standards Track                   [Page 13]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    10.1.  Localized Routing Initiation (LRI)

       The LRI messages use a new Mobility Header type (17).  The LMA sends
       an LRI message to a MAG to request local forwarding for a pair of
       MNs.  The MAG may also send this message to request the two LMAs for
       offering local forwarding as described in Section 7.

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

          Sequence Number: A monotonically increasing integer.  Set by a
          sending node in a request message and used to match a reply to the
          request.

          Reserved: This field is unused and MUST be set to zero.

          Lifetime: The requested time, in seconds, for which the sender
          wishes to have local forwarding.  A value of 0xffff (all ones)
          indicates an infinite lifetime.  When set to 0, indicates a
          request to stop localized routing.

          Mobility Options: MUST contain two separate MN-ID options,
          followed by one or more HNPs for each of the MNs.  For instance,
          for Mobile Nodes MN1 and MN2 with identifiers MN1-ID and MN2-ID,
          and Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple
          MUST be present in the following order: [MN1-ID, MN1-HNP],
          [MN2-ID, MN2-HNP].  The MN-ID and HNP options are the same as in
          [RFC5213].  The LRI MAY contain the remote MAG IPv6 address
          option, which is formatted identically to the HNP option, except
          that it uses a different Type code and the Prefix Length is always
          equal to 128 bits (see Section 10.1).

       The LRI message SHOULD be re-transmitted if a corresponding LRA
       message is not received within LRA_WAIT_TIME time units, up to a
       maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units.

    Krishnan, et al.             Standards Track                   [Page 14]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    10.2.  Localized Routing Acknowledgment (LRA)

       The LRA messages use a new Mobility Header type (18).  A MAG sends an
       LRA message to the LMA as a response to the LRI message.  An LMA may
       also send this message to a MAG as a response to the LRI message as
       described in Section 7.

         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
                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        |           Sequence #          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |U|  Reserved   |   Status      |           Lifetime            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                        Mobility options                       .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Sequence Number: Copied from the sequence number field of the LRI
          message being responded to.

           'U' flag: When set to 1, the LRA message is sent unsolicited.

           The Lifetime field indicates a new requested value.  The MAG MUST
           wait for the regular LRI message to confirm that the request is
           acceptable to the LMA.

           Reserved: This field is unused and MUST be set zero.

           Status: 8-bit unsigned integer indicating the result of
           processing the Localized Routing Acknowledgment message.  Values
           of the Status field less than 128 indicate that the Localized
           Routing Acknowledgment was processed successfully by the mobility
           entities(LMA or MAG).  Values greater than or equal to 128
           indicate that the Localized Routing Acknowledgment was rejected
           by the mobility entities.  The following Status values are
           currently defined:

              0: Success
              128: Localized Routing Not Allowed
              129: MN Not Attached

           Lifetime: The time, in seconds, for which local forwarding is
           supported.  It is typically copied from the corresponding field
           in the LRI message.

    Krishnan, et al.             Standards Track                   [Page 15]

    RFC 6705                PMIPv6 Localized Routing          September 2012

           Mobility Options: When Status code is 0, MUST contain the
           [MN-ID, HNP] tuples in the same order as in the LRI message.
           When Status code is not 0, MUST contain only those [MN-ID, HNP]
           tuples for which local forwarding is supported.  The MN-ID and
           HNP options are the same as those described in [RFC5213].

    11.  New Mobility Option

    11.1.  MAG IPv6 Address

       The MAG IPv6 address mobility option contains the IPv6 address of a
       MAG involved in localized routing.  The MAG IPv6 address option has
       an alignment requirement of 8n+4.

         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      |   Reserved    | Address Length|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                       MAG IPv6 Address                        +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type

                51

            Length

                8-bit unsigned integer indicating the length of the option
                in octets, excluding the type and length fields.  This field
                MUST be set to 18.

            Reserved (R)

                This 8-bit field is unused.  The value MUST be initialized
                to 0 by the sender and MUST be ignored by the receiver.

            Address Length

                This field MUST be set to 128.

    Krishnan, et al.             Standards Track                   [Page 16]

    RFC 6705                PMIPv6 Localized Routing          September 2012

            MAG IPv6 Address

                A 16-byte field containing the MAG's IPv6 address.

    12.  Configuration Variables

       The LMA and the MAG must allow the following variables to be
       configurable:

       LRA_WAIT_TIME:  This variable is used to set the time interval, in
          seconds, between successive retransmissions of an LRI message.
          The default value is 3 seconds.

       LRI_RETRIES:  This variable indicates the maximum number of times the
          initiator retransmits an LRI message before stopping.  The default
          value for this variable is 3.

    13.  Security Considerations

       The protocol inherits the threats to [RFC5213] that are identified in
       [RFC4832].  The protocol specified in this document uses the same
       security association as defined in [RFC5213] for use between the LMA
       and the MAG to protect the LRI and LRA messages.  This document also
       assumes the preexistence of a MAG-MAG security association if LR
       needs to be supported between them.  Support for integrity protection
       using IPsec is REQUIRED, but support for confidentiality is OPTIONAL.
       The MAGs MUST perform ingress filtering on the MN-sourced packets
       before encapsulating them into MAG-MAG tunnels in order to prevent
       address spoofing.

    14.  IANA Considerations

       The Localized Routing Initiation (described in Section  10.1) and the
       Localized Routing Acknowledgment (described in Section 10.2) have
       each been assigned a Mobility Header type (17 and 18, respectively)
       from the "Mobility Header Types - for the MH Type field in the
       Mobility Header" registry at
       http://www.iana.org/assignments/mobility-parameters.

       The MAG IPv6 Address has been assigned a Mobility Option type (51)
       from the "Mobility Options" registry at
       http://www.iana.org/assignments/mobility-parameters.

    Krishnan, et al.             Standards Track                   [Page 17]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    15.  Contributors

       This document merges ideas from five different draft documents
       addressing the PMIP localized routing problem.  The authors of these
       drafts are listed below (in alphabetical order).

       Kuntal Chowdhury <kchowdhury@starentnetworks.com>

       Ashutosh Dutta <adutta@niksun.com>

       Rajeev Koodli <rkoodli@starentnetworks.com>

       Suresh Krishnan <suresh.krishnan@ericsson.com>

       Marco Liebsch <marco.liebsch@nw.neclab.eu>

       Paulo Loureiro <loureiro@neclab.eu>

       Desire Oulai <desire.oulai@videotron.com>

       Behcet Sarikaya <sarikaya@ieee.org>

       Qin Wu <sunseawq@huawei.com>

       Hidetoshi Yokota <yokota@kddilabs.jp>

    16.  Acknowledgments

       The authors would like to thank Sri Gundavelli, Julien Abeille, Tom
       Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn,
       Ahmad Muhanna, Zoltan Turanyi, Dirk von Hugo, Pete McCann, Xiansong
       Cui, Carlos Bernardos, Basavaraj Patil, Jari Arkko, Mary Barnes, Les
       Ginsberg, Russ Housley, Carl Wallace, Ralph Droms, Adrian Farrel, and
       Stephen Farrell for their comments and suggestions.

    Krishnan, et al.             Standards Track                   [Page 18]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    17.  References

    17.1.  Normative References

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

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

       [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
                  Mobile IPv6", RFC 5844, May 2010.

       [RFC5845]  Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
                  "Generic Routing Encapsulation (GRE) Key Option for Proxy
                  Mobile IPv6", RFC 5845, June 2010.

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

    17.2.  Informative References

       [RFC4832]  Vogt, C. and J. Kempf, "Security Threats to Network-Based
                  Localized Mobility Management (NETLMM)", RFC 4832, April
                  2007.

       [RFC6279]  Liebsch, M., Ed., Jeong, S., and Q. Wu, "Proxy Mobile IPv6
                  (PMIPv6) Localized Routing Problem Statement", RFC 6279,
                  June 2011.

    Krishnan, et al.             Standards Track                   [Page 19]

    RFC 6705                PMIPv6 Localized Routing          September 2012

    Authors' Addresses

       Suresh Krishnan
       Ericsson
       8400 Blvd Decarie
       Town of Mount Royal, Quebec
       Canada

       Phone: +1 514 345 7900 x42871
       EMail: suresh.krishnan@ericsson.com

       Rajeev Koodli
       Cisco Systems

       EMail: rkoodli@cisco.com

       Paulo Loureiro
       NEC Laboratories Europe
       NEC Europe Ltd.
       Kurfuersten-Anlage 36
       69115 Heidelberg
       Germany

       EMail: loureiro@neclab.eu

       Qin Wu
       Huawei Technologies Co., Ltd.
       101 Software Avenue, Yuhua District
       Nanjing, Jiangsu  21001
       China

       Phone: +86-25-56623633
       EMail: sunseawq@huawei.com

       Ashutosh Dutta
       NIKSUN

       EMail: adutta@niksun.com

    Krishnan, et al.             Standards Track                   [Page 20]