summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6705.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6705.txt')
-rw-r--r--doc/rfc/rfc6705.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc6705.txt b/doc/rfc/rfc6705.txt
new file mode 100644
index 0000000..31adbde
--- /dev/null
+++ b/doc/rfc/rfc6705.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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]
+