RFC 5026
Mobile IPv6 Bootstrapping in Split Scenario
RFC 5026: Mobile IPv6 Bootstrapping in Split Scenario 🎀
Okay so this one is from October 2007 and it's on the Standards Track 💅. Written by G. Giaretta (Ed.) from Qualcomm, J. Kempf from DoCoMo Labs USA, and V. Devarapalli (Ed.) from Azaire Networks. It was published in the Network Working Group. Its title block doesn't list anything it obsoletes or updates, so it doesn't touch any other RFCs there 🌸.
Status of This Memo ✨
This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want to know where this protocol sits in standardization right now, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🦋.
Abstract 💜
Okay so, a Mobile IPv6 node needs three things before it can even start using Mobile IPv6 service: a Home Agent address, a home address, and IPsec security associations with its Home Agent 😭. RFC 3775 says that some or all of these have to be set up statically, which is a lot of manual setup bestie 🙈. This document explains how a Mobile IPv6 node can pull that info from non-topological information and security credentials that were already pre-configured on the Mobile Node. Iconic 👑.
It solves the split scenario from the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario is when the Mobile Node's mobility service gets authorized by a different service provider than the one providing basic network access 🧚. The solution is also generically applicable to any bootstrapping case, since all the other scenarios are just more specific versions of the split scenario ✨.
Table of Contents 🌈
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Split Scenario ..................................................4
4. Components of the Solution ......................................7
5. Protocol Operations .............................................9
5.1. Home Agent Address Discovery ...............................9
5.1.1. DNS Lookup by Home Agent Name ......................10
5.1.2. DNS Lookup by Service Name .........................10
5.2. IPsec Security Associations Setup .........................11
5.3. Home Address Assignment ...................................11
5.3.1. Home Address Assignment by the Home Agent ..........11
5.3.2. Home Address Auto-Configuration by the
Mobile Node ........................................12
5.4. Authorization and Authentication with MSA .................14
6. Home Address Registration in the DNS ...........................14
7. Summary of Bootstrapping Protocol Flow .........................16
8. Option and Attribute Format ....................................17
8.1. DNS Update Mobility Option ................................17
8.2. MIP6_HOME_PREFIX Attribute ................................19
9. Security Considerations ........................................20
9.1. HA Address Discovery ......................................20
9.2. Home Address Assignment through IKEv2 .....................22
9.3. SA Establishment Using EAP through IKEv2 ..................22
9.4. Backend Security between the HA and AAA Server ............22
9.5. Dynamic DNS Update ........................................23
10. IANA Considerations ...........................................24
11. Contributors ..................................................24
12. Acknowledgements ..............................................25
13. References ....................................................25
13.1. Normative References .....................................25
13.2. Informative References ...................................261. Introduction 🍓
Okay so, Mobile IPv6 [1] needs the Mobile Node to know its Home Agent Address, its own Home Address, and the cryptographic materials (for example, shared keys or certificates) it needs to set up IPsec security associations with the Home Agent (HA). That's all so the Mobile IPv6 signaling is protected 🔐. People call this the Mobile IPv6 bootstrapping problem [7], and it's giving main character energy ngl 💀.
The Mobile IPv6 base protocol doesn't say how to get this info automatically. So network admins usually end up setting up config data by hand on both the Mobile Nodes and the HAs 😭. In real deployments that manual setup doesn't scale, because the more Mobile Nodes you have, the more painful it gets fr fr.
As [7] goes over, there are several bootstrapping scenarios, and they depend on how two parties relate to each other. One is the network operator that authenticates a mobile node to grant network access service, called the Access Service Authorizer (ASA). The other is the service provider that authorizes Mobile IPv6 service, called the Mobility Service Authorizer (MSA) 🦋. This document is a solution for the bootstrapping problem in the case where the MSA and the ASA are different entities. That's the split scenario, and yes, it's the one we're obsessed with 💖.
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 RFC 2119 [2] 🫶.
General mobility terminology can be found in [8]. Here are the extra terms this doc uses 🌸:
Access Service Authorizer (ASA)
A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service.
Access Service Provider (ASP)
A network operator that provides direct IP packet forwarding to and from the end host.
Mobility Service Authorizer (MSA)
A service provider that authorizes Mobile IPv6 service.
Mobility Service Provider (MSP)
A service provider that provides Mobile IPv6 service. To get that service, the mobile node has to be authenticated and prove it's authorized to get it 🔥.
Split scenario
A scenario where mobility service and network access service are authorized by different entities. That means the MSA is different from the ASA 👑.
3. Split Scenario ✨
Okay so, the problem statement [7] basically assumes that mobility service and network access service can be totally separate things 🦋. That means mobility service and network access might be authorized by different entities. For example, the service model in [7] lets an enterprise network set up a Home Agent and offer Mobile IPv6 service to a user, even when that user is online through a totally different account. Like, they could be using their personal WiFi hotspot account at a coffee shop ☕💅.
So in this document, we assume network access and mobility service are authorized by different entities 💖. That means authentication and authorization for mobility service and network access get considered separately. We call this the split scenario 🔥.
Also, the model in [7] separates the entity that provides the service from the entity that authenticates and authorizes the user 👑. This is kind of like the roaming model for network access. So in the split scenario, there are two different cases, depending on how the entity providing the mobility service (the Mobility Service Provider, MSP) relates to the entity that authenticates and authorizes the user (the Mobility Service Authorizer, MSA) 🌸.
Figure 1 shows the split scenario when the MSP and the MSA are the same entity 🧚. So the network operator that runs the Home Agent is also the one that authenticates and authorizes the user for mobility service 💜.
Mobility Service
Provider and Authorizer
+-------------------------------------------+
| |
| +-------------+ +--+ |
| | MSA/MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ |
| +-------------+ |
| |
+-------------------------------------------+
+--+
|MN|
+--+
Figure 1 -- Split Scenario (MSA == MSP)Figure 2 shows the split scenario when the MSA and the MSP are two different entities 🎀. This could happen if the Mobile Node is really far from its MSA network, so it gets a closer HA to make things faster ⚡. It could also happen if the MSA can't provide any Home Agent at all and needs a third party (the MSP) to hand out mobility service to its users 🫶. Also, the MSP might or might not be the same network operator that provides network access (the ASP, Access Service Provider) 👀.
Mobility Service
Authorizer
+-------------+
| MSA AAA |
| server |
+-------------+
^
|
AAA protocol |
| Mobility Service
| Provider
+--------|----------------------------------+
| V |
| +-------------+ +--+ |
| | MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ |
| +-------------+ |
| |
+-------------------------------------------+
+--+
|MN|
+--+
Figure 2 -- Split Scenario (MSA != MSP)Figure 1 and Figure 2 both assume an Authentication, Authorization, and Accounting (AAA) protocol is used to authenticate and authorize the Mobile Node for mobility service 🔐. But here's the tea 🫖: IKEv2 only allows EAP client authentication, and server authentication has to be done with certificates or public keys. So the Mobile Node might still need a Certificate Revocation List check (CRL check), even though an AAA protocol handles the authentication and authorization 😭.
If a Public Key Infrastructure (PKI) is used instead, the Mobile Node and the HA use certificates to authenticate each other, and no AAA server is involved at all [9] 🌈. This is conceptually similar to Figure 1, since MSP == MSA, except that the Home Agent (and maybe the Mobile Node too) may need a certificate revocation list check (CRL check) with the Certification Authority (CA) 💅. The CA can be either internal or external to the MSP. Figure 3 illustrates this ✨.
Certification
Authority
+-------------+
| CA |
| server |
+-------------+
^
|
CRL Check |
| Mobility Service
| Provider and Authorizer
+--------|----------+
| V |
| +-------------+ |
| | HA | |
| | | |
| +-------------+ |
| |
+-------------------+
+--+
|MN|
+--+
Figure 3 -- Split Scenario with PKIFor more details on using PKI for IKEv2 authentication, check out [3] and [10] 📚🎀.
Honestly, the split scenario is the simplest model you can come up with, because it doesn't make any assumptions about the access network 🧠. That means mobility service gets bootstrapped independently from whatever authentication protocol is used for network access (like EAP, or even open access) 🦋. So the solution in this document, which was built for this scenario, could also be used for the integrated access-network deployment model [7]. It just might not be optimized for it 🙈.
4. Components of the Solution 🧩
The bootstrapping problem is made up of several sub-problems. Each one can be solved on its own, in a modular way 💜. Below, the components are identified, with a quick overview of how each one gets solved.
HA address discovery
The Mobile Node needs to find the address of its Home Agent 🔍. The main goal of any bootstrapping solution is to keep the data pre-configured on the Mobile Node to a minimum 🌸. That's why the DHAAD defined in [1] might not work in real deployments. It requires the Mobile Node to be pre-configured with the home network prefix, and it doesn't let an operator load balance by dynamically assigning Mobile Nodes to Home Agents in different subnets 😤. This document defines a Home Agent address discovery solution based on the Domain Name Service (DNS), and it introduces a new DNS SRV record [4] 🎀. The only thing that really needs to be pre-configured on the Mobile Node is the domain name of the MSP ✨.
IPsec Security Associations setup
Mobile IPv6 requires that a Mobile Node and its Home Agent share an IPsec SA, so they can protect binding updates and other Mobile IPv6 signaling 🔐. This document provides a solution based on IKEv2, which follows what is specified in [3] 💖. IKEv2 peer authentication can be done with certificates or with EAP, depending on the network operator's deployment model 🫶.
Home Address (HoA) assignment
The Mobile Node needs to know its Home Address to bootstrap Mobile IPv6 operation 🏠. The Home Agent assigns the Home Address during the IKEv2 exchange (as described in [3]) 👑. The solution in this document also lets the Mobile Node auto-configure its Home Address using stateless auto-configuration [11], Cryptographically Generated Addresses [12], or privacy addresses [13] 🦋.
Authentication and Authorization with MSA
The user has to be authenticated before the MSP can grant the service 🔑. Since only the MSA can verify the user credentials, the MSA is the one that performs this authorization step 💅. On top of that, the MSA has to explicitly authorize the mobility service based on the user's profile 📋. These operations get done in different ways, depending on the credentials the Mobile Node uses during IKEv2 peer authentication, and on the backend infrastructure (PKI or AAA) 🌈.
An optional part of bootstrapping is giving the Mobile Node a way to have its Fully Qualified Domain Name (FQDN) updated in the DNS with a dynamically assigned home address 🍓. Not every application needs this, but lots of networking applications use the FQDN to get a node's address before they start sending IP traffic to it 🙈. The solution in this document says the dynamic DNS update is performed either by the Home Agent or through the AAA infrastructure, depending on the trust relationship in place 🤝.
5. Protocol Operations 🛠️
This section breaks down, step by step, the procedures needed to perform Mobile IPv6 bootstrapping, based on the components from the previous section 💜.
5.1. Home Agent Address Discovery
Once a Mobile Node has network access, it can start Mobile IPv6 bootstrapping 🚀. To do that, the Mobile Node queries the DNS server to ask for information about Home Agent service. As mentioned earlier in the document, the Mobile Node should be pre-configured with the domain name of the Mobility Service Provider 💖.
The Mobile Node needs the IP address of a DNS server before it can send a DNS request 📡. That can be configured on the Mobile Node, or it can be obtained through DHCPv6 from the visited link [14] ✨. Either way, it's assumed there's some kind of mechanism that configures the Mobile Node with a DNS server, since a DNS server is needed for lots of other reasons anyway 🧚.
There are two options for a DNS lookup of a Home Agent address in this document: DNS lookup by Home Agent Name, and DNS lookup by service name 🔍.
This document doesn't provide a specific mechanism for load balancing Mobile Nodes among Home Agents 🙅♀️. An MSP can get coarse-grained load balancing by dynamically updating the SRV RR priorities to reflect the current load across its collection of Home Agents 📊. Mobile Nodes then use the priority mechanism to preferentially pick the least loaded HA 💅. How well this works depends on how much load it puts on the DNS servers, especially if dynamic DNS gets used for frequent updates 😬.
While this document specifies a DNS-based Home Agent Address Discovery solution, DHCP may be used when the ASP and the MSP are the same entity 🎀. See [15] for details 💜.
5.1.1. DNS Lookup by Home Agent Name ✨
okay so in this case the Mobile Node is configured with the Fully Qualified Domain Name of the Home Agent 🎀 like, it could be set to "ha1.example.com", where "example.com" is the domain name of the MSP granting the mobility service 💅
the Mobile Node builds a DNS request by setting the QNAME to the name of the Home Agent 🫶 and the QTYPE is "AAAA" so the DNS server sends back the IPv6 address of the Home Agent 🌸 once the DNS server replies, the Mobile Node knows its Home Agent address and can run IKEv2 to set up the IPsec SAs and get a Home Address 🦋
ngl the Home Agent FQDN config on the mobile node can also be extended to dynamically assign a local home agent from the visited network 👀 bestie, this would be super useful for improving routing efficiency in bidirectional tunneling mode 💜 but enhancements or conventions for dynamic assignment of local home agents are outside the scope of this specification 🙈
5.1.2. DNS Lookup by Service Name ✨
okay so RFC 2782 [4] defines the service resource record (SRV RR) 🧚 and it lets an operator use several servers for a single domain, move services from host to host, and mark some hosts as primary servers for a service with others as backups 👑 clients ask for a specific service/protocol for a specific domain and get back the names of any available servers ✨
RFC 2782 [4] also describes the policies for choosing a service agent based on the preference and weight values 🍓 the DNS SRV record may contain the preference and weight values for multiple Home Agents available to the Mobile Node, in addition to the Home Agent FQDNs 💅 if multiple Home Agents are in the DNS SRV record, the Mobile Node is responsible for processing the info as per policy and picking one Home Agent 🫶
if the Home Agent of choice doesn't respond to the IKE_SA_INIT messages, or if IKEv2 authentication fails, the Mobile Node SHOULD try the next Home Agent on the list 😭 if none of the Home Agents respond, the Mobile Node SHOULD try again after a period of time that is configurable on the Mobile Node 🌸 and if IKEv2 authentication fails with all Home Agents, it is an unrecoverable error on the Mobile Node 💀
the service name for Mobile IPv6 Home Agent service, as required by RFC 2782, is "mip6" and the protocol name is "ipv6" 🦋 a transport name can't be used here because Mobile IPv6 doesn't run over a transport protocol 🙈
the SRV RR has a DNS type code of 33 🔥 as an example, the Mobile Node builds a request with QNAME set to "_mip6._ipv6.example.com" and QTYPE set to SRV ✨ the reply contains the FQDNs of one or more servers, which can then be resolved in a separate DNS transaction to the IP addresses 🎀 however, if there's room in the SRV reply, it is RECOMMENDED that the DNS server also returns the IP addresses of the Home Agents in AAAA records as part of the additional data section 🫶 (this way you avoid needing an extra DNS round trip to resolve the FQDNs, periodt 💖)
5.2. IPsec Security Associations Setup 🔐
as soon as the Mobile Node has discovered the Home Agent Address, it sets up an IPsec Security Association with the Home Agent itself through IKEv2 💜 the detailed description of this procedure is in [3] 🌸
if the Mobile Node wants the HA to register the Home Address in the DNS, it MUST use the FQDN as the initiator identity in the IKE_AUTH step of the IKEv2 exchange (IDi) 😭 this is needed because the Mobile Node has to prove it's the owner of the FQDN given in the later DNS Update Option 🔥 check out Sections 6 and 9 for a deeper dive on this one 👀
the IKEv2 Mobile Node to Home Agent authentication can use either IKEv2 public key signatures or the Extensible Authentication Protocol (EAP) 🦋 the details on using IKEv2 authentication are in [3] and [5] 📚 the choice of an IKEv2 peer authentication method depends on the deployment 🍓 the Mobile Node should be configured with info on which IKEv2 authentication method to use 🧚 but honestly, IKEv2 restricts Home Agent to Mobile Node authentication to public key signature-based authentication 💅
5.3. Home Address Assignment 🏡
Home Address assignment happens during the IKEv2 exchange 🎀 the Home Address can be assigned directly by the Home Agent, or it can be auto-configured by the Mobile Node ✨
5.3.1. Home Address Assignment by the Home Agent 👑
when the Mobile Node runs IKEv2 with its Home Agent, it can request a HoA through the Configuration Payload in the IKE_AUTH exchange by including an INTERNAL_IP6_ADDRESS attribute 🫶 when the Home Agent processes the message, it allocates a HoA and sends it back in a CFG_REPLY message 🌸 the Home Agent could also consult a DHCP server on the home link for the actual home address allocation 💜 this is explained in detail in [3] 📚
5.3.2. Home Address Auto-Configuration by the Mobile Node 🦋
okay so with the type of assignment from the previous section, the Home Address can't be generated based on Cryptographically Generated Addresses (CGAs) [12] or based on the privacy extensions for stateless auto-configuration [13] 😭 but the Mobile Node might still want an auto-configured HoA based on these mechanisms 👀 also, the auto-configuration procedure in this section can't be used in some possible deployments, since the Home Agents might be provisioned with pools of allowed Home Addresses 🙈
in the simplest case, the Mobile Node is given a pre-configured home prefix and home prefix length 🎀 the Mobile Node creates a Home Address based on that pre-configured prefix and sends it to the Home Agent, with an INTERNAL_IP6_ADDRESS attribute in a Configuration Payload of type CFG_REQUEST 💅 if the Home Address is valid, the Home Agent replies with a CFG_REPLY that includes an INTERNAL_IP6_ADDRESS with the same address ✨ if the Home Address the Mobile Node sent isn't valid, the Home Agent assigns a different Home Address in an INTERNAL_IP6_ADDRESS attribute with a new value 😬 according to [5], the Mobile Node MUST use the address sent by the Home Agent 🔥 later, if the Mobile Node wants an auto-configured Home Address (e.g., based on CGA), it can run Mobile Prefix Discovery, get a prefix, auto-configure a new Home Address, and then do a new CREATE_CHILD_SA exchange 🦋
if the Mobile Node isn't given a pre-configured Home Prefix, it can't just propose an auto-configured HoA in the Configuration Payload 🙃 that's because the Mobile Node doesn't know the home prefix before the IKEv2 exchange starts 💀 the Mobile Node must get the home prefix and the home prefix length before it can configure a home address 🫶
one simple solution would be for the Mobile Node to just assume the prefix length on the home link is 64 bits and pull the home prefix out of the Home Agent's address 🌈 the downside is that the home prefix can't be anything other than /64 😭 this also ties the prefix on the home link to the Home Agent's address, but in general, a Home Agent with a particular address should be able to serve a number of prefixes on the home link, not just the prefix its address was configured from 👑
another solution would be for the Mobile Node to assume the prefix length on the home link is 64 bits and send its interface identifier to the Home Agent in the INTERNAL_IP6_ADDRESS attribute within the CFG_REQ payload 🧚 even though this approach doesn't tie the prefix on the home link to the Home Agent's address, it still requires the home prefix length to be 64 bits 🙈
so for this reason, the Mobile Node needs to get the home link prefixes through the IKEv2 exchange 🚨 in the Configuration Payload during the IKE_AUTH exchange, the Mobile Node includes theMIP6_HOME_PREFIXattribute in theCFG_REQUESTmessage 💖 the Home Agent, when it processes this message, MUST include in theCFG_REPLYpayload prefix information for one prefix on the home link 🔥 this prefix information includes the prefix length (see Section 8.2) 📏 the Mobile Node then auto-configures a Home Address from the prefix returned in theCFG_REPLYmessage and runs aCREATE_CHILD_SAexchange to create security associations for the new Home Address 🎉
as mentioned earlier in this document, there are deployments where auto-configuration of the Home Address can't be used 🥺 in that case, when the Home Agent receives a CFG_REQUEST that includes a MIP6_HOME_PREFIX attribute, it includes a Notify Payload of type "USE_ASSIGNED_HoA" and the related Home Address in an INTERNAL_IP6_ADDRESS attribute in the subsequent IKE response 🌸 if the Mobile Node gets a "USE_ASSIGNED_HoA" Notify Payload in response to the Configuration Payload containing the MIP6_HOME_PREFIX attribute, it looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the address in it in the subsequent CREATE_CHILD_SA exchange 💅
when the Home Agent gets a Binding Update for the Mobile Node, it does proxy DAD for the auto-configured Home Address 🔍 if DAD fails, the Home Agent rejects the Binding Update 🙅♀️ if the Mobile Node gets a Binding Acknowledgement with status 134 (DAD failed), it MUST stop using the current Home Address, configure a new HoA, and then run an IKEv2 CREATE_CHILD_SA exchange to create security associations based on the new HoA 😭 the Mobile Node doesn't need to run the IKE_INIT and IKE_AUTH exchanges again 🙌 once the necessary security associations exist, the Mobile Node sends a Binding Update for the new Home Address 💜
it's worth noting that with this mechanism, the prefix info carried in the MIP6_HOME_PREFIX attribute includes only one prefix, and it doesn't carry all the info you'd normally get from an IPv6 router advertisement 🫠 Mobile Prefix Discovery, specified in RFC 3775, is the mechanism the Mobile Node uses to get all prefixes on the home link and all the related info 📚 so the MIP6_HOME_PREFIX attribute is only for Home Address auto-configuration and doesn't replace Mobile Prefix Discovery for the purposes detailed in RFC 3775 🦋
5.4. Authorization and Authentication with MSA ✨
okay so picture this 🧚. The Mobile Node finds its Home Agent dynamically, right? Then the Home Agent probably can't check the Mobile Node's credentials by itself during the IKEv2 exchange 😭. And the mobility service has to be explicitly authorized based on the user's profile. The HA might not even know whether the service is allowed at a certain time of day, or whether the Mobile Node's credit is about to run out 💀.
So the Home Agent may need to contact the MSA to authenticate the Mobile Node and authorize the mobility service 🫶. If certificates are used and the MSP and MSA have a PKI deployed, this can be done with a Public Key Infrastructure. If the Mobile Node has some other kind of credentials instead, the AAA infrastructure must be used 🔐.
The backend communication itself is out of scope for this document 🙈. [16] lists goals for that communication, and [17] and [18] define the RADIUS and Diameter extensions, respectively, for the backend communication 💜.
6. Home Address Registration in the DNS 🌸
okay this part is so important bestie. For the Mobile Node to be reachable through its dynamically assigned Home Address, the DNS needs to be updated with the new Home Address 💅. Applications look up nodes by FQDN through DNS, so the DNS update is essential for IP reachability, which is literally the main purpose of Mobile IPv6 👑.
RFC 3775 doesn't talk about DNS updating because it assumes the Mobile Node has a static Home Address 🤷♀️. But once a dynamic Home Address is assigned, any existing DNS entry becomes invalid, and the Mobile Node becomes unreachable unless a DNS update is performed 😱.
The DNS update has to be done securely so malicious nodes can't attack or modify it, which means the node doing the update must share a security association with the DNS server 🔒. Having every possible Mobile Node share a security association with the MSP's DNS servers would be a huge administrative headache 💀. And even when a Mobile Node does have a security association with its MSP's DNS server, there's an address authorization issue on top of that 🙈. A detailed analysis of possible threats against DNS update is in Section 9.5, so go read that one 🦋.
So for security and admin reasons, it is RECOMMENDED that the Home Agent perform DNS entry updates for the Mobile Node 🎀. To do this, the Mobile Node MAY include a new mobility option in the Binding Update, the DNS Update option, with the R flag not set. This option is defined in Section 8 and includes the FQDN that needs updating ✨. After receiving the Binding Update, the Home Agent MUST update the DNS entry using the identifier from the Mobile Node and the Home Address from the Home Address Option 💖. The procedure for sending a dynamic DNS update message is specified in [6]. The dynamic DNS update SHOULD be performed in a secure way, so the usage of TKEY and TSEC or DNSSEC is recommended (see Section 9.5 for details) 🔐. As soon as the Home Agent has updated the DNS, it MUST send a Binding Acknowledgement message to the Mobile Node, including the DNS Update mobility option with the correct value in the Status field (see Section 8.1) 🫶.
This can be done directly by the Home Agent if it has a security association with the domain in the Mobile Node's FQDN 🥰.
BUT if the Mobile Node wants to be reachable through an FQDN that belongs to the MSA, then the Home Agent and the DNS server that needs updating are in different administrative domains 🌈. In that case the Home Agent may not share a security association with the DNS server, so the DNS entry update can be done by the AAA server of the MSA ✨. To make that happen, the Home Agent sends the FQDN-HoA pair to the AAA server through the AAA protocol. The message gets proxied by the MSP's AAA infrastructure and received by the MSA's AAA server, which performs the DNS update based on [6] 💜. Heads up though: even in this case, the Home Agent is always required to perform a DNS update for the reverse entry, since that always happens in the MSP's DNS server 👑. The detailed communication between Home Agent and AAA is out of scope for this document, but more details are in [16] 🧚.
We also need a way to remove stale DNS entries 🧹. A DNS entry goes stale when its related Home Address is no longer used by the Mobile Node 💀. To remove one, the Mobile Node includes the DNS Update mobility option in the Binding Update with the R flag set. After receiving it, the Home Agent MUST remove the DNS entry identified by the FQDN from the Mobile Node and the Home Address from the Home Address Option 🙅♀️. The procedure for sending a dynamic DNS update message is specified in [6]. As mentioned above, the dynamic DNS update SHOULD be performed in a secure way, so the usage of TKEY and TSEC or DNSSEC is recommended (see Section 9.5 for details) 🔒.
If the Mobile Node never sends an explicit de-registration BU, the HA MAY use the binding cache entry expiration as a trigger to remove the DNS entry ⏰.
7. Summary of Bootstrapping Protocol Flow 🦋
Here's the whole bootstrapping message flow when the Home Agent does the dynamic DNS update 👀:
+----+ +----+ +-----+
| MN | | HA | | DNS |
+----+ +----+ +-----+
IKEv2 exchange
(HoA configuration)
<======================>
BU (DNS update option)
----------------------->
DNS update
<------------------->
BA (DNS update option)
<-----------------------And here's the opposite case, where the dynamic DNS update is done by the MSA's AAA server instead 🔄:
+----+ +----+ +---+ +---+
| MN | | HA | |AAA| |DNS|
+----+ +----+ +---+ +---+
IKEv2 exchange
(HoA configuration)
<======================>
BU (DNS update option)
----------------------->
AAA request
(FQDN, HoA)
<-------------->
DNS update
<----------->
AAA answer
(FQDN, HoA)
<-------------->
BA (DNS update option)
<-----------------------Even in this last case, the Home Agent is always required to perform a DNS update for the reverse entry, since that always happens in the MSP's DNS server. It isn't shown in the figure above 💅.
8. Option and Attribute Format 🎀
8.1. DNS Update Mobility Option 💖
This is the layout of the DNS Update mobility option 🧩:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |R| Reserved | MN identity (FQDN) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type 🏷️: the value is DNS-UPDATE-TYPE (17).
Option Length 📏: an 8-bit unsigned integer giving the length of the option, not counting the type and length fields.
Status 🚦: an 8-bit unsigned integer that shows the result of the dynamic DNS update procedure. This field MUST be set to 0 and ignored by the receiver when the DNS Update mobility option is in a Binding Update message. When the DNS Update mobility option is in the Binding Acknowledgement message, Status values less than 128 mean the Home Agent performed the dynamic DNS update successfully. Values greater than or equal to 128 mean the HA did not complete the dynamic DNS update. These Status values are currently defined:
0 DNS update performed
128 Reason unspecified
129 Administratively prohibited
130 DNS update failed🚨 Remember: when this option rides in a Binding Update, the Status field MUST be 0 and the receiver ignores it, so don't try to read anything into it there!
R flag 🔁: if set, the Mobile Node is asking the HA to remove the DNS entry identified by the FQDN in this option and the Mobile Node's HoA. If not set, the Mobile Node is asking the HA to create or update a DNS entry with its HoA and the FQDN in the option.
Reserved 🫧: MUST be set to 0.
MN identity 🪪: the Mobile Node's identity in FQDN format, which the Home Agent uses to send a dynamic DNS update. It's a variable length field.
8.2. MIP6_HOME_PREFIX Attribute ✨
okay so the MIP6_HOME_PREFIX attribute rides along inside IKEv2 Configuration Payload messages 🫶 its whole job is to carry the home prefix that the Mobile Node uses to auto-configure its home address 🏠
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Home Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+Reserved (1 bit) 🔒
This bit MUST be set to zero and MUST be ignored on receipt. no touching, bestie 🙅♀️
Attribute Type (15 bits) 🏷️
A unique identifier for the MIP6_HOME_PREFIX attribute (16). this is its ID card 🪪
Length (2 octets) 📏
The length in octets of the Value field (Home Prefix, Prefix Lifetime and Prefix Length). This can be 0 or 21. so it's either empty or exactly 21 octets, no in-between vibes 💅
Prefix Lifetime (4 octets) ⏳
The lifetime of the Home Prefix. how long the prefix stays valid, basically 🕰️
Home Prefix (16 octets) 🏡
The prefix of the home link through which the Mobile Node may auto-configure its Home Address. this is the main event, the prefix the Mobile Node builds its address from 🌸
Prefix Length (1 octet) 📐
The length in bits of the home prefix specified in the field Home Prefix. so it tells you where the prefix ends 🎀
Now the fun part, the two roles 👑 When the Mobile Node includes the MIP6_HOME_PREFIX attribute in the CFG_REQUEST payload, the Length field is 0, because it's just asking, not giving anything yet 🙏 When the Home Agent includes it in the CFG_REPLY payload, the Length field is 21 and the attribute also carries the actual home prefix info ✨ it's giving "here's your stuff" energy 🎁
9. Security Considerations 🔐
okay bestie, this section is seriously important, so let's go through it properly 💀
9.1. HA Address Discovery 🕵️♀️
Using DNS for address discovery comes with some real security risks 😬 DNS transactions on the Internet are usually done without the DNS server being authenticated by the client, or the client being authenticated by the server. no cap, that's a lot of trust 🙈 There are two risks involved:
- A legitimate client obtains a bogus Home Agent address from a bogus DNS server. This is sometimes called a "pharming" attack. 🍯
- An attacking client obtains a legitimate Home Agent address from a legitimate server.
the Case 1 risk gets mitigated because the Mobile Node is required to conduct an IKE transaction with the Home Agent before it does a Binding Update to set up Mobile IPv6 service 🛡️ according to the IKEv2 specification [5], the responder has to present the initiator with a valid certificate containing the responder's public key, and the responder's IKE_AUTH message to the initiator has to be protected with an authenticator calculated using the public key in that certificate. so an attacker would need to set up BOTH a bogus DNS server AND a bogus Home Agent, and also provision that Home Agent with a certificate the victim Mobile Node could verify 😤 If the Mobile Node can detect that the certificate isn't trustworthy, the attack gets foiled when the Mobile Node tries to set up the IKE SA 🚫
the Case 2 risk is limited, for a single Mobile Node to Home Agent transaction, if the attacker doesn't have proper credentials to authenticate with the Home Agent 🔑 The IKE SA establishment fails when the attacking Mobile Node tries to authenticate itself with the Home Agent. whether the Home Agent uses EAP or host-side certificates to authenticate the Mobile Node, the authentication fails unless the Mobile Node has valid credentials. no valid creds, no entry 💅
there's another Case 2 risk too, because the attacker might be trying to launch a Denial of Service (DoS) attack on the Home Agent 💥 In that case, the attacker grabs the Home Agent address from DNS, then passes the address along to a network of attacking hosts that bombard the Home Agent with traffic. this attack isn't unique to the bootstrapping solution, though. it's actually a risk that ANY Mobile IPv6 Home Agent installation faces 😭 In fact, every service on the Internet that hands out a globally routable unicast address to clients faces it too. Since Mobile IPv6 requires the Mobile Node to communicate through a globally routable unicast address of a Home Agent, the Home Agent address could end up in an attacker's hands through various routes (theft of the Mobile Node, malware on the Mobile Node, or evil intent from the Mobile Node owner themselves, etc.), even if the home address is configured manually on the Mobile Node 🙃 So every Mobile IPv6 Home Agent installation will likely need anti-DoS measures. These include overprovisioning links to and from Home Agents and Home Agent processing capacity, vigilantly monitoring traffic on the Home Agent networks to spot when traffic volume jumps abnormally (a possible DoS attack), and hot spares that can be switched on quickly if an attack hits a running collection of Home Agents 🔥 DoS attacks of moderate intensity should be foiled during the IKEv2 transaction. IKEv2 implementations are expected to generate their cookies without any saved state, and to time out cookie generation parameters frequently, with the timeout value increasing if a DoS attack is suspected. This should prevent state depletion attacks, and should keep service running for legitimate clients until the practical limits on the network bandwidth and processing capacity of the Home Agent network get reached 🌈
Explicit security measures between the DNS server and host, such as DNSSEC [19] or TSIG/TKEY [20] [21], can mitigate the risk of 1) and 2), but these measures aren't widely deployed on end nodes 🥲 They also aren't enough to protect the Home Agent address against DoS attack, because a node with a legitimate security association with the DNS server could still intentionally or inadvertently cause the Home Agent address to become a DoS target 🎯
Last thing, and it's a big one 👀 assigning a home agent from the serving network access provider (a local home agent) or a home agent from a nearby network (a nearby home agent) may set up the potential to compromise a mobile node's location privacy 📍 A home address anchored at such a home agent contains some information about the topological location of the mobile node. So a mobile node that needs location privacy should not disclose that home address to nodes that aren't authorized to learn its location, e.g., by updating DNS with the new home address 🙊
Security considerations for discovering HA using DHCP are covered in [22]. 📚
9.2. Home Address Assignment through IKEv2 🏠
Mobile IPv6 bootstrapping assigns the home address through the IKEv2 transaction 🎀 The Mobile Node can either request an address, kind of like DHCP, or it can request a prefix on the home link and then auto-configure an address from it.
RFC 3775 [1] requires that a Home Agent check the authorization of a home address received during a Binding Update. So the home agent MUST authorize each home address allocation and use 🛂 This authorization is based on linking the mobile node identity used in the IKEv2 authentication process with the home address. Home agents MUST implement at least the following two modes of authorization:
- Configured home address(es) for each mobile node. In this mode, the home agent or the infrastructure nodes behind it know which addresses a specific mobile node is authorized to use. The mobile node is allowed to request these addresses, or if the mobile node requests any home address, these addresses get returned to it 📋
- First-come-first-served (FCFS). In this mode, the home agent keeps a pool of "used" addresses, and lets mobile nodes request any address, as long as it isn't used by another mobile node 🏃♀️
Addresses MUST be marked as used for at least as long as the binding exists, and they're associated with the identity of the mobile node that made the allocation 🔖
On top of that, the home agent MUST ensure that the requested address is not the authorized address of any other mobile node, i.e., if both FCFS and configured modes use the same address space 🚦 no double-booking allowed, periodt 💅
9.3. SA Establishment Using EAP through IKEv2 🔐
Security considerations for authenticating the IKE transaction using EAP are covered in [3]. 🫶
9.4. Backend Security between the HA and AAA Server 🗄️
Some Mobile IPv6 bootstrapping deployments may use an AAA server to handle authorization for mobility service. This process has its own security requirements, but the backend protocol for the interface between a Home Agent and an AAA server isn't covered in this document. For a discussion of that interface, check out [16] 🧚
9.5. Dynamic DNS Update ✨
Okay bestie, let's talk about DNS updates 💅. If a Home Agent updates DNS for the Mobile Node directly with the DNS server, the Home Agent MUST have a security association of some type with that server 🔐. The security association MAY be set up using DNSSEC [19] or TSIG/TKEY [20][21]. A security association is REQUIRED even when the DNS server lives in the same administrative domain as the Home Agent, no exceptions 🙅♀️. It SHOULD also be separate from the security associations used for other purposes, like AAA 🧚
Now, if the Mobility Service Provider is different from the Mobility Service Authorizer, network admins might want to limit how many cross-administrative-domain security associations they have 🌸. If the Mobile Node's FQDN is in the Mobility Service Authorizer's domain, then the AAA signaling for mobility service authorization already needs a security association anyway. So the Home Agent can send the Mobile Node's FQDN to the AAA server over the HA-AAA server security association, and the AAA server does the update 🦋. In that setup, you need a security association between the AAA server and the DNS server for the dynamic DNS update. For a deeper dive on the Home Agent to AAA server interface, check out [16] 📚
Here's the big one 👑: whether the AAA server or the Home Agent does the DNS update, the authorization of the Mobile Node to update a FQDN MUST be checked before the update happens. How authorization gets decided is an implementation issue, so that's up to the implementer 🛠️. But to make this authorization step possible, the Mobile Node MUST use a FQDN as the IDi in the IKE_AUTH step of the IKEv2 exchange. That FQDN MUST be the same FQDN the Mobile Node provides in the DNS Update Option 🫶
If EAP over IKEv2 is used to set up the IPsec SA, the Home Agent learns about authorization for the Mobile Node's FQDN through the AAA back-end communication during the IKEv2 exchange 🔥. The result gives the Home Agent what it needs to authorize the Mobile Node's DNS update request. For the details on how the AAA server and Home Agent talk to each other for this, see [16] 💜
And if certificates are used in IKEv2, the authorization info about the FQDN for the DNS update MUST be in the certificate the Mobile Node provides 📜. The IKEv2 spec doesn't include a required certificate type, so we can't say exactly how the Mobile Node's FQDN should show up in the certificate 🤷♀️. As an example though, if the certificate type is "X.509 Certificate - Signature" (one of the recommended types), then the FQDN may appear in the subjectAltName attribute extension [23] 🎀
10. IANA Considerations 🌈
Okay so this document defines a new Mobility Option and a new IKEv2 Configuration Attribute Type 🧚 Here's what got assigned:
- from the "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE, 17 (Section 8.1)
- from the "IKEv2 Configuration Payload Attribute Types" namespace ([5]): MIP6_HOME_PREFIX attribute, 16 (Section 8.2)
- from the "IKEv2 Notify Payload Error Types" namespace ([5]): USE_ASSIGNED_HoA error type, 42 (Section 5.3.2)
This document also creates a brand new namespace called "Status Codes (DNS Update Mobility Option)" for the status field in the DNS Update mobility option 💖. The current values are described in Section 8.1, and they're listed right here:
0 DNS update performed
128 Reason unspecified
129 Administratively prohibited
130 DNS update failedFuture values of the Status field in the DNS Update mobility option can be allocated using Standards Action or IESG approval 🔮
11. Contributors 🫶
This contribution is a joint effort from the bootstrapping solution design team of the MIP6 WG 🌟 The contributors are Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal Chowdury, and Julien Bournelle 💅
The design team members can be reached at:
Gerardo Giaretta, gerardog@qualcomm.com
Basavaraj Patil, basavaraj.patil@nokia.com
Alpesh Patel, alpesh@cisco.com
Jari Arkko, jari.arkko@kolumbus.fi
James Kempf, kempf@docomolabs-usa.com
Yoshihiro Ohba, yohba@tari.toshiba.com
Gopal Dommety, gdommety@cisco.com
Alper Yegin, alper.yegin@samsung.com
Vijay Devarapalli, vijay.devarapalli@azairenet.com
Kuntal Chowdury, kchowdury@starentnetworks.com
Junghoon Jee, jhjee@etri.re.kr
Julien Bournelle, julien.bournelle@gmail.com12. Acknowledgements 💜
The authors want to thank Rafa Lopez, Francis Dupont, Jari Arkko, Kilian Weniger, Vidya Narayanan, Ryuji Wakikawa, and Michael Ye for their valuable comments 🥰
13. References 📚
13.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April
2007.
[4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.13.2. Informative References
[7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[8] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[9] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
X.509 Public Key Infrastructure Certificate Management Protocol
(CMP)", RFC 4210, September 2005.
[10] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[11] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[12] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005.
[13] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941,
September 2007.
[14] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
2003.
[15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Work in Progress, June 2007.
[16] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress,
September 2006.
[17] Chowdhury, K., "RADIUS Mobile IPv6 Support", Work in Progress,
March 2007.
[18] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support",
Work in Progress, May 2007.
[19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[20] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[21] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.
[22] Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", Work in Progress, June 2007.
[23] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.Authors' Addresses 🖊️
Gerardo Giaretta
Qualcomm
EMail: gerardog@qualcomm.com
James Kempf
DoCoMo Labs USA
181 Metro Drive
San Jose, CA 95110
USA
EMail: kempf@docomolabs-usa.com
Vijay Devarapalli
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA
EMail: vijay.devarapalli@azairenet.comFull Copyright Statement ©
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔏
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🎀
📦 where this page comes from
- ietf: rfc5026 2007-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms