diff options
Diffstat (limited to 'doc/rfc/rfc7148.txt')
| -rw-r--r-- | doc/rfc/rfc7148.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7148.txt b/doc/rfc/rfc7148.txt new file mode 100644 index 0000000..6866ee1 --- /dev/null +++ b/doc/rfc/rfc7148.txt @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) X. Zhou +Request for Comments: 7148 ZTE Corporation +Category: Standards Track J. Korhonen +ISSN: 2070-1721 Broadcom + C. Williams + Consultant + S. Gundavelli + Cisco + CJ. Bernardos + UC3M + March 2014 + + + Prefix Delegation Support for Proxy Mobile IPv6 + +Abstract + + This specification defines extensions to the Proxy Mobile IPv6 + protocol for allowing a mobile router in a Proxy Mobile IPv6 domain + to obtain IP prefixes for its attached mobile networks using DHCPv6 + prefix delegation. Network-based mobility management support is + provided for those delegated IP prefixes just as it is provided for + the mobile node's home address. Even if the mobile router performs a + handoff and changes its network point of attachment, mobility support + is ensured for all the delegated IP prefixes and for all the IP nodes + in the mobile network that use IP address configuration from those + delegated IP prefixes. + +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/rfc7148. + + + + + + + + + + +Zhou, et al. Standards Track [Page 1] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 2] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................6 + 3. Solution Overview ...............................................7 + 3.1. Stated Assumptions .........................................7 + 3.2. Deployment Models ..........................................8 + 3.2.1. Delegating Router Co-located with Mobile + Access Gateway ......................................8 + 3.2.2. Delegating Router Co-located with Local + Mobility Anchor .....................................9 + 3.2.3. Static Configuration of Delegated Mobile + Network Prefixes ...................................12 + 4. Message Formats ................................................12 + 4.1. Delegated Mobile Network Prefix Option ....................12 + 4.2. Status Codes ..............................................14 + 5. Operational Details ............................................14 + 5.1. MAG Considerations ........................................14 + 5.1.1. Extension to Binding Update List Entry Data + Structure ..........................................14 + 5.1.2. Signaling Considerations ...........................14 + 5.1.3. DHCP -- MAG Interactions ...........................16 + 5.1.3.1. Delegating Router Co-located with + Mobile Access Gateway .....................17 + 5.1.3.2. Delegating Router Co-Located with + Local Mobility Anchor .....................18 + 5.1.4. Packet Forwarding ..................................19 + 5.2. LMA Considerations ........................................20 + 5.2.1. Extensions to Binding Cache Entry Data Structure ...20 + 5.2.2. Signaling Considerations ...........................20 + 5.2.3. Packet Forwarding ..................................22 + 5.3. Security Policy Database (SPD) Example Entries ............22 + 6. Security Considerations ........................................23 + 7. IANA Considerations ............................................24 + 8. Acknowledgements ...............................................24 + 9. References .....................................................25 + 9.1. Normative References ......................................25 + 9.2. Informative References ....................................26 + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 3] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +1. Introduction + + Proxy Mobile IPv6 [RFC5213] enables network-based mobility management + support for an IP host without requiring its participation in any IP + mobility signaling. In Proxy Mobile IPv6 (PMIPv6), the mobile access + gateway (MAG) performs the mobility management function on behalf of + the mobile node (MN). The local mobility anchor (LMA) is the home + agent for the MN and the topological anchor point. The mobility + elements (LMA and MAGs) in the network allow an IP host to obtain an + IPv4 address and/or a set of IPv6 addresses and be able to obtain IP + mobility support for those IP address(es) within the Proxy Mobile + IPv6 domain. In this context, the mobility management support is + enabled for an individual IP host, which is the mobile node. The + IPv4 home address or the IPv6 home network prefixes are logically + bound to the link shared between the mobile access gateway and the + mobile node, and only the mobile node can use those IP address(es) by + configuring them on the interface attached to that link. Currently, + there is no mobility support for the mobile networks attached to a + mobile router (MR) in a Proxy Mobile IPv6 domain. + + This specification defines extensions to the Proxy Mobile IPv6 + protocol for allowing mobility support to the mobile networks + attached to a mobile router. These extension include definition of a + new mobility option that can be exchanged in the signaling messages + between the mobile access gateway and the local mobility anchor. The + mobile router can request the mobility entities in the Proxy Mobile + IPv6 domain for delegated IP prefix(es) using DHCP prefix delegation + extensions [RFC3633], static configuration of the prefixes, or + mechanisms specific to the access technology. The mobility entities + in the PMIPv6 network provide network-based mobility management + support for those delegated prefixes just as it is supported for a + home address. The delegated prefixes are hosted in the mobile + network attached to the mobile router. IP mobility is ensured for + all the IP nodes in the mobile network, even as the mobile router + performs a handoff by changing its point of network attachment within + the Proxy Mobile IPv6 domain. The local mobility anchor in the Proxy + Mobile IPv6 domain will not track the individual IP nodes in the + mobile network; it only tracks a single mobile router session that is + hosting the mobile network and associates the delegated IP prefixes + with that session. Although the protocol solution defined in this + specification also allows signaling IPv4 subnets between the mobile + access gateway and the local mobility anchor, the delegation of IPv4 + subnets to the mobile router is out of the scope of this + specification. + + + + + + + +Zhou, et al. Standards Track [Page 4] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + _----_ + +-------+ _( )_ + | |---( Internet ) + | LMA | (_ _) + | | '----' + +-------+ + | + === === === + == Proxy == + == Mobile IPv6 == + == Domain == + === === === + ___________|___________ + | | + +-------+ +-------+ + | MAG | | MAG | + +-------+ +-------+ + . + . + - - - - - - - - + | +------+ | + | | MR | | + | +------+ | + | | | + | ------- | + | | | | + | LFN LFN | + - - - - - - - - + + Figure 1: Mobile Router in Proxy Mobile IPv6 Domain + + Within the context of this document, the definition of a mobile + router extends the definition of a mobile node from [RFC5213] by + adding routing capability between the mobile network and the point of + attachment of the mobile router. Local fixed nodes (LFNs) are IP + nodes in the mobile network; LFNs all move with the mobile router as + a single cluster. As the mobile router moves, the LFNs are not aware + of the mobility of the MR to a new point of attachment. Figure 1 + illustrates a mobile router in a Proxy Mobile IPv6 domain. + + The rest of this document identifies the protocol extensions and the + operational details of the local mobility anchor and mobile access + gateway for realizing prefix delegation support for Proxy Mobile + IPv6. + + + + + + + +Zhou, et al. Standards Track [Page 5] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +2. Terminology + + 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]. + + All the mobility-related terms used in this document are to be + interpreted as defined in Proxy Mobile IPv6 specifications [RFC5213] + and [RFC5844]. All the DHCP-related terms are to be interpreted as + defined in DHCPv6 Prefix Delegation for Network Mobility (NEMO) + [RFC6276], DHCPv6 Prefix Delegation (DHCPv6PD) [RFC3633], and Subnet + Allocation Option for DHCPv4 [RFC6656]. This document also provides + a context-specific explanation of the following terms used here and + originally defined in the Mobile Network terminology document + [RFC4885]. + + Mobile Router (MR) + + The term "mobile router" is used to refer to an IP router whose + mobility is managed by the network while being attached to a Proxy + Mobile IPv6 domain. The mobile router is a mobile node as defined + in [RFC5213] but with additional capabilities for supporting an + attached mobile network. The MR's interface used for attachment + to the mobile access gateway is referred to as the "egress + interface". Any MR's interface used for attachment to the mobile + network is referred to as the "ingress interface". The mobility + entities in the Proxy Mobile IPv6 domain provide mobility for the + IPv4/IPv6 address(es) assigned to the mobile node's egress link + and also mobility support to the network prefixes hosted in the + network attached to the mobile router. + + Mobile Network + + A mobile network is an IP network attached to a mobile router. + There can be many IP nodes in this IP network. The mobile router + is a gateway for these IP nodes for reaching other IP networks or + the Internet. The mobile router and the attached IP networks move + as a single cluster. + + Delegated Mobile Network Prefix (DMNP) + + The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix + delegated to a mobile router and is hosted in the mobile network. + The IP nodes in the mobile network will be able to obtain IP + address configuration from the DMNP and will have IP mobility + support for that address configuration. The DMNP is topologically + anchored on the local mobility anchor, and the mobility elements + + + + +Zhou, et al. Standards Track [Page 6] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + in the Proxy Mobile IPv6 domain provide IP mobility support for + the prefix by forwarding the mobile network traffic to the mobile + router. + + Local Fixed Node (LFN) + + A local fixed node is an IP node in the mobile network. As the + mobile router performs a handoff and changes its network point of + attachment, the local fixed node moves along with the mobile + router. + +3. Solution Overview + + This section lists the stated assumptions and provides an overview of + the operation of this specification. This document references three + different deployment scenarios and explains the protocol operation. + +3.1. Stated Assumptions + + o The mobile router is a mobile node as defined in [RFC5213] but + with additional capabilities for routing IP packets between its + egress interface (interface used for attachment to the mobile + access gateway) and any of its ingress interfaces (interfaces used + for attachment to the mobile network). + + o This specification assumes that a mobile router is an IPv4 and/or + IPv6 router without any capability for mobility management. + + o The mobile router can obtain the delegated IP prefix(es) for its + attached mobile networks using DHCPv6 prefix delegation, static + configuration, or mechanisms specific to access technology. This + document assumes DHCPv6 prefix delegation [RFC3633] in conjunction + with the Prefix Exclude Option [RFC6603] as the default mechanism + for prefix assignment to the mobile node. It defines an + interworking between the mobility entities and the DHCPv6 + functional elements in a non-normative way. The mechanism that + delegates IPv4 subnets to a mobile router is out of the scope of + this specification. + + o The mobile router obtains the IP address configuration for its + egress roaming interface as specified in [RFC5213] and [RFC5844]. + The mobile router, along with its mobile networks, will be able to + perform handoff, change its point of attachment in the network, + and retain IP mobility support. + + o When using DHCPv6 prefix delegation, this document assumes that + the mobile router uses its egress interface when making DHCPv6 + requests. + + + +Zhou, et al. Standards Track [Page 7] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +3.2. Deployment Models + + This section explains the protocol operation used to support prefix + delegation in Proxy Mobile IPv6 for the following three deployment + models: i) delegating router co-located with mobile access gateway, + ii) delegating router co-located with local mobility anchor, and iii) + static configuration of delegated prefixes. High-level message call + flows between the mobile router, mobile access gateway, and the local + mobility anchor are presented while explaining the protocol + operation. + +3.2.1. Delegating Router Co-located with Mobile Access Gateway + + In this deployment scenario, the delegating router (DR) function, as + specified in [RFC3633], is co-located with the mobile access gateway, + and a requesting router (RR) function is enabled on the mobile + router. + + Figure 2 shows the high-level message call flow for this case. The + mobile router attaches to the mobile access gateway, which triggers + the Proxy Mobile IPv6 signaling between the mobile access gateway and + the local mobility anchor, setting up the bidirectional tunnel + between them (regular Proxy Mobile IPv6 registration). After that, + the DHCPv6 requesting router function running on the mobile router + sends a Solicit message requesting a prefix. This message is + received by the DHCPv6 delegating router function running on the + mobile access gateway. The mobile access gateway then sends a Proxy + Binding Update message including a Delegated Mobile Network Prefix + (DMNP) option carrying the ALL_ZERO value [RFC5213]. This serves as + a request for the local mobility anchor to allocate a set of + delegated prefixes, conveyed back in one or more DMNP options in a + Proxy Binding Acknowledgement message. The DHCPv6-PD procedure is + then completed as described in [RFC3633], ending with the delegating + router sending a Reply message conveying the delegated prefixes. If + the requesting router includes a Rapid Commit option in its Solicit + message, it is preferable that the MAG respond directly with a Reply + message rather than with an Advertise message, as described in + [RFC3315], Section 17.2.3. + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 8] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + +-----+ +-----+ +-----+ + | MR | | MAG | | LMA | + |(RR) | | (DR)| | | + +-----+ +-----+ +-----+ + 1) |-- MN Attach -----| | + | |--Proxy Binding Update----->| + | | | + | |<-------Proxy Binding Ack.--| + | | | + | |o==========================o| + 2) | | PMIPv6 tunnel | + | |o==========================o| + 3) |--Solicit for---->| | + | delegated prefix | | + 4) | |--Proxy Binding Update----->| + | | | + 5) | |<--Proxy Binding Ack.(DMNP)-| + | | | + - -<---+ | + 6) |<------Advertise--| | | + | | | | + 7) |--Request-------->| Optional | + | | | | + - -<---+ | + 8) |<---Reply (DMNP)--| | + | | | + + Figure 2: Delegating Router Co-located with Mobile Access Gateway + + From an operational point of view, this is the simplest deployment + option, as it keeps a single protocol interface between the mobile + access gateway and the local mobility anchor. + +3.2.2. Delegating Router Co-located with Local Mobility Anchor + + In this deployment scenario, the delegating router (DR) function, as + specified in [RFC3633], is co-located with the local mobility anchor; + the requesting router (RR) function is enabled on the mobile router; + and a DHCPv6 relay agent (DRA) function is co-located on the mobile + access gateway. + + Figure 3 shows the high-level message call flow for this case. The + mobile router attaches to the mobile access gateway, which triggers + the Proxy Mobile IPv6 signaling between the mobile access gateway and + the local mobility anchor, setting up the bidirectional tunnel + between them (regular Proxy Mobile IPv6 registration). After that, + the DHCPv6 requesting router function running on the mobile router + requests a prefix by sending a Solicit message. This message is + + + +Zhou, et al. Standards Track [Page 9] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + received by the DHCPv6 relay agent function running on the mobile + access gateway, which then completes the DHCPv6 signaling, according + to [RFC3315]. The relay agent function SHOULD include the relay + agent remote-id option [RFC4649] into Relay-forward messages with + appropriate identity information to enable correlation of mobile + router identities used over DHCPv6 and PMIPv6. + + Once the mobile access gateway gets the set of delegated prefixes + from the delegating router function running on the local mobility + anchor, the MAG conveys the delegated prefixes in a Proxy Binding + Update. This ensures that the local mobility anchor properly routes + the traffic addressed to the delegated prefixes via the PMIPv6 tunnel + established with the mobile access gateway and that mobility is + provided to these prefixes while the mobile router roams within the + PMIPv6 domain. Note that the relay agent function in the mobile + access gateway has to queue the Reply message for the duration of the + PMIPv6 signaling (steps 10 and 11) before forwarding the Reply + message to the requesting router. While this does not change + anything from the DHCPv6-PD protocol's point of view, implementations + will need to account for interactions between the timing of PMIPv6 + signaling and the DHCPv6 timeout/retry logic. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 10] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + +-----+ +-----+ +-----+ + | MR | | MAG | | LMA | + |(RR) | |(DRA)| |(DR) | + +-----+ +-----+ +-----+ + 1) |-- MN Attach -----| | + | |--------- PBU ----------->| + | | | + | |<-------- PBA ------------| + | | | + | |o========================o| + 2) | | PMIPv6 tunnel | + | |o========================o| + 3) |-- Solicit for -->| | + | delegated prefix | | + 4) | |--- Solicit ------------->| + - - - <---+ + 5) | |<-- Advertise ------------| | + | | | | + 6) |<- Advertise -----| | | + | | | Optional + 7) |-- Request ------>| | | + | | | | + 8) | |--- Request ------------->| | + - - - <---+ + 9) | |<-- Reply (DMNP) ---------| + | | | + 10) | |----------PBU (DMNP)----->| + | | | + 11) | |<---------PBA (DMNP)------| + | | | + 12) |<-- Reply (DMNP) -| | + | | | + + Figure 3: Delegating Router Co-located with Local Mobility Anchor + + The DR function can also be located in other entities of the home + network aside from the LMA. This deployment model requires some + interworking between the DR and the LMA and is out of the scope of + this specification. Note that this additional interworking would + have no impact on the protocol between the LMA and MAG defined in + this document. + + + + + + + + + + +Zhou, et al. Standards Track [Page 11] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +3.2.3. Static Configuration of Delegated Mobile Network Prefixes + + In this deployment scenario, the DMNPs of the mobile router are + statically configured in the mobile node's policy profile [RFC5213]. + The DMNPs are statically configured in the mobile network attached to + the mobile router. The mobile router is the default-router for the + mobile networks. + + Figure 4 shows a high-level message call flow for this example. The + mobile access gateway obtains statically configured mobile network + prefixes from the policy profile and registers them with the local + mobility anchor using the extensions specified in this document, that + is, the use of the Delegated Mobile Network Prefix (DMNP) option in + the Proxy Mobile IPv6 signaling. There is no explicit trigger from + the mobile router for registering or de-registering those prefixes. + As long as there is a mobility session for the mobile router's home + address, the local mobility anchor enables mobility support for the + mobile network prefixes. + + +-----+ +-----+ +-----+ + | MR | | MAG | | LMA | + | | | | | | + +-----+ +-----+ +-----+ + 1) |-- MN Attach -----| | + 2) | - (Policy Profile) | + | | | + 3) | |--------- PBU (DMNP) ---->| + | | | + 4) | |<-------- PBA (DMNP) -----| + | | | + | |o========================o| + 5) | | PMIPv6 tunnel | + | |o========================o| + | | | + + Figure 4: Static Configuration of Delegated Mobile Network Prefixes + +4. Message Formats + + This section defines extensions to Proxy Mobile IPv6 [RFC5213] + protocol messages. + +4.1. Delegated Mobile Network Prefix Option + + A new mobility header option, the Delegated Mobile Network Prefix + option, is defined for use with Proxy Binding Update and Proxy + Binding Acknowledgement messages exchanged between a local mobility + anchor and a mobile access gateway. This option is used for + + + +Zhou, et al. Standards Track [Page 12] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + exchanging the mobile router's IPv4/IPv6 DMNP. There can be multiple + instances of the Delegated Mobile Network Prefix option present in a + message. + + The Delegated Mobile Network Prefix option has an alignment + requirement of 8n+2. Its format is as follows: + + 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 |V| Reserved | Prefix Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + . . + + IPv4 or IPv6 Delegated Mobile Network Prefix + + | (DMNP) | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 55 + + Length + + 8-bit unsigned integer indicating the length of the option in + octets, excluding the Type and Length fields. + + IPv4 Prefix (V) + + If the IPv4 Prefix (V) flag is set to a value of (1), then it + indicates that the prefix that is included in the DMNP field is an + IPv4 prefix. If the IPv4 Prefix (V) flag is set to a value of + (0), then it indicates that the prefix that is included in the + DMNP field is an IPv6 prefix. + + Reserved + + This field is unused for now. The value MUST be initialized to 0 + by the sender and MUST be ignored by the receiver. + + + + + + + + +Zhou, et al. Standards Track [Page 13] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + Prefix Length + + 8-bit unsigned integer indicating the number of leftmost bits + covering the network part of the address contained in the Prefix + field. + + Delegated Mobile Network Prefix + + Contains a mobile router's 4-byte IPv4 or a 16-byte IPv6 Delegated + Mobile Network Prefix. + +4.2. Status Codes + + This document defines the following new status code values for use in + the Proxy Binding Acknowledgement message. These values have been + allocated from the same number space as defined in Section 6.1.8 of + [RFC6275]. + + NOT_AUTHORIZED_FOR_DELEGATED_MNP: 177 + + Not authorized for DMNP + + REQUESTED_DMNP_IN_USE: 178 + + Requested DMNP is in use + +5. Operational Details + +5.1. MAG Considerations + +5.1.1. Extension to Binding Update List Entry Data Structure + + In order to support this specification, the conceptual Binding Update + List Entry (BULE) data structure [RFC5213] needs to be extended to + include a Delegated Mobile Network Prefix (DMNP) list. Each entry in + the list is used for storing an IPv4/IPv6 mobile network prefix + delegated to the mobile router. + +5.1.2. Signaling Considerations + + During the mobile router's initial attachment procedure, the mobile + access gateway obtains the mobile router's policy profile, as per the + procedures defined in [RFC5213]. The mobile node's policy profile + defined in [RFC5213] is extended to include a parameter that + indicates Delegated Prefix support. If the policy profile indicates + that the mobile router is authorized for Delegated Prefix support, + then the considerations described next apply. + + + + +Zhou, et al. Standards Track [Page 14] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + The mobile access gateway MUST include one or more Delegated Mobile + Network Prefix (DMNP) options in the Proxy Binding Update message in + order to request the local mobility anchor to allocate DMNP(s) for + the mobile router. + + If the mobile access gateway requests the local mobility anchor to + perform the prefix assignment, then: + + o There MUST be exactly one instance of the Delegated Mobile Network + Prefix option with an ALL_ZERO value and with the (V) flag set to + a value of (0). This serves as a request to the local mobility + anchor to allocate a set of IPv6 DMNPs. + + o There MUST be exactly one instance of the Delegated Mobile Network + Prefix option with an ALL_ZERO value and with the (V) flag set to + a value of (1). This serves as a request to the local mobility + anchor to allocate a set of IPv4 DMNP. + + o If the received Proxy Binding Acknowledgement message has the + status field value set to NOT_AUTHORIZED_FOR_DELEGATED_MNP (not + authorized for DMNP), the mobile access gateway MUST NOT enable + mobility support for any of the prefixes in the mobile network, + and prefix delegation support has to be disabled. + + o If the received Proxy Binding Acknowledgement message has the + status field value set to REQUESTED_DMNP_IN_USE (Requested DMNP is + in use), the mobile access gateway MUST NOT enable mobility + support for the requested prefixes. The mobile access gateway MAY + choose to send Proxy Binding Update message requesting the local + mobility anchor to perform the prefix assignment. + + If the mobile access gateway provides the local mobility anchor with + the prefix(es) to be allocated, then: + + o There MUST be exactly one instance of the Delegated Mobile Network + Prefix option with NON_ZERO prefix value [RFC5213] for each of the + mobile network prefixes that the mobile access gateway is + requesting the local mobility anchor to allocate. The prefix + value in the option is the prefix that is either statically + configured for that mobile router in the mobile node's policy + profile or obtained via interactions with the DHCP PD functions. + This serves as a request to the local mobility anchor to allocate + the requested IPv4/IPv6 prefix. + + If the received Proxy Binding Acknowledgement message has the status + field value set to 0 (Proxy Binding Update accepted), the mobile + access gateway has to apply the following considerations. + + + + +Zhou, et al. Standards Track [Page 15] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + o The Delegated Mobile Network Prefix (DMNP) list in the mobile + router's Binding Update List entry has to be updated with the + allocated prefix(es). However, if the received message was in + response to a de-registration request with a lifetime value of + (0), then the DMNP list has to be removed along with the Binding + Update List entry. + + o The mobile access gateway has to set up a policy-based route for + forwarding the IP packets received from the mobile network (with + the source IP address from any of the IPv4/IPv6 DMNPs) through the + bidirectional tunnel set up for that mobile router. However, if + the received message was in response to a de-registration request + with a lifetime value of (0), then the created forwarding state + has to be removed. + + This specification assumes that all the mobile access gateways of a + PMIPv6 domain support the same prefix delegation mechanism. Any + differences will result in DMNPs getting de-registered and the mobile + network losing the prefix(es). This would result in the attached + local fixed nodes losing the assigned IP addresses. The mobile + router MAY explicitly deprecate these prefixes. Alternatively, the + lifetime of the addresses may expire. + +5.1.3. DHCP -- MAG Interactions + + This section describes the interactions between the DHCP and PMIPv6 + logical entities running on the mobile access gateway. This section + is applicable only for deployments that use DHCPv6-based prefix + delegation (i.e., it does not apply if static configuration is used). + As described next, these interactions vary slightly depending on the + considered deployment model at the mobile access gateway (described + in Section 3.2). + + The mobile router, acting as a requesting router as described in + [RFC3633], sends a Solicit message including one or more IA_PD + option(s) to the delegating router / DHCPv6 relay agent co-located on + the mobile access gateway. This message provides the needed trigger + for the mobile access gateway to request the local mobility anchor to + enable DMNP support for that mobility session. We next describe the + subsequent interactions depending on the deployment model. + + + + + + + + + + + +Zhou, et al. Standards Track [Page 16] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +5.1.3.1. Delegating Router Co-located with Mobile Access Gateway + + The mobile access gateway applies the considerations in Section 5.1.2 + for requesting the local mobility anchor to enable delegated prefix + support. For example, if the mobile router is soliciting an IPv4 + prefix, the mobile access gateway includes in the Proxy Binding + Update signaling a Delegated Mobile Network Prefix option with an + ALL_ZERO value and with the (V) flag set to a value of (1). + + The mobile access gateway, upon successfully completing the Proxy + Binding Update signaling with the local mobility anchor (following + the considerations described in Section 5.1.2), adds the DMNPs to the + Binding Update List. Then, the mobile access gateway provides the + obtained prefixes to the DHCPv6 delegating router for prefix + assignment. The way in which these prefixes are passed to the DHCPv6 + delegating router function is beyond the scope of this document. + + o In case the Proxy Binding Update signaling with the local mobility + anchor is not completed successfully, for example, because the + local mobility anchor is not authorized for DMNP or the requested + prefix is in use, the DHCPv6 delegating router will send a Reply + message to the requesting router with no IA_PREFIX suboptions and + with a Status Code option as described in [RFC3633], Section 11.2. + + The standard DHCPv6 considerations will be applied with respect to + the interactions between the delegating router and the requesting + router. The requesting router is provided with the delegated + prefix(es), which can then be then advertised in the mobile network + and therefore used by the local fixed nodes to autoconfigure IP + addresses, allowing them to gain access to the Internet. + + Any time the requesting router releases the delegated prefixes, the + delegating router removes the assigned prefixes. To do so, the + mobile access gateway will send an Updated Proxy Binding Update + following the considerations described in Section 5.1.2 for + de-registering those prefixes. The way in which the DHCPv6 + delegating router triggers the mobile access gateway in order to + de-register the prefixes is beyond the scope of this document. + + In case the mobile router performs a handover and attaches to a + different mobile access gateway, the following cases are possible: + + o The new mobile access gateway does not support the delegation of + mobile network prefixes described in this specification. In this + case, forwarding of the previously DMNPs is no longer performed. + + + + + + +Zhou, et al. Standards Track [Page 17] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + o The new mobile access gateway supports the delegation of mobile + network prefixes described in this specification. There are two + possible cases upon the reception of the Solicit message by the + delegating router. If the MAG already knows the DMNPs, it conveys + them in a DMNP option included in the Proxy Binding Update sent to + the local mobility anchor, which then authorizes them based on: a) + the content of the associated Binding Cache entry (if one exists), + b) the user profile (if the allocation is static), or c) checking + that the DMNPs are not already allocated. On the other hand, if + the mobile access gateway is not aware of the DMNPs, it will + include 0.0.0.0 / :: in a DMNP option included in the Proxy + Binding Update sent to the LMA, which will provide the right + prefixes back in the Proxy Binding Acknowledgement based on a) the + content of the associated Binding Cache entry (if one exits), b) + the profile (if static allocation is used), or c) dynamic + assignment. + +5.1.3.2. Delegating Router Co-Located with Local Mobility Anchor + + A DHCPv6 relay agent function running on the mobile access gateway + will forward the DHCP messages to the local mobility anchor that has + the co-located delegating router function. The requesting router and + the delegating router complete the DHCP messages related to prefix + delegation. + + During the DHCPv6 exchange, the standard DHCPv6 considerations apply + with respect to the interactions between the delegating router, + DHCPv6 relay agent, and requesting router. + + The mobile access gateway learns from the co-located DHCPv6 relay + agent the prefixes allocated by the delegating router. The way in + which the mobile access gateway obtains this information from the + DHCPv6 relay agent function is beyond the scope of this document. + + The mobile access gateway will apply the considerations in + Section 5.1.2 for requesting the local mobility anchor to enable + delegated prefix support. The mobile access gateway will include + exactly one instance of the Delegated Mobile Network Prefix option + with NON_ZERO prefix value for each of the mobile network prefixes + that the mobile access gateway is requesting the local mobility + anchor to allocate. The prefix value(s) in the option will be the + prefix(es) obtained via DHCP prefix delegation. + + The mobile access gateway, upon successfully completing the Proxy + Binding Update signaling with the local mobility anchor, will provide + the obtained prefixes to the DHCPv6 relay agent for prefix + assignment. The delegating router is provided with the delegated + prefix(es) completing the standard DHCPv6 signaling. These prefixes + + + +Zhou, et al. Standards Track [Page 18] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + can then be advertised in the mobile network and therefore used by + the local fixed nodes to autoconfigure IP addresses, allowing them to + gain access to the Internet. + + o In case the Proxy Binding Update signaling with the local mobility + anchor is not completed successfully, for example, because the + local mobility anchor is not authorized for DMNP, the requested + prefix is in use, or the delegated prefix(es) do not match the + ones allocated by DHCP prefix delegation, the DHCPv6 relay agent + MAY send a Reply message to the requesting router with no + IA_PREFIX suboptions and with a Status Code option as described in + [RFC3633], Section 11.2. + + In case the mobile router performs a handover and attaches to a + different mobile access gateway, the following cases are possible: + + o The new mobile access gateway does not support the delegation of + mobile network prefixes described in this specification. In this + case, forwarding of the previously delegated mobile network + prefixes is no longer performed. + + o The new mobile access gateway supports the delegation of mobile + network prefixes described in this specification. There are two + possible cases upon the reception of the Solicit message by the + DHCPv6 relay agent. If the MAG already knows the DMNPs, it + conveys them in a DMNP option included in the Proxy Binding Update + sent to the local mobility anchor, which then authorizes them + based on: a) the content of the associated Binding Cache entry (if + one exists), b) the user profile (if the allocation is static), or + c) checking that the DMNPs are not already allocated. On the + other hand, if the mobile access gateway is not aware of the + DMNPs, it will include 0.0.0.0 / :: in a DMNP option included in + the Proxy Binding Update sent to the LMA, which will provide the + right prefixes back in the Proxy Binding Acknowledgement based on + a) the content of the associated Binding Cache entry (if one + exits), b) the profile (if static allocation is used), or c) + dynamic assignment. + +5.1.4. Packet Forwarding + + On receiving an IP packet from a mobile router, the mobile access + gateway MUST ensure, before tunneling the packet to the local + mobility anchor, that there is an established binding for the mobile + router and that the source IP address of the packet is a prefix + delegated to that mobile router. If the source address of the + received IP packet is not part of the DMNP, then the mobile access + gateway MUST NOT tunnel the packet to the local mobility anchor. + + + + +Zhou, et al. Standards Track [Page 19] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + On receiving an IP packet from the bidirectional tunnel established + with the local mobility anchor, the mobile access gateway MUST first + decapsulate the packet (remove the outer header) and then use the + destination address of the (inner) packet to forward it on the + interface through which the mobile router is reachable. + + The above forwarding considerations are not applicable to the IP + traffic sent/received to/from the mobile router's home address (IPv4 + HoA / Home Network Prefix (HNP)). For the mobile router's home + address traffic, forwarding considerations from [RFC5213] and + [RFC5844] continue to apply. + +5.2. LMA Considerations + +5.2.1. Extensions to Binding Cache Entry Data Structure + + In order to support this specification, the conceptual Binding Cache + entry (BCE) data structure [RFC5213] needs to be extended to include + the Delegated Mobile Network Prefix (DMNP) list. Each entry in the + list represents a DMNP. + +5.2.2. Signaling Considerations + + If the Proxy Binding Update message does not include any Delegated + Mobile Network Prefix option(s) (Section 4.1), then the local + mobility anchor MUST NOT enable Delegated Prefix support for the + mobility session, and the Proxy Binding Acknowledgement message that + is sent in response MUST NOT contain any Delegated Mobile Network + Prefix option(s). + + If the Proxy Binding Update message includes one or more Delegated + Mobile Network Prefix options, but the local mobility anchor is not + configured with Delegated Prefix support, then the local mobility + anchor will ignore the option(s) and process the rest of the option + as specified in [RFC5213]. This would have no effect on the + operation of the rest of the protocol. The Proxy Binding + Acknowledgement message that is sent in response will not include any + Delegated Mobile Network Prefix option(s). + + If the Proxy Binding Update message has the Delegated Mobile Network + Prefix option(s) and if the local mobility anchor is configured for + Delegated Prefix support, then the local mobility anchor MUST enable + the Delegated Mobile Network Prefix option for that mobility session. + The Proxy Binding Acknowledgement message that is sent in response + MUST include the Delegated Mobile Network Prefix option(s). The + following considerations apply. + + + + + +Zhou, et al. Standards Track [Page 20] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + o If there is at least one instance of the Delegated Mobile Network + Prefix option with an ALL_ZERO [RFC5213] prefix value, then this + serves as a request for the local mobility anchor to perform the + assignment of one or more DMNPs. + + * A Delegated Mobile Network option with an ALL_ZERO value and + with the (V) flag set to a value of (0) is a request for the + local mobility anchor to allocate one or more IPv6 prefixes. + + * A Delegated Mobile Network option with an ALL_ZERO value and + with the (V) flag set to a value of (1) is a request for the + local mobility anchor to allocate one or more IPv4 prefixes. + + * Inclusion of multiple instances of Delegated Mobile Network + options with ALL_ZERO values, one with the (V) flag set to a + value of (1) and another instance with the (V) flag set to a + value of (0), is a request to allocate both IPv4 and IPv6 + prefixes. + + o If there are no instances of the Delegated Mobile Network Prefix + option present in the request with an ALL_ZERO value but a + specific prefix value exists, then this serves as a request for + the local mobility anchor to perform the allocation of the + requested prefix(es). + + * If any one of the requested prefixes are assigned to some other + mobility node, or not from an authorized pool that the local + mobility can allocate for that mobility session, then the Proxy + Binding Update MUST be rejected by sending a Proxy Binding + Acknowledgement message with the Status field set to + REQUESTED_DMNP_IN_USE (Requested DMNP is in use). + + Upon accepting the Proxy Binding Update, the local mobility anchor + MUST send a Proxy Binding Acknowledgement message with the Status + field set to 0 (Proxy Binding Update accepted). + + o The message MUST include one instance of the Delegated Mobile + Network Prefix option for each of the allocated IPv4/IPv6 DMNPs. + + o The Delegated Mobile Network Prefix (DMNP) list in the mobile + router's Binding Cache entry has to be updated with the allocated + prefix(es). However, if the request is a de-registration request + with a lifetime value of (0), the DMNP list has to be removed + along with the Binding Cache entry. + + + + + + + +Zhou, et al. Standards Track [Page 21] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + o A route (or a platform-specific equivalent function that sets up + the forwarding) for each of the allocated prefixes over the tunnel + has to be added. However, if the request is a de-registration + request, with a lifetime value of (0), all the IPv4/IPv6 delegated + prefix routes created for that session have to be removed. + +5.2.3. Packet Forwarding + + The local mobility anchor MUST advertise a connected route into the + routing infrastructure for the IP prefixes delegated to all of the + mobile routers that it is serving. This step essentially enables the + local mobility anchor to be a routing anchor for those IP prefixes + and be able to intercept IP packets sent to those mobile networks. + + On receiving a packet from a correspondent node with the destination + address matching any of the mobile router's DMNPs, the local mobility + anchor MUST forward the packet through the bidirectional tunnel set + up with the mobile access gateway where the mobile router is + attached. + + On receiving an IP packet from the bidirectional tunnel established + with the mobile access gateway, the local mobility anchor MUST first + decapsulate the packet (remove the outer header) and then use the + destination address of the (inner) packet for forwarding decisions. + The local mobility anchor MUST ensure that there is an established + binding for the mobile router and that the source IP address of the + packet is a prefix delegated to a mobile router reachable over that + bidirectional tunnel. + + The above forwarding considerations are not applicable to the IP + traffic sent/received to/from the mobile router's home address (IPv4 + HoA/HNP). For the mobile router's home address traffic, forwarding + considerations from [RFC5213] and [RFC5844] continue to apply. + +5.3. Security Policy Database (SPD) Example Entries + + The use of DHCPv6, as described in this document, requires message + integrity protection and source authentication. The IPsec security + mechanism used by Proxy Mobile IPv6 [RFC5213] for securing the + signaling messages between the mobile access gateway and the local + mobility anchor can be used for securing the DHCP signaling between + the mobile access gateway and the local mobility anchor. + + The Security Policy Database (SPD) and Security Association Database + (SAD) entries necessary to protect the DHCP signaling is specified + below. The format of these entries is based on [RFC4877] + conventions. The SPD and SAD entries are only example + configurations. A particular implementation of mobile access gateway + + + +Zhou, et al. Standards Track [Page 22] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + and local mobility anchor implementation can configure different SPD + and SAD entries as long as they provide the required security for + protecting DHCP signaling messages. + + For the examples described in this document, a mobile access gateway + with address "mag_address_1" and a local mobility anchor with address + "lma_address_1" are assumed. + + mobile access gateway SPD-S: + - IF local_address = mag_address_1 & + remote_address = lma_address_1 & proto = UDP & + local_port = any & remote_port = DHCP + Then use SA1 (OUT) and SA2 (IN) + + mobile access gateway SAD: + - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT): + local_address = mag_address_1 & + remote_address = lma_address_1 & + proto = UDP & remote_port = DHCP + - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT): + local_address = lma_address_1 & + remote_address = mag_address_1 & + proto = UDP & local_port = DHCP + + local mobility anchor SPD-S: + - IF local_address = lma_address_1 & + remote_address = mag_address_1 & proto = UDP & + local_port = DHCP & remote_port = any + Then use SA2 (OUT) and SA1 (IN) + + local mobility anchor SAD: + - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT): + local_address = lma_address_1 & + remote_address = mag_address_1 & + proto = UDP & local_port = DHCP + - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT): + local_address = mag_address_1 & + remote_address = lma_address_1 & + proto = UDP & remote_port = DHCP + +6. Security Considerations + + The Delegated Mobile Network Prefix option defined in this + specification is for use in Proxy Binding Update and Proxy Binding + Acknowledgement messages. This option is carried like any other + mobility header option as specified in [RFC5213]. Therefore, it + inherits from [RFC5213] its security guidelines and does not require + any additional security considerations. + + + +Zhou, et al. Standards Track [Page 23] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + + The use of DHCPv6 in this specification is as defined in the DHCPv6 + base specification [RFC3315] and DHCPv6 prefix delegation + specification [RFC3633]. The security considerations specified in + those specifications apply to this document. + + If IPsec is used, the IPsec security association that is used for + protecting the Proxy Binding Update and Proxy Binding Acknowledgement + also needs to be used for protecting the DHCPv6 signaling between the + mobile access gateway and the local mobility anchor. Considerations + specified in Section 5.3 identify the extensions to security policy + entries [RFC4301] + +7. IANA Considerations + + o This specification defines a new mobility header option, the + Delegated Mobile Network Prefix option. This mobility option is + described in Section 4.1. The type value 55 for this message has + been allocated from the "Mobility Options" registry at http:// + www.iana.org/assignments/mobility-parameters. + + o This document also defines two new status code values for use in + the Proxy Binding Acknowledgement message, as described in + Section 4.2. These status codes are + NOT_AUTHORIZED_FOR_DELEGATED_MNP (not authorized for DMNP) with a + status code value of 177 and REQUESTED_DMNP_IN_USE (Requested DMNP + is in use) with a status code value of 178. These values have + been assigned from the same number space as allocated for other + status codes [RFC6275]. + +8. Acknowledgements + + The authors would like to acknowledge Ryuji Wakikawa, Alexandru + Petrescu, Behcet Sarikaya, Seil Jeon, Basavaraj Patil, Brian + Haberman, and Michal Hoeft for all the discussions and reviews of + this document. + + The work of Carlos J. Bernardos has also been partially supported by + the European Community's Seventh Framework Programme (FP7-ICT-2009-5) + under grant agreement n. 258053 (MEDIEVAL project) and by the + Ministry of Science and Innovation of Spain under the QUARTET project + (TIN2009-13992-C02-01). + + + + + + + + + + +Zhou, et al. Standards Track [Page 24] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +9. References + +9.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. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August + 2006. + + [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with + IKEv2 and the Revised IPsec Architecture", RFC 4877, April + 2007. + + [RFC5213] Gundavelli, S., 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. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + + [RFC6276] Droms, R., Thubert, P., Dupont, F., Haddad, W., and C. + Bernardos, "DHCPv6 Prefix Delegation for Network Mobility + (NEMO)", RFC 6276, July 2011. + + [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, + "Prefix Exclude Option for DHCPv6-based Prefix + Delegation", RFC 6603, May 2012. + + + + + + + + + +Zhou, et al. Standards Track [Page 25] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +9.2. Informative References + + [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support + Terminology", RFC 4885, July 2007. + + [RFC6656] Johnson, R., Kinnear, K., and M. Stapp, "Description of + Cisco Systems' Subnet Allocation Option for DHCPv4", RFC + 6656, July 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhou, et al. Standards Track [Page 26] + +RFC 7148 Prefix Delegation Support for PMIPv6 March 2014 + + +Authors' Addresses + + Xingyue Zhou + ZTE Corporation + No.50 Software Avenue, Yuhuatai District + Nanjing + China + + Phone: +86-25-8801-4634 + EMail: zhou.xingyue@zte.com.cn + + + Jouni Korhonen + Broadcom + Porkkalankatu 24 + Helsinki FIN-00180 + Finland + + EMail: jouni.nospam@gmail.com + + + Carl Williams + Consultant + San Jose, CA + USA + + EMail: carlw@mcsr-labs.org + + + Sri Gundavelli + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: sgundave@cisco.com + + + Carlos J. Bernardos + Universidad Carlos III de Madrid + Av. Universidad, 30 + Leganes, Madrid 28911 + Spain + + Phone: +34 91624 6236 + EMail: cjbc@it.uc3m.es + URI: http://www.it.uc3m.es/cjbc/ + + + + +Zhou, et al. Standards Track [Page 27] + |