RFC 7148
Prefix Delegation Support for Proxy Mobile IPv6
RFC 7148: Prefix Delegation Support for Proxy Mobile IPv6 🎀
okay bestie, this is RFC 7148 💖 It's called "Prefix Delegation Support for Proxy Mobile IPv6" and it was written by X. Zhou (ZTE Corporation), J. Korhonen (Broadcom), C. Williams (Consultant), S. Gundavelli (Cisco), and CJ. Bernardos (UC3M). It's a Standards Track document, dated March 2014, with ISSN 2070-1721. The header doesn't list any Obsoletes or Updates, so it isn't replacing or patching another RFC. 🦋
Abstract ✨
okay so this spec adds extensions to Proxy Mobile IPv6 so a mobile router in a PMIPv6 domain can grab IP prefixes for the mobile networks it's carrying, using DHCPv6 prefix delegation. 🧚 Network-based mobility management covers those delegated prefixes just like it covers the mobile node's home address. Even if the mobile router hands off and changes where it's attached, mobility support is kept for all the delegated prefixes and for every IP node in the mobile network that configures addresses from them. ✨
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 had public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741. 💅
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7148. 🌸
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 read these carefully, because they spell out 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 they come without warranty, as described in the Simplified BSD License. 🫶
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 ....................................261. Introduction ✨
okay so Proxy Mobile IPv6 [RFC5213] gives network-based mobility management to an IP host without making it take part in any IP mobility signaling at all. 🦋 In PMIPv6, the mobile access gateway (MAG) does the mobility management work on behalf of the mobile node (MN). The local mobility anchor (LMA) is the home agent for the MN and its topological anchor point. Together, the LMA and MAGs in the network let an IP host get an IPv4 address and/or a set of IPv6 addresses and keep IP mobility support for those addresses inside the Proxy Mobile IPv6 domain. The mobility management support is enabled for one 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 addresses by configuring them on the interface attached to that link. Right now, there's 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 so mobility support can reach the mobile networks attached to a mobile router. 💖 These extensions include 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 ask 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 like they do 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 when the mobile router hands off by changing its point of network attachment within the Proxy Mobile IPv6 domain. 🌈 The local mobility anchor in the Proxy Mobile IPv6 domain won't track the individual IP nodes in the mobile network. It only tracks a single mobile router session that hosts the mobile network, and it associates the delegated IP prefixes with that session. Although the protocol solution defined here also allows signaling IPv4 subnets between the mobile access gateway and the local mobility anchor, delegating IPv4 subnets to the mobile router is out of scope for this specification. 🙈
_----_
+-------+ _( )_
| |---( Internet )
| LMA | (_ _)
| | '----'
+-------+
|
=== === ===
== Proxy ==
== Mobile IPv6 ==
== Domain ==
=== === ===
___________|___________
| |
+-------+ +-------+
| MAG | | MAG |
+-------+ +-------+
.
.
- - - - - - - -
| +------+ |
| | MR | |
| +------+ |
| | |
| ------- |
| | | |
| LFN LFN |
- - - - - - - -Figure 1: Mobile Router in Proxy Mobile IPv6 Domain
Within 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 mobile router's point of attachment. 🧚 Local fixed nodes (LFNs) are IP nodes in the mobile network, and they all move with the mobile router as a single cluster. As the mobile router moves, the LFNs aren't aware that the MR has moved to a new point of attachment. Figure 1 shows 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. 💅
2. Terminology ✨
okay bestie, let's get the vocab down first 💅 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 are to be read the way they're defined in the Proxy Mobile IPv6 specs, [RFC5213] and [RFC5844]. All the DHCP-related terms are to be read the way they're 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 gives a context-specific explanation of the following terms, which were originally defined in the Mobile Network terminology document [RFC4885]. 🦋
Mobile Router (MR)
The term "mobile router" refers to an IP router whose mobility is managed by the network while it's attached to a Proxy Mobile IPv6 domain. The mobile router is a mobile node as defined in [RFC5213], but with extra abilities for supporting an attached mobile network. The MR's interface used for attaching to the mobile access gateway is called the "egress interface". Any MR interface used for attaching to the mobile network is called 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 they also give 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 lots of IP nodes in this IP network. The mobile router is a gateway for these IP nodes to reach 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 that is hosted in the mobile network. The IP nodes in the mobile network can get IP address configuration from the DMNP, and they'll have IP mobility support for that address configuration. The DMNP is topologically anchored on the local mobility anchor, and the mobility elements 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. When the mobile router does 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 gives an overview of how this specification works. This document references three different deployment scenarios and explains the protocol operation. 💖
3.1. Stated Assumptions
- The mobile router is a mobile node as defined in [RFC5213], but with extra abilities for routing IP packets between its egress interface (the interface used for attaching to the mobile access gateway) and any of its ingress interfaces (the interfaces used for attaching to the mobile network). 👑
- This specification assumes that a mobile router is an IPv4 and/or IPv6 router without any capability for mobility management. 🫶
- The mobile router can get the delegated IP prefix(es) for its attached mobile networks using DHCPv6 prefix delegation, static configuration, or mechanisms specific to the access technology. This document assumes DHCPv6 prefix delegation [RFC3633] together 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 scope for this specification. 🍓
- The mobile router gets 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 do a handoff, change its point of attachment in the network, and keep IP mobility support. ✨
- When using DHCPv6 prefix delegation, this document assumes that the mobile router uses its egress interface when making DHCPv6 requests. 🔥
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 shown while the protocol operation is explained. 🦋
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, which are 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. 🎀
+-----+ +-----+ +-----+
| 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 GatewayFrom an operational point of view, this is the simplest deployment option, because 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 🦋
okay bestie, so in this setup the delegating router (DR) function from [RFC3633] lives on the local mobility anchor, the requesting router (RR) function runs on the mobile router, and a DHCPv6 relay agent (DRA) function is co-located on the mobile access gateway 💅
Figure 3 shows the call flow. When the mobile router attaches to the mobile access gateway, that triggers the Proxy Mobile IPv6 signaling between the mobile access gateway and the local mobility anchor, and the bidirectional tunnel between them gets set up (regular Proxy Mobile IPv6 registration) ✨ After that, the DHCPv6 requesting router function on the mobile router asks for a prefix by sending a Solicit message. The DHCPv6 relay agent function on the mobile access gateway receives it and finishes the DHCPv6 signaling according to [RFC3315]. The relay agent function SHOULD include the relay agent remote-id option [RFC4649] in Relay-forward messages, with appropriate identity information, so that mobile router identities used over DHCPv6 and PMIPv6 can be correlated 🫶
Once the mobile access gateway gets the set of delegated prefixes from the delegating router function on the local mobility anchor, it sends those delegated prefixes along in a Proxy Binding Update. This way the local mobility anchor routes traffic addressed to the delegated prefixes through the PMIPv6 tunnel with the mobile access gateway, and those prefixes keep getting mobility support while the mobile router roams inside the PMIPv6 domain 🌸 One thing to note: the relay agent function in the mobile access gateway has to hold the Reply message for the whole PMIPv6 signaling (steps 10 and 11) before it forwards the Reply to the requesting router. This doesn't change anything from the DHCPv6-PD protocol's point of view, but implementations will need to handle how the timing of PMIPv6 signaling interacts with the DHCPv6 timeout/retry logic 😭
+-----+ +-----+ +-----+
| 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 live in other entities on the home network besides the LMA 👑 That deployment model needs some interworking between the DR and the LMA, and it is out of the scope of this specification. Note that this extra interworking would have no impact on the protocol between the LMA and MAG defined in this document ✨
3.2.3. Static Configuration of Delegated Mobile Network Prefixes 🧚
in this one the DMNPs of the mobile router are statically configured in the mobile node's policy profile [RFC5213] 💖 They're statically configured in the mobile network attached to the mobile router, and the mobile router is the default-router for those mobile networks.
Figure 4 shows the call flow. The mobile access gateway grabs the statically configured mobile network prefixes from the policy profile and registers them with the local mobility anchor, using the extensions in this document. That means the Delegated Mobile Network Prefix (DMNP) option goes in the Proxy Mobile IPv6 signaling. There's no explicit trigger from the mobile router for registering or de-registering those prefixes. As long as there's a mobility session for the mobile router's home address, the local mobility anchor keeps enabling 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
okay so there's a brand new mobility header option, the Delegated Mobile Network Prefix option 🦋 It's used with Proxy Binding Update and Proxy Binding Acknowledgement messages that get swapped between a local mobility anchor and a mobile access gateway. The option carries the mobile router's IPv4/IPv6 DMNP, and you can have multiple instances of it in one message 🔥
The Delegated Mobile Network Prefix option has an alignment requirement of 8n+2. Here's the format:
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) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means:
Type: the value is55🍓Length: an 8-bit unsigned integer giving the length of the option in octets, not counting the Type and Length fields.IPv4 Prefix (V): if this flag is set to1, the prefix in the DMNP field is an IPv4 prefix. If it's set to0, the prefix in the DMNP field is an IPv6 prefix.Reserved: unused for now. The sender MUST initialize this to0, and the receiver MUST ignore it 🙈Prefix Length: an 8-bit unsigned integer giving the number of leftmost bits that cover the network part of the address in the Prefix field.Delegated Mobile Network Prefix: holds a mobile router's 4-byte IPv4 or 16-byte IPv6 Delegated Mobile Network Prefix.
4.2. Status Codes
this document defines two new status code values for the Proxy Binding Acknowledgement message. They're allocated from the same number space 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 use5. Operational Details 💖
5.1. MAG Considerations ✨
5.1.1. Extension to Binding Update List Entry Data Structure 🌸
okay so to support this spec, 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 that list stores an IPv4/IPv6 mobile network prefix delegated to the mobile router 🫶
5.1.2. Signaling Considerations ✨
Okay so bestie, during the mobile router's initial attachment, the mobile access gateway grabs the mobile router's policy profile, the way [RFC5213] lays it out 💅. That policy profile from [RFC5213] gets extended with a parameter that says whether Delegated Prefix support is on 🎀. If the profile says the mobile router is authorized for Delegated Prefix support, then everything below applies 🫶
The mobile access gateway MUST include one or more Delegated Mobile Network Prefix (DMNP) options in the Proxy Binding Update message so it can ask the local mobility anchor to allocate DMNP(s) for the mobile router 🦋
If the mobile access gateway wants the local mobility anchor to do the prefix assignment, then:
- There MUST be exactly one instance of the Delegated Mobile Network Prefix option with an
ALL_ZEROvalue and with the(V)flag set to a value of(0). This is basically the request saying "hey LMA, please give me a set of IPv6 DMNPs" 🧚 - There MUST be exactly one instance of the Delegated Mobile Network Prefix option with an
ALL_ZEROvalue and with the(V)flag set to a value of(1). This is the request for a set of IPv4 DMNP 🌸 - If the received Proxy Binding Acknowledgement message has the
statusfield value set toNOT_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 💀 - If the received Proxy Binding Acknowledgement message has the
statusfield value set toREQUESTED_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 a Proxy Binding Update message asking the local mobility anchor to perform the prefix assignment 🙈
If the mobile access gateway gives the local mobility anchor the prefix(es) to be allocated, then:
- There MUST be exactly one instance of the Delegated Mobile Network Prefix option with a
NON_ZEROprefix value [RFC5213] for each of the mobile network prefixes that the mobile access gateway is asking 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 through interactions with the DHCP PD functions. This is the request for 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.
- 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
lifetimevalue of(0), then the DMNP list has to be removed along with the Binding Update List entry 👑 - 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
lifetimevalue 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). That would mean the attached local fixed nodes lose their 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 is about the interactions between the DHCP and PMIPv6 logical entities running on the mobile access gateway. It only applies to deployments that use DHCPv6-based prefix delegation (so it doesn't apply if static configuration is used) 🎀 As described next, these interactions vary a little depending on the deployment model at the mobile access gateway (described in Section 3.2).
The mobile router is acting as a requesting router, as described in [RFC3633]. It 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 is the trigger that gets the mobile access gateway to ask the local mobility anchor to enable DMNP support for that mobility session 🦋 Here's how the subsequent interactions go, depending on the deployment model.
5.1.3.1. Delegating Router Co-located with Mobile Access Gateway 💅
The mobile access gateway applies the considerations in Section 5.1.2 to ask 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 a Delegated Mobile Network Prefix option with an ALL_ZERO value and with the (V) flag set to a value of (1) in the Proxy Binding Update signaling 🌸
Once the Proxy Binding Update signaling with the local mobility anchor is complete (following the considerations described in Section 5.1.2), the mobile access gateway adds the DMNPs to the Binding Update List. Then it hands the obtained prefixes to the DHCPv6 delegating router for prefix assignment. How those prefixes get passed to the DHCPv6 delegating router function is beyond the scope of this document 🫶
- If 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 apply to the interactions between the delegating router and the requesting router. The requesting router gets the delegated prefix(es), which it can then advertise in the mobile network. That way the local fixed nodes can autoconfigure IP addresses and get access to the Internet 🌈
Any time the requesting router releases the delegated prefixes, the delegating router removes the assigned prefixes. To do that, the mobile access gateway sends an Updated Proxy Binding Update, following the considerations described in Section 5.1.2 for de-registering those prefixes. How the DHCPv6 delegating router triggers the mobile access gateway to de-register the prefixes is beyond the scope of this document ✨
If the mobile router does a handover and attaches to a different mobile access gateway, these cases are possible:
- The new mobile access gateway does not support the delegation of mobile network prefixes described in this specification. In this case, forwarding of the previous DMNPs is no longer performed 💀
- The new mobile access gateway does support the delegation of mobile network prefixes described in this specification. There are two possible cases when the delegating router receives the Solicit message. If the MAG already knows the DMNPs, it puts 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 isn't aware of the DMNPs, it includes
0.0.0.0 / ::in a DMNP option in the Proxy Binding Update sent to the LMA. The LMA then provides the right prefixes back in the Proxy Binding Acknowledgement based on: a) the content of the associated Binding Cache entry (if one exists), b) the profile (if static allocation is used), or c) dynamic assignment 👑
5.1.3.2. Delegating Router Co-Located with Local Mobility Anchor ✨
okay so the DHCPv6 relay agent running on the mobile access gateway 🦋 forwards the DHCP messages to the local mobility anchor, which is where the co-located delegating router function lives. the requesting router and the delegating router then finish the DHCP messages related to prefix delegation 💅
During the DHCPv6 exchange, the standard DHCPv6 considerations apply to how the delegating router, DHCPv6 relay agent, and requesting router interact 🎀
the mobile access gateway learns the prefixes that the delegating router allocated from the co-located DHCPv6 relay agent 👀 how it gets that info from the relay agent function is beyond the scope of this document 🙈
the mobile access gateway will follow the considerations in Section 5.1.2 when it asks the local mobility anchor to turn on delegated prefix support 💖 it includes exactly one instance of the Delegated Mobile Network Prefix option with a NON_ZERO prefix value for each mobile network prefix it wants the local mobility anchor to allocate, and the prefix values in those options are the prefixes it got through DHCP prefix delegation 🌸
once the Proxy Binding Update signaling with the local mobility anchor works out, the mobile access gateway hands the obtained prefixes to the DHCPv6 relay agent for prefix assignment ✨ the delegating router gets the delegated prefixes through the usual DHCPv6 signaling 🧚 then those prefixes can get advertised in the mobile network, so the local fixed nodes can autoconfigure their IP addresses and get on the Internet 🌈
- If the Proxy Binding Update signaling with the local mobility anchor does not complete 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_PREFIXsuboptions and with a Status Code option as described in [RFC3633], Section 11.2. 🙅♀️
in case the mobile router does a handover and attaches to a different mobile access gateway, these cases are possible 🦋
- 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. 💀
- The new mobile access gateway supports the delegation of mobile network prefixes described in this specification. There are two possible cases when the DHCPv6 relay agent receives the Solicit message. If the MAG already knows the DMNPs, it puts them in a DMNP option included in the Proxy Binding Update sent to the local mobility anchor, and the local mobility anchor 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 includes
0.0.0.0 / ::in a DMNP option included in the Proxy Binding Update sent to the LMA, and the LMA provides 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 make sure, 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. 🚫
on receiving an IP packet from the bidirectional tunnel set up 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 the mobile router is reachable through 🧚
the forwarding considerations above do not apply to IP traffic sent to or from the mobile router's home address (IPv4 HoA / Home Network Prefix (HNP)). for the mobile router's home address traffic, the forwarding considerations from [RFC5213] and [RFC5844] still apply 💜
5.2. LMA Considerations 👑
5.2.1. Extensions to Binding Cache Entry Data Structure 🌸
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 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 message as specified in [RFC5213]. this has no effect on the rest of the protocol. the Proxy Binding Acknowledgement message 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 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 sent in response MUST include the Delegated Mobile Network Prefix option(s). the following considerations apply 💅
- 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 assign one or more DMNPs.- A Delegated Mobile Network option with an
ALL_ZEROvalue 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_ZEROvalue 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. 🌈 - Including multiple instances of Delegated Mobile Network options with
ALL_ZEROvalues, one with the (V) flag set to a value of (1) and another with the (V) flag set to a value of (0), is a request to allocate both IPv4 and IPv6 prefixes. 👑
- A Delegated Mobile Network option with an
- If there are no instances of the Delegated Mobile Network Prefix option in the request with an
ALL_ZEROvalue, but a specific prefix value exists, then this serves as a request for the local mobility anchor to allocate the requested prefix(es). 🎀- If any one of the requested prefixes is assigned to some other mobility node, or is 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). 😭
- If any one of the requested prefixes is assigned to some other mobility node, or is 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
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) ✨
- The message MUST include one instance of the Delegated Mobile Network Prefix option for each of the allocated IPv4/IPv6 DMNPs. 🧚
- 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. 🍓 - 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 it is serving. this basically makes the local mobility anchor a routing anchor for those IP prefixes, so it can catch IP packets headed to those mobile networks 🦋
on receiving a packet from a correspondent node with a 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 make sure 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 forwarding considerations above do not apply to IP traffic sent to or from the mobile router's home address (IPv4 HoA/HNP). for the mobile router's home address traffic, the forwarding considerations from [RFC5213] and [RFC5844] still apply 🫶
5.3. Security Policy Database (SPD) Example Entries ✨
okay so the DHCPv6 bit in this spec needs message integrity protection and source authentication 🔐 (no skipping this bestie 💅). The good news is that Proxy Mobile IPv6 [RFC5213] already has an IPsec setup for securing its signaling between the mobile access gateway and the local mobility anchor, and you can just reuse that same setup for the DHCP signaling between them 🫶
the SPD and SAD entries you need for this are below. they follow the [RFC4877] conventions 🎀 and they're only example configs, so a real MAG and LMA can set up different SPD and SAD entries of their own, as long as they still give the required security for the DHCP signaling messages 🧚
for the examples in this doc, we're assuming a mobile access gateway with the address mag_address_1 and a local mobility anchor with the address lma_address_1 🌸
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 = DHCP6. Security Considerations 🔥
this is the serious bit, so pay attention 👀 the Delegated Mobile Network Prefix option from this spec is for use in Proxy Binding Update and Proxy Binding Acknowledgement messages 💜 it gets carried like any other mobility header option, as specified in [RFC5213]. so it inherits its security guidelines from [RFC5213] and doesn't need any extra security considerations. no cap, that's a relief 😭
the DHCPv6 use in this spec follows the DHCPv6 base spec [RFC3315] and the DHCPv6 prefix delegation spec [RFC3633] 🦋 the security considerations in those two specs apply to this document too, so read them 🙈
if you're using IPsec, then the IPsec security association that protects the Proxy Binding Update and Proxy Binding Acknowledgement messages also has to be used to protect the DHCPv6 signaling between the mobile access gateway and the local mobility anchor 🔐 the extensions to security policy entries are identified in Section 5.3 (see [RFC4301] for the policy entries themselves) ✨
⚠️ bestie, if you skip the IPsec protection on the DHCPv6 signaling, the whole thing is exposed. the security considerations in [RFC3315] and [RFC3633] are not optional vibes, they apply here 💀
7. IANA Considerations 🌈
- this spec defines a new mobility header option, the Delegated Mobile Network Prefix option 🎀 it's described in Section 4.1. the type value
55for this message has been allocated from the "Mobility Options" registry athttp://www.iana.org/assignments/mobility-parameters🧚 - this doc also defines two new status code values for use in the Proxy Binding Acknowledgement message, described in Section 4.2 🦋 they are
NOT_AUTHORIZED_FOR_DELEGATED_MNP(not authorized for DMNP) with a status code value of177, andREQUESTED_DMNP_IN_USE(Requested DMNP is in use) with a status code value of178✨ these values were assigned from the same number space used for other status codes [RFC6275] 💖
8. Acknowledgements 🫶
the authors want to give a huge shoutout to Ryuji Wakikawa, Alexandru Petrescu, Behcet Sarikaya, Seil Jeon, Basavaraj Patil, Brian Haberman, and Michal Hoeft 💜 for all the discussions and reviews of this doc. literally iconic of them 👑
also, the work of Carlos J. Bernardos was 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) 🌸
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.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.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/📦 where this page comes from
- ietf: rfc7148 2014-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms