RFC 5555
Mobile IPv6 Support for Dual Stack Hosts and Routers
Mobile IPv6 Support for Dual Stack Hosts and Routers 💖
okay bestie, this is RFC 5555 🎀 and it's a whole mobility upgrade for dual stack devices. It was written by H. Soliman, Ed. from Elevate Technologies 💅, and it's on the Standards Track ✨. It's dated June 2009 🌸 and it's part of the Network Working Group stream. The title block doesn't list anything this RFC obsoletes or updates, so it's standing on its own 🦋.
Status of This Memo ✨
ok so this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (c) 2009 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, as they stand on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, bestie, because they explain your rights and restrictions for this document 🙈.
Abstract
okay so the current Mobile IPv6 and Network Mobility (NEMO) specs only support IPv6 🥺. This spec levels them up so you can register IPv4 addresses and prefixes, and so both IPv4 and IPv6 packets can travel through the tunnel to the home agent 🚇. It also lets the mobile node roam over both IPv6 and IPv4 🧚, including when a Network Address Translation box sits on the path between the mobile node and its home agent 🔥.
Table of Contents
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Motivation for Using Mobile IPv6 Only ......................4
1.3. Scenarios Considered by This Specification .................4
2. Solution Overview ...............................................6
2.1. Home Agent Address Discovery ...............................6
2.2. Mobile Prefix Solicitation and Advertisement ...............7
2.3. Binding Management .........................................8
2.3.1. Foreign Network Supports IPv6 .......................8
2.3.2. Foreign Network Supports IPv4 Only ..................9
2.4. Route Optimization ........................................11
2.5. Dynamic IPv4 Home Address Allocation ......................11
3. Extensions and Modifications to Mobile IPv6 ....................11
3.1. Binding Update Extensions .................................11
3.1.1. IPv4 Home Address Option ...........................11
3.1.2. The IPv4 Care-of Address Option ....................13
3.1.3. The Binding Update Message Extensions ..............13
3.2. Binding Acknowledgement Extensions ........................14
3.2.1. IPv4 Address Acknowledgement Option ................14
3.2.2. The NAT Detection Option ...........................16
4. Protocol Operation .............................................17
4.1. Tunnelling Formats ........................................17
4.1.1. Tunnelling Impacts on Transport and MTU ............18
4.2. NAT Detection .............................................19
4.3. NAT Keepalives ............................................21
4.4. Mobile Node Operation .....................................22
4.4.1. Selecting a Care-of Address ........................22
4.4.2. Sending Binding Updates ............................23
4.4.3. Sending Packets from a Visited Network .............25
4.4.4. Movement Detection in IPv4-Only Networks ...........26
4.5. Home Agent Operation ......................................26
4.5.1. Sending Packets to the Mobile Node .................28
4.6. Correspondent Node Operation ..............................29
5. Security Considerations ........................................29
5.1. Handover Interactions for IPsec and IKE ...................30
5.2. IKE Negotiation Messages between the Mobile Node
and Home Agent ............................................33
5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling .....33
5.2.2. IKEv2 Operation for Securing Data over IPv4 ........36
6. Protocol Constants .............................................38
7. Acknowledgements ...............................................38
8. IANA Considerations ............................................38
9. References .....................................................39
9.1. Normative References ......................................39
9.2. Informative References ....................................40
10. Contributors ..................................................411. Introduction ✨
okay so Mobile IPv6 [RFC3775] and NEMO [RFC3963] let mobile nodes move around the Internet while staying reachable and keeping their sessions going 🚶♀️💕. They do this using an IPv6 home address or prefix. The catch is that IPv6 isn't widely deployed yet 🥲, so mobile nodes probably won't be using only IPv6 addresses for their connections at first. It's totally reasonable to assume mobile nodes will need an IPv4 home address that upper layers can use for a long time 💅. It's also reasonable to assume they'll move onto networks that might not support IPv6, so they'd need to be able to use an IPv4 care-of address 🌸. So this spec extends Mobile IPv6 so dual stack mobile nodes can ask their home agent (which is also dual stacked 👯) to tunnel IPv4/IPv6 packets addressed to their home addresses, plus IPv4/IPv6 care-of address(es) 🎀.
With this spec, mobile nodes only need Mobile IPv6 and [RFC3963] to handle mobility while they move around the Internet 🦋. That means no more running two mobility management protocols at the same time 🙌. This spec gives the extensions that let dual stack mobile nodes use IPv6 mobility only ✨.
This spec also looks at cases where a mobile node moves into a private IPv4 network and gets a private IPv4 care-of address 🏠. In those situations, the mobile node has to be able to get through the IPv4 NAT so it can talk to the home agent 🔥. IPv4 NAT traversal for Mobile IPv6 is covered right here in this spec 💜.
In this spec, "mobile node" means both a mobile host and a mobile router, unless the discussion is specifically about one or the other 🧚. Similarly, we use "home address" to mean an address/prefix format 🍓. Both mobile host and mobile router functionality were already defined in [RFC3775] and [RFC3963], respectively 📚. This spec doesn't change those behaviors that are already defined, and it doesn't extend the specific types of host and router support that already exist 🙈. The two exceptions are: (i) letting the mobile node talk to its home agent even over IPv4 networks, and (ii) letting it use IPv4 home addresses and prefixes 💖.
Here, extensions are defined for the binding update and the binding acknowledgement 💌. Note that all these extensions apply when the mobile node talks to a Mobility Anchor Point (MAP) as defined in [RFC5380] 🗺️. The requirements on the MAP are identical to the ones stated for the home agent 👑. But NAT traversal is unlikely to be needed with a MAP, since it's expected to be in the same address domain 💅.
1.1. Requirements Notation
okay this part is the key word glossary 🔑, so pay attention bestie 👀. 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] 📖✨.
1.2. Motivation for Using Mobile IPv6 Only
ok so IPv6 has a bunch of upgrades over today's IPv4, mainly because it has a massive address space 🌌. Mobile IPv6 also has a bunch of upgrades over Mobile IPv4 [RFC3344], mostly because it inherits capabilities from IPv6 💫. For example, route optimization and dynamic home agent discovery can only be achieved with Mobile IPv6 🦋.
One of the perks of IPv6's huge address space is that it lets mobile nodes get a globally unique care-of address wherever they are 🌍. That means there's no need for the NAT traversal techniques designed for Mobile IPv4 🙅♀️. Mobile IPv6 becomes way simpler and more bandwidth-efficient as a mobility management protocol because of that 🔥. But during the move towards IPv6, NAT traversal for existing private IPv4 networks still needs attention 🥺, so this spec introduces NAT traversal for exactly that purpose 🫶.
The benefits above are the case for using only Mobile IPv6 for dual stack mobile nodes, because it gives you a long-lasting mobility solution 👑. Using Mobile IPv6 for dual stack mobility means you don't have to change your mobility solution just because IPv6 shows up in a network you've already deployed 💅✨.
1.3. Scenarios Considered by This Specification
okay so there are a bunch of scenarios where mobile nodes running Mobile IPv6 can run into trouble 🧚. Some of these mobility and transition headaches were already covered in [RFC4977], and this spec looks at every single problem from that doc 💅. Here's the lineup. They're not mutually exclusive, so one mobile node can be in more than one of these at the same time 💀.
All of the scenarios below assume that both the mobile node and the home agent are IPv4- and IPv6-enabled, and that only Mobile IPv6 is used between them. We also assume the home agent is always reachable through a globally unique IPv4 address 🫶.
Scenario 1: IPv4-only foreign network 🍓
In this one, the mobile node is connected to an IPv4-only foreign network. The only address it can configure is an IPv4 care-of address. Rough, but we'll handle it 💪.
Scenario 2: Mobile node behind a NAT 🦋
Here the mobile node is in a private IPv4 foreign network, and a NAT device connects that network to the Internet. If the home agent is outside the NAT device, the mobile node will need a NAT traversal mechanism to talk to the home agent. Not a vibe, but it's manageable ✨.
It should be noted that [RFC5389] calls out some issues with NATs that act as generic Application Level Gateways (ALGs) and rewrite any 32-bit field containing the NAT's public IP addresses. This specification will not support such NATs 🙅♀️.
Scenario 3: Home agent behind a NAT 🌈
This one is extra messy because the home agent itself lives inside a private IPv4 network. We still assume the home agent is allocated a globally unique IPv4 address 🎀. That address might not be physically configured on the home agent's interface. Instead, it's associated with the home agent on the Network Address Port Translation (NAPT) device, which lets the home agent be reached through address or port mapping. Very main character, very complicated 🌸.
Scenario 4: Use of IPv4-only applications 💜
In this scenario, the mobile node may be located in an IPv4, IPv6, or dual network. However, the mobile node might be talking to an IPv4-only node. In that case, the mobile node would need a stable IPv4 address for its application. The alternative to an IPv4 address is to use protocol translators. End-to-end communication with IPv4 is preferred over protocol translators, though 🙈.
The mobile node may also be communicating with an IPv4-only application that requires an IPv4 address.
So the cases above show why the mobile node needs a stable IPv4 home address. That's done using an IPv4 home address. Running Mobile IPv4 and Mobile IPv6 at the same time is problematic (as [RFC4977] illustrates), so this scenario adds a requirement on Mobile IPv6 to support IPv4 home addresses 👑.
Scenario 5: IPv6 and IPv4-enabled networks 🧚
In this scenario, the mobile node should prefer an IPv6 care-of address for either its IPv6 or IPv4 home address. Normal IP-in-IP tunnelling should be used here, as described in [RFC3775]. Under rare exceptions, where IP-in-IP tunnelling for IPv6 doesn't let the mobile node reach the home agent, the mobile node follows the sending algorithm described in Section 4.4.1 🔥.
UDP tunnelling in IPv6 networks is proposed in this document as a last-resort mechanism for when reachability can't be achieved through normal IP-in-IP tunnelling. It should not be viewed as a normal mode of operation, and it should not be used as a first resort 🫠.
2. Solution Overview ✨
In order to let Mobile IPv6 be used by dual stack mobile nodes, the following needs to happen 💅:
- Mobile nodes should be able to use IPv4 and IPv6 home or care-of addresses at the same time, and update their home agents accordingly.
- Mobile nodes need to know the IPv4 address of the home agent as well as its IPv6 address. There's no need for IPv4 prefix discovery, though 🙅♀️.
- Mobile nodes need to be able to detect the presence of a NAT device and traverse it to communicate with the home agent 🦋.
This section gives an overview of the extensions needed so mobile nodes can use only Mobile IPv6 for IP mobility management 🌸.
2.1. Home Agent Address Discovery
Dynamic Home Agent Address Discovery (DHAAD) is defined in [RFC3775]. It lets mobile nodes discover their home agents by appending a well-known anycast interface identifier to their home link's prefix. BUT this mechanism is based on IPv6-anycast routing. So if a mobile node (MN) is in an IPv4-only foreign network, it can't rely on native IPv6 routing 😭. In that case, the solution for discovering the home agent's IPv4 address is through the Domain Name System (DNS). If the MN is attached to an IPv6-only or dual stack network, it may also use the procedures defined in [CHOWDHURY] to discover home agent information. Note that [CHOWDHURY] can't give the mobile node information that lets it communicate with the home agent if the mobile node is in an IPv4-only network. In that scenario, the mobile node needs to discover the IPv4 address of its home agent through the DNS 🎀.
For DNS lookup by name, the mobile node should be configured with the name of the home agent. When the mobile node needs to discover a home agent, it sends a DNS request with QNAME set to the configured name. An example is ha1.example.com. If a home agent has an IPv4 and IPv6 address, the corresponding DNS record should be configured with both AAAA and A records. That way, the DNS reply will contain AAAA and A records too ✨.
For DNS lookup by service, the SRV record defined in [RFC5026] is reused. For instance, if the service name is "mip6" and the protocol name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS request with the QNAME set to _mip6._ipv6.example.com. The response should contain the home agent's FQDN(s), and it may include the corresponding AAAA and A records as well 💜.
If multiple home agents live on the home link and each one is configured with a public IPv4 address, then the operation above applies. The correct DNS entries can be configured accordingly 🧚.
2.2. Mobile Prefix Solicitation and Advertisement
According to [RFC3775], the mobile node can send a Mobile Prefix Solicitation and receive a Mobile Prefix Advertisement containing all prefixes advertised on the home link 🌈.
A dual stack mobile node MAY send a Mobile Prefix Solicitation message encapsulated in IPv4 (i.e., IPv6 in IPv4) when it has no access to IPv6 within the local network 🦋. Securing these messages requires the mobile node to have a security association with the home agent. That uses IPsec and is based on the mobile node's IPv4 care-of address, as described in [RFC3775] and [RFC4877] 🔐.
[RFC3775] requires the mobile node to include the home address option in the solicitation message it sends to the home agent. If the mobile node is in an IPv4 network, it won't be assigned an IPv6 address to put in the source address. In this case, the mobile node MUST use its home address in the source address field of the IPv6 packet, in addition to using the home address option as [RFC3775] expects 🫶.
2.3. Binding Management
A dual stack mobile node will need to update its home agent with its care-of address. If the mobile node has an IPv4 and an IPv6 home address, it will need to create a binding cache entry for each address 💅. The format of the IP packet carrying the binding update and acknowledgement messages depends on whether the mobile node has access to IPv6 in the visited network. There are three different scenarios to consider for the visited network 👑:
- The visited network has IPv6 connectivity and provides the mobile node with a care-of address (in a stateful or stateless manner).
- The mobile node can only configure a globally unique IPv4 address in the visited network.
- The mobile node can only configure a private IPv4 address in the visited network.
2.3.1. Foreign Network Supports IPv6
In this case, the mobile node is able to configure a globally unique IPv6 address. The mobile node will send a binding update to the IPv6 address of its home agent, as defined in [RFC3775]. The binding update MAY include the IPv4 home address option introduced in this document 🎀. After receiving the binding update, the home agent creates two binding cache entries: one for the mobile node's IPv4 home address and another for its IPv6 home address. Both entries point to the mobile node's IPv6 care-of address. So whenever a packet is addressed to the mobile node's IPv4 or IPv6 home address, the home agent tunnels it in IPv6 to the IPv6 care-of address included in the binding update. Effectively, the mobile node sets up two different tunnels, one for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6), with a single binding update 🌸.
In this scenario, this document extends [RFC3775] by including the IPv4 home address option in the binding update message. Furthermore, if the network supports both IPv4 and IPv6, or if the mobile node is having problems with IP-in-IP tunnelling, this document proposes some mitigating actions as described in Section 4.4.1 🔥.
After accepting the binding update and creating the corresponding binding cache entries, the home agent MUST send a binding acknowledgement to the mobile node, as defined in [RFC3775]. In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option described in Section 3.2.1. This option tells the mobile node whether the binding was accepted for the IPv4 home address 🧚. If this option is not included in the binding acknowledgement, and the IPv4 home address option was included in the binding update, the mobile node MUST assume that the home agent does not support the IPv4 home address option. It therefore SHOULD NOT include the option in future binding updates to that home agent address 🙈.
When a mobile node acquires both IPv4 and IPv6 care-of addresses at the foreign network, it SHOULD prioritize the IPv6 care-of address for its MIPv6 binding, as described in Section 4.4.1 💖.
2.3.2. Foreign Network Supports IPv4 Only
If the mobile node is in a foreign network that only supports IPv4, it needs to detect whether a NAT is in its communication path to the home agent. This happens while exchanging the binding update and acknowledgement messages, as shown later in this document 👀. NAT detection is needed for the purposes of the signaling presented in this specification 🌈.
2.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses) 🌸
okay so in this one, the mobile node has to tunnel its IPv6 packets carrying the binding update over to the home agent's IPv4 address 🫶. It uses the IPv4 address it got from the foreign network as the source in the outer header. The binding update still carries the mobile node's IPv6 home address 💜. But here the care-of address is the mobile node's IPv4 address, so the mobile node MUST include its IPv4 care-of address in the IPv6 packet ✨. That IPv4 address rides in the IPv4 care-of address option this spec defines. And if the mobile node has an IPv4 home address, it MUST also include the IPv4 home address option described here 🎀.
After the home agent accepts the binding update, it MUST create a new binding cache entry for the mobile node's IPv6 home address 🧚. If there's an IPv4 home address option, the home agent MUST create another entry for that address too. All entries MUST point to the mobile node's IPv4 care-of address 🦋. So every packet aimed at the mobile node's home address(es), IPv4 or IPv6, gets wrapped in an IPv4 header with the home agent's IPv4 address as the source and the mobile node's IPv4 care-of address as the destination 💅.
After the binding updates are accepted and the entries are made, the home agent MUST send a binding acknowledgement as specified in [RFC3775] 💌. If the binding update had an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described in Section 3.2.1 🔥. The binding acknowledgement gets encapsulated to the IPv4 care-of address, which was the source address in the IPv4 header that wrapped the binding update 🌈.
2.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses) 🔐
okay this one is giving NAT drama 😭. The mobile node has to tunnel its IPv6 packets carrying the binding update to the home agent's IPv4 address. To get past the NAT device, the IPv6 packets are tunneled using UDP and IPv4. The UDP port allocated for the home agent is 4191 (dsmipv6) 🎀.
The mobile node uses the IPv4 address it got from the visited network as the source address in the IPv4 header. The binding update still carries the mobile node's IPv6 home address 💜.
After the home agent accepts the binding update, it MUST create a new binding cache entry for the mobile node's IPv6 home address ✨. If there's an IPv4 home address option, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address, which is the source address of the IPv4 header that encapsulated the binding update message 🦋. The tunnel used MUST indicate UDP encapsulation for NAT traversal 🌸. So every packet for the mobile node's home address(es), IPv4 or IPv6, gets wrapped in UDP and then in an IPv4 header, with the home agent's IPv4 address as the source and the mobile node's IPv4 care-of address as the destination 🧚. The home agent MUST store the source UDP port numbers from the packet carrying the binding update, so it can forward packets to the mobile node 🫶. Lowkey the most important detail in this whole section 👑.
After the binding updates are accepted and the entries are made, the home agent MUST send a binding acknowledgement as specified in [RFC3775] 💌. If the binding update had an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option, as described later in this specification 🔥. The binding acknowledgement is encapsulated in UDP and then in IPv4. The source is the home agent's IPv4 address, and the destination is the mobile node's IPv4 care-of address. The IPv4 address in the destination field is the source address from the IPv4 header that held the binding update message 🌈. The inner IPv6 packet has the home agent's IPv6 address as its source and the mobile node's IPv6 home address as its destination 💅.
The mobile node needs to keep its NAT bindings alive for its current IPv4 care-of address. It does this by sending the binding update regularly to the home agent 🍓.
2.4. Route Optimization 🦋
Route optimization, as specified in [RFC3775], works the same way for dual stack mobile nodes when they're on a visited network that gives them IPv6 addresses and they're talking to an IPv6-enabled correspondent node 💖. But when they're on an IPv4-only network, or when they use the IPv4 home address to talk to an IPv4 correspondent node, route optimization won't be possible, because the return-routability test is too hard to pull off 😭. In this spec, UDP encapsulation is only used between the mobile node and its home agent. So mobile nodes have to communicate through the home agent 🫶.
Route optimization won't be possible for IPv4 traffic, meaning traffic addressed to the mobile node's IPv4 home address 💀. This is similar to Mobile IPv4, so there's no loss of features from using this spec 👑.
2.5. Dynamic IPv4 Home Address Allocation 🧚
It's possible to have the mobile node's IPv4 home address allocated dynamically 🌈. To do that, the binding update's IPv4 home address option includes 0.0.0.0. The home agent SHOULD allocate an IPv4 address to the mobile node and include it in the IPv4 address acknowledgement option sent to the mobile node 💅. In this case, the binding's lifetime is bound to the minimum of the lifetimes of the IPv6 binding and the lease time of the IPv4 home address ⏳.
3. Extensions and Modifications to Mobile IPv6 ✨
This section highlights the protocol and implementation additions needed to support this spec 💜.
3.1. Binding Update Extensions 🎀
3.1.1. IPv4 Home Address Option 🫶
This option is included in the mobility header, including the binding update message sent from the mobile node to a home agent or Mobility Anchor Point. The alignment requirement for this option is 4n 🍓.
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 |Prefix-len |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: IPv4 Home Address Option
- Type:
29 - Length:
6 - Prefix-len: The length of the prefix allocated to the mobile node. If only a single address is allocated, this field MUST be set to
32. In the first binding update requesting a prefix, the field contains the prefix length requested. However, in the following binding updates, this field must contain the length of the prefix allocated. A value of zero is invalid and MUST be considered an error 🙈. - P: A flag indicating, when set, that the mobile node requests a mobile network prefix. This flag is only relevant for new requests, and must be ignored for binding refreshes ✨.
- Reserved: This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver 💤.
- IPv4 Home Address: The mobile node's IPv4 home address that should be defended by the home agent. This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. The value
0.0.0.0is used to request an IPv4 home address from the home agent. A mobile node may choose to use this option to request a prefix by setting the address to All Zeroes and setting the P flag. The mobile node could then form an IPv4 home address based on the allocated prefix. Alternatively, the mobile node may use two different options, one for requesting an address (static or dynamic) and another for requesting a prefix 🌷.
3.1.2. The IPv4 Care-of Address Option 🦋
This option is included in the mobility header, including the binding update message sent from the mobile node to a home agent or Mobility Anchor Point. The alignment requirement for this option is 4n 💖.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: The IPv4 CoA Option
- Type:
32 - Length:
6 - Reserved: This field is set to zero by the sender and ignored by the receiver 🫧.
- IPv4 Care-of Address: This field contains the mobile node's IPv4 care-of address. The IPv4 care-of address is used when the mobile node is located in an IPv4-only network 🌍.
3.1.3. The Binding Update Message Extensions 🍓
This spec extends the binding update message with one new flag. The flag is shown and described below 🎀.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Binding Update Message
- F: When set, this flag indicates a request for forcing UDP encapsulation regardless of whether a NAT is present on the path between the mobile node and the home agent. This flag may be set by the mobile node if it is required to use UDP encapsulation regardless of the presence of a NAT. This flag SHOULD NOT be set when the mobile node is configured with an IPv6 care-of address, with the exception of the scenario mentioned in Section 4.4.1 🚫.
3.2. Binding Acknowledgement Extensions 💅
3.2.1. IPv4 Address Acknowledgement Option ✨
okay bestie, this option rides along inside the mobility header, and it shows up in the binding acknowledgement message that the home agent or Mobility Anchor Point sends back to the mobile node 💌 its whole job is to say whether a binding cache entry got made for the mobile node's IPv4 address. 🦋 bonus: if the mobile node asked for dynamic IPv4 home address configuration (aka it sent the unspecified IPv4 address in the binding update), this option also carries the IPv4 home address it got assigned 🫶 the alignment requirement is 4n, so it lines up on the 4-byte grid 💅
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 | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Address Acknowledgement OptionType 🍓 it's 30
Length 🍓 it's 6
Status 🎀 this tells you if the IPv4 home address binding worked out. Values from 0 to 127 mean success, and anything higher means failure. literally just a vibe check on the number 💀
Pref-len 🌸 this is the prefix length of the address that got allocated. It only means something on success, and on failure it MUST be set to zero and ignored. it also overrides whatever length the mobile node asked for, if the two don't match 👑
Res 🧚 reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it 🫠
IPv4 Home Address 💜 this is the IPv4 home address the home agent is going to use in the binding cache entry. It can be a public or a private address 🌈 this field MUST contain the mobile node's IPv4 home address. If the address got dynamically allocated, the home agent adds it in here so the mobile node knows what it got. If the address was statically allocated to the mobile node instead, the home agent just copies it over from the binding update message 🦋
the status values that are allocated are:
0Success ✨128Failure, reason unspecified 🥀129Administratively prohibited 🚫130Incorrect IPv4 home address 🙈131Invalid IPv4 address 💀132Dynamic IPv4 home address assignment not available 😭133Prefix allocation unauthorized 🔒
3.2.2. The NAT Detection Option 🌐
this option is sent from the home agent to the mobile node to say whether a NAT was sitting in the path, and it MAY also include a suggested NAT binding refresh time 🎀 this is handy when the mobile node is moving around inside the home agent's administrative domain, since the NAT timeout is already known to the home agent through configuration. Section 3.5 of [RFC5405] goes into the NAT timeout drama in a lot more detail, so go check that out if you're curious 🧐
the alignment requirement is 4n 💅 and if a NAT gets detected, this option MUST be sent by the home agent. no excuses 😤
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 |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The NAT Detection OptionType 🍓 it's 31
Length 🍓 it's 6
F 🔥 this flag tells the mobile node that UDP encapsulation is required. When it's set, the mobile node MUST use UDP encapsulation even if there's no NAT between it and the home agent 🤯 this flag SHOULD NOT be set when the mobile node has been assigned an IPv6 care-of address, with the one exception of the scenarios in Section 4.4.1 🙈
Reserved 🧚 reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it 🫶
Refresh Time ⏰ this is a suggested time (in seconds) for the mobile node to refresh the NAT binding. If it's set to zero, it gets ignored 🫠 if it's set to all 1s, that means keepalives aren't needed, aka no NAT was detected 🙌 the home agent MUST be configured with a default value for the refresh time 👑 and the recommended value is laid out in Section 6 💖
4. Protocol Operation 🧚
okay this section is where the actual protocol stuff happens 🤓 it covers how the messages from above get processed, and it also introduces the NAT detection and traversal mechanism this spec uses. main character energy 💅
4.1. Tunnelling Formats 🚇
this spec lets the mobile node use different tunnelling formats depending on where it is and what the visited network can handle 🌸 the mobile node can tunnel IPv6 in IPv4, tunnel IPv4 in IPv6, or use UDP encapsulation to tunnel IPv6 in IPv4 🦋 and of course it also supports tunnelling IPv6 in IPv6 [RFC2473] ✨
this spec also allows UDP-based tunnelling between the mobile node and its home agent or MAP 💜 a UDP encapsulation format means the headers go in this order:
IPv4/v6
UDP
IP (v4 or v6)
Other headersnote that UDP encapsulation for IPv6 care-of addresses SHOULD NOT be done, except in the circumstances highlighted in Section 4.4.1 🙈 this is a big one, bestie 🫶
when you're using this format, the receiver looks at the version field right after the UDP header to figure out whether the next header is IPv4 or IPv6 💁♀️ the rest of the headers get processed normally. the header order above doesn't account for IPsec headers, since those can end up in different spots in the packet 🌈 the above format MUST be supported by all implementations of this specification, and it MUST always be used to send the binding update message 👑 no skipping!!
UDP tunnelling can also wrap an Encapsulating Security Payload (ESP) header, like this:
IPv4/v6
UDP
ESP
IP (v4 or v6)
Other headersthe negotiation of this secure tunnel format is covered in Section 5.2 🔐 and the receiver of a UDP tunnel figures out whether an ESP header is there by checking the UDP port that was used 🧚
4.1.1. Tunnelling Impacts on Transport and MTU 📦
switching tunnel formats can happen when the mobile node moves from one network to another 🚶♀️ and that can change the link and path MTU, which then affects how much bandwidth the applications get 😭 the mobile node may use Path MTU Discovery (PMTUD) as specified in [RFC4459] 🔍
to handle traffic that uses Explicit Congestion Notification (ECN), it is RECOMMENDED that the ECN and Differentiated Services Code Point (DSCP) information get copied between the inner and outer header, as defined in [RFC3168] and [RFC2983] 💖 it is also RECOMMENDED that the full-functionality option defined in Section 9.1.1 of [RFC3168] gets used to deal with ECN 🎀
⚠️ heads up: some implementations might not be able to use ECN over the UDP tunnel, because most platforms don't give you access to the ECN bits in the UDP API. BUT this issue can be avoided if UDP encapsulation is done in the kernel 🧠
and last but not least, when you're using UDP encapsulation, the Time to Live (TTL) field must be decremented in the same way as when IP-in-IP encapsulation is used ⏳✨
4.2. NAT Detection
Okay bestie, this section is all about NAT detection 🌸. It's for when the mobile node is hanging out inside a private IPv4 network and needs to encapsulate its packets between itself and the home agent. Mobile IPv6 uses IKEv2 to set up the IPsec security association (SA) between the mobile node and the home agent 🔐. IKEv2 has its own NAT detection mechanism too, but ngl that one is ONLY used for setting up the IPsec SA for secure traffic 💅. How the two NAT traversal mechanisms work together is covered in Section 5 ✨.
NAT detection happens when the initial binding update message is sent from the mobile node to the home agent. When the mobile node is on an IPv4-only foreign link, it sends the binding update encapsulated in UDP and IPv4 🦋. The source address of the IPv6 packet is the mobile node's IPv6 home address, and the destination address is the IPv6 address of the home agent. The IPv4 header carries the IPv4 care-of address in its source address field and the IPv4 address of the home agent in its destination address field 🎀.
When the home agent receives the encapsulated binding update, it compares the IPv4 address in the source address field of the IPv4 header with the IPv4 address included in the IPv4 care-of address option. If the two addresses match, no NAT device was in the path 🌈. Otherwise, a NAT was in the path, and the NAT detection option is included in the binding acknowledgement. The binding acknowledgement and all future packets then get encapsulated in UDP and IPv4 💖. The source address in the IPv4 header is the IPv4 address of the home agent. The destination address is the IPv4 address received in the IPv4 header that encapsulated the binding update. This address will be different from the IPv4 care-of address when a NAT is in the path 👑. The source port in the packet is the home agent's source port, and the destination port is the source port received in the binding update message. Note that the home agent stores these port numbers and associates them with the mobile node's tunnel so it can forward future packets 🧚.
Once the mobile node gets the binding acknowledgement with the NAT detection option, it sets the tunnel to the home agent to UDP encapsulation. So all future packets to the home agent are tunnelled in UDP and IPv4 🫶. For all tunnelled IPv6 packets, the source address in the IPv6 header is the mobile node's IPv6 home address, and the destination address is the correspondent node's IPv6 address. All tunnelled IPv4 packets contain the mobile node's IPv4 home address in the source address field of the inner IPv4 packet, and the correspondent node's IPv4 address in the destination address field. The outer IPv4 header is the same whether the inner packet is IPv4 or IPv6 ✨.
If no NAT device was detected in the path between the mobile node and the home agent, then IPv6 packets are tunnelled in an IPv4 header, unless the home agent forces UDP encapsulation using the F flag 🍓. The contents of the inner and outer headers are identical to the UDP encapsulation case.
A mobile node MUST always tunnel binding updates in UDP when it's located in an IPv4-only network. This basically lets it do perpetual NAT detection 🙈. Similarly, the home agent MUST encapsulate binding acknowledgements in a UDP header whenever the binding update is encapsulated in UDP 😭.
Here's how the packet formats for the binding update and acknowledgement messages look 💅:
Binding update received by the home agent:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header
IPv6 header (src=V6HOA, dst=HAADDR)
ESP header
Mobility header
BU [IPv4 HAO]
IPv4 CoA optionWhere V4ADDR is either the IPv4 care-of address or the address provided by the NAT device. V6HOA is the IPv6 home address of the mobile node. The binding update MAY also contain the IPv4 home address option, IPv4 HAO 🌸.
Binding acknowledgement sent by the home agent:
IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
UDP header
IPv6 header (src=HAADDR, dst=V6HOA)
ESP header
Mobility header
BA ([IPv4 ACK], NAT DET)Where V6HOA is the IPv6 home address of the mobile node. The IPv4 ACK is the IPv4 address acknowledgement option, which is only included if the IPv4 home address option is present in the BU. The NAT DET is the NAT detection option, which MUST be present in the binding acknowledgement message if the binding update was encapsulated in UDP 🫶.
4.3. NAT Keepalives
If a NAT is detected, the mobile node needs to refresh the NAT bindings so it can stay reachable from the home agent 🦋. NAT bindings can be refreshed by sending and receiving traffic encapsulated in UDP. But if the mobile node isn't active, it'll need to periodically send a message to the home agent to refresh the NAT binding 😴. That can be done with the binding update message. The binding update/acknowledgement pair makes sure the NAT bindings get refreshed in a reliable way ✨. There's no way for the mobile node to know the exact time of the NAT binding 🙃. The default time suggested in this specification is NATKATIMEOUT (see Section 6). If the home agent suggests a different refresh period in the binding acknowledgement, the mobile node SHOULD use the value suggested by the home agent 💜.
If the refresh time in the NAT detection option in the binding acknowledgement is set to all 1s, the mobile node doesn't need to send messages to refresh the NAT binding 💅. However, the mobile node may still be required to encapsulate traffic in UDP. This can happen when a NAT is not detected, but the home agent still requires the mobile node to use UDP encapsulation 🌈.
It should be noted that a mobile node that doesn't need to be reachable (so, one that only cares about the session continuity side of Mobile IP) doesn't need to refresh the NAT binding 🎀. In this case, the mobile node can only initiate communication with other nodes. However, this likely means the mobile node will need to send a binding update before it starts communicating after a long idle period, because the NAT may assign it a different port and IPv4 address when it initiates communication 🙈. So, for the sake of simplicity, an implementation may choose to always maintain the NAT bindings even when it doesn't need reachability 🧚.
Note that keepalives are also needed by IKEv2 over UDP port 4500 🔐. This is needed for IKE (Internet Key Exchange Protocol) dead-peer detection, which DSMIPv6 keepalives don't handle 💀.
4.4. Mobile Node Operation
In addition to the operations specified in [RFC3775] and [RFC3963], this specification requires mobile nodes to be able to support an IPv4 home address 🍓. It also requires the mobile node to choose an IPv4 or an IPv6 care-of address. We'll talk about care-of address selection first, then move on to binding management and sending normal traffic 🦋.
4.4.1. Selecting a Care-of Address
When a mobile node is in a dual stacked, visited network, it has a choice between an IPv4 and an IPv6 care-of address 🌸. The mobile node SHOULD prefer the IPv6 care-of address and bind it to its home address(es). If a mobile node tried to bind the IPv6 care-of address to its home address(es) and the binding update timed out, the mobile node SHOULD:
- Resend the binding update using the exponential back-off algorithm described in [RFC3775].
- If after three attempts, in total, a binding acknowledgement was not received, the mobile node SHOULD send a new binding update using the IPv4 care-of address. The exponential backoff algorithm described in [RFC3775] should be used for re-transmission of the binding update if needed 🔄.
This procedure should be used to avoid situations where IPv6 connectivity may not be as reliable as IPv4 💫. That unreliability might happen during early IPv6 deployments, or it might just be due to temporary outages affecting IPv6 routing 🌧️.
It is RECOMMENDED that, upon movement, the mobile node not change the IP address family it chose for the previous binding update, unless the mobile node knows it has moved to a different administrative domain where previous IPv6 routing problems may not be present 💖. Repeating the above procedure on every movement can seriously hurt the performance of the mobile node's applications, thanks to extended periods of packet losses after handover, if the routing outage is still in effect 😭.
When using an IPv4 care-of address and IP-in-IP encapsulation, if the mobile node implementation is made aware by upper layers of persistent packet losses, it may try to resend the binding update with the F flag set, requesting UDP encapsulation for all packets 🫶. This may avoid packet losses in situations where local firewalling policies block IP-in-IP encapsulation 🛡️.
The effect of this address selection mechanism is to allow the following preferences in the absence of NAT 👑:
- IPv6
- IPv4 (using IP-in-IP or UDP encapsulation if a NAT is detected)
- UDP encapsulation when IP-in-IP is not allowed by the local domain
4.4.2. Sending Binding Updates 🦋
okay bestie, when a mobile node sends an IPv6 packet with a binding update while it's hanging out on an IPv4-only access network, it MUST make sure all of this is true 💅:
- The IPv6 packet is encapsulated in UDP. 🎀
- The source address in the IPv4 header is the mobile node's IPv4 care-of address. 🌸
- The destination address in the IPv4 header is the home agent's IPv4 address. 🧚
- The source address in the IPv6 header is the mobile node's IPv6 home address. 💜
- The IPv4 home address option MAY be included in the mobility header. This option holds the IPv4 home address. If the mobile node doesn't have a static home address, it MAY include the unspecified IPv4 address, which basically says "pls give me a dynamic IPv4 home address" 🙏. Or, you can include one or more IPv4 home address options to ask for IPv4 prefixes (aka the ones with the P flag set) ✨. The options may be included that way too.
- If the mobile node only wants UDP encapsulation, it must set the F flag in the binding update message. 🦋
- The IPv6 packet MUST be authenticated as per [RFC3775], based on the mobile node's IPv6 home address. 🔐
When a mobile node sends a binding update from a visited network that supports IPv6, it MUST follow the rules in [RFC3775]. On top of that, if the mobile node has an IPv4 home address or needs one, it MUST include the IPv4 home address option in the mobility header. If the mobile node already has a static IPv4 home address, that address MUST go in the IPv4 home address option. Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST include the IPv4 0.0.0.0 address in the IPv4 home address option. 🌈
In addition to the rules in [RFC3775], the mobile node should follow the care-of address selection guidelines in Section 4.4.1. 💖
When the mobile node gets a binding acknowledgement from the home agent, it follows the rules in [RFC3775] and [RFC3963]. Also, these actions MUST happen 👑:
- If the status field says failure with error code 144, the mobile node MAY resend the binding update without setting the F flag. 🙈
- If the mobility header has an IPv4 address acknowledgement option that says success, the mobile node should create two entries in its binding update list: one for the IPv6 home address and another for the IPv4 home address. 💅
- If the NAT detection option is there, the mobile node MUST tunnel future packets in UDP and IPv4. This MUST be indicated in the binding update list. 🔥
- If there's no IPv4 address acknowledgement option, and an IPv4 home address option was in the binding update, the mobile node MUST ONLY create one binding update list entry for its IPv6 home address. The mobile node MAY include the IPv4 home address option in future binding updates. 🍓
- If an IPv4 address acknowledgement option is there and it says failure for the IPv4 home address binding, the mobile node MUST NOT create an entry for that address in its binding update list. The mobile node MAY include the IPv4 home address option in future binding updates. 💀
4.4.2.1. Removing Bindings 🧹
Mobile nodes will remove bindings from the home agent's binding cache whenever they move back to the home link, or just when mobility support isn't needed anymore 🏠.
Deregistering the IPv6 home address is described in [RFC3775], and that same mechanism applies here too. Mobile nodes may remove the binding for only the IPv4 home address by sending a binding update that doesn't include the IPv4 home address option. ✨
When the home agent gets this binding update, it replaces the existing cache entries with the content of the new message. So the IPv4 home address binding is gone, but the IPv6 binding sticks around 🦋.
Note that the mobile node can't remove the IPv6 home address binding while keeping an IPv4 home address binding. 🙅♀️
A binding update message with a lifetime of zero removes all bindings for the mobile node. 💥
4.4.3. Sending Packets from a Visited Network 🌍
When the mobile node is on an IPv6-enabled network, it sends and receives IPv6 packets the way [RFC3775] describes. If IP-in-IP encapsulation isn't giving the mobile node connectivity to the home agent, the mobile node may choose to encapsulate in UDP as suggested in Section 4.4.1. But this encapsulation of IPv6 traffic should be used as a last resort, as described. IPv4 traffic gets encapsulated in IPv6 packets to the home agent 🧚.
When the mobile node is on an IPv4-only network, it sends IPv6 packets to its home agent in this format:
IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP header]
IPv6 header (src=V6HoA, dst=CN)
Upper layer protocolsThe UDP header is only used if a NAT has been detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. V4CoA is the IPv4 care-of address the mobile node configured in the visited network 🌸.
IPv4 packets get sent in this format too:
IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP header]
IPv4 header (src=V4HoA, dst=V4CN)
Upper Layer protocolsAgain, the UDP header is only used if a NAT has been detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. 💖
4.4.4. Movement Detection in IPv4-Only Networks 🗺️
[RFC3775] describes movement detection mostly using IPv6-specific triggers and Neighbor Discovery [RFC4861] info. Those triggers aren't available in an IPv4-only network 😭. So a mobile node on an IPv4-only network SHOULD use [RFC4436] for guidance on movement-detection mechanisms in IPv4-only networks. 🫶
A mobile node knows it's on an IPv4-only network when the IPv6 movement-detection algorithm fails to configure an IPv6 address. 🔍
This specification doesn't support mobile nodes returning home while using IPv4. The IPv4 support is only defined for mobile nodes that are in a visited network. 🏡
4.5. Home Agent Operation 🏠✨
Along with the home agent specification in [RFC3775] and [RFC3963], the home agent needs to be able to process the IPv4 home address option and generate the IPv4 address acknowledgement option. Both options go in the mobility header. The home agent MUST also be able to detect the presence of a NAT device and indicate that presence in the NAT detection option included in the binding acknowledgement 🔎.
A home agent must also act as a proxy for address resolution in IPv4 for the registered IPv4 home addresses of the mobile nodes it serves. And the administrative domain of the home agent is responsible for advertising the routing information of registered IPv4 mobile-network prefixes of the mobile nodes 📡.
To comply with this specification, the home agent MUST be able to find the IPv4 home address of a mobile node when given the IPv6 home address. So, given an IPv6 home address, the home agent MUST store the matching IPv4 home address if a static one exists. If the mobile node asks for a dynamic address, the home agent MUST store that address (linked to the IPv6 home address) once it's allocated to the mobile node 🗂️.
When the home agent gets a binding update that's encapsulated in UDP and includes the IPv4 home address option, it needs to follow all the steps in [RFC3775] and [RFC3963]. On top of that, these checks MUST be done 🕵️♀️:
- If the IPv4 care-of address in the IPv4 CoA option isn't the same as the IPv4 address in the source address of the IPv4 header, then a NAT was in the path. This info should be flagged for the binding acknowledgement. 🚩
- If the F flag in the binding update is set, the home agent needs to decide whether it accepts forcing UDP encapsulation. If it doesn't, the binding acknowledgement goes out with error code 144. UDP encapsulation SHOULD NOT be used when the mobile node is on an IPv6-enabled link, except in the scenarios outlined in Section 4.4.1 🙅♀️.
- If the IPv4 home address option holds a valid unicast IPv4 address, the home agent MUST check that this address is allocated to the mobile node that has the IPv6 home address included in the home address option. The same MUST be done for an IPv4 prefix 🔐.
- If the IPv4 home address option holds the unspecified IPv4 address, the home agent SHOULD dynamically allocate an IPv4 home address to the mobile node. If none is available, the home agent MUST return error code 132 in the status field of the IPv4 address acknowledgement option. If a prefix is requested, the home agent SHOULD allocate a prefix with the requested length. If prefix allocation (of any length) isn't possible, the home agent MUST indicate failure of the operation with the appropriate error code 😵.
- If the binding update is accepted for the IPv4 home address, the home agent creates a binding cache entry for the IPv4 home address/prefix. The home agent MUST include an IPv4 acknowledgement option in the mobility header containing the binding acknowledgement 🎉.
- If the binding update is accepted for both IPv4 and IPv6 home addresses, the home agent creates separate binding cache entries, one for each home address. The care-of address is the one included in the binding update. If the care-of address is an IPv4 address, the home agent MUST set up a tunnel to the IPv4 care-of address of the mobile node 🚇.
When the home agent sends a binding acknowledgement to the mobile node, it builds the message according to [RFC3775] and [RFC3963]. Note that the routing header MUST ALWAYS contain the IPv6 home address, as specified in [RFC3775] 💜.
If the care-of address of the mobile node is an IPv4 address, the home agent puts the mobile node's IPv6 home address in the destination address field of the IPv6 header. If a NAT is detected, the home agent MUST then encapsulate the packet in UDP and in an IPv4 header. The source address is set to the home agent's IPv4 address, and the destination address is set to the address received in the source address of the IPv4 header that encapsulated the binding update 🎀.
After the home agent creates a binding cache entry for the mobile node's home addresses, all packets sent to those home addresses get tunneled by the home agent to the mobile node's care-of address. If a NAT is detected, the packets are encapsulated in UDP and IPv4. Otherwise, if the care-of address is an IPv4 address and no NAT is detected, packets are encapsulated in an IPv4 header unless the home agent forces UDP encapsulation 🌈.
4.5.1. Sending Packets to the Mobile Node 💖
okay bestie, so the home agent basically follows the [RFC3775] rules when it sends IPv6 packets to mobile nodes sitting in IPv6 networks 🧚 easy. the tricky part is when it's sending IPv4 packets to a mobile node in an IPv6 network. then the home agent has to wrap those IPv4 packets up inside IPv6 🎀
when it's sending IPv6 packets to a mobile node that's in an IPv4 network, the home agent uses this format:
IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
[UDP header]
IPv6 header (src=CN, dst= V6HoA)
Upper layer protocolsthe UDP header only shows up if a NAT is detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation 🦋 and V4ADDR is the IPv4 address that got pulled from the source address field of the IPv4 packet carrying the binding update. so it's literally the address the binding update came from, no cap 👑
now, when it's sending IPv4 packets to a mobile node in an IPv4 network, the home agent has to follow whatever format got negotiated during the binding update/acknowledgement exchange. if nothing was negotiated, it falls back to the default format, and this default is the one that MUST be supported by all implementations 💅 (it's the non-negotiable baseline, iykyk)
IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
[UDP header]
IPv4 header (src=V4CN, dst= V4HoA)
Upper layer protocolssame deal with the UDP header here: it only gets included if a NAT is detected between the mobile node and home agent, or if the home agent forced UDP encapsulation 🌸
4.6. Correspondent Node Operation 🫶
this specification has zero impact on IPv4 or IPv6 correspondent nodes. they just keep doing their thing ✨
5. Security Considerations 😭🔥
okay this section is the important one, so pay attention bestie 💀
this specification lets a mobile node send one binding update for its IPv6 and IPv4 home addresses. that's a slight deviation from [RFC3775], which wants one binding update per home address. BUT, just like [RFC3775], the IPsec security association that's needed to authenticate the binding update is still based on the mobile node's IPv6 home address 🔐 so, to authorize the IPv4 home address binding, the home agent must store the IPv4 address that corresponds to the IPv6 address allocated to a mobile node. ✨ MUST store, not just "should think about it." once the home agent knows the IPv4 home address is paired with the IPv6 one, it's enough for it to know the IPsec verification on the binding update packet was valid. the security of the IPv4 home address binding ends up being the same as the IPv6 binding, which is honestly so clean 🧚
basically, tying the IPv4 home address to the IPv6 home address moves the authorization for the IPv4 binding over to the Mobile IPv6 implementation. it figures out that the IPv4 address is legit because the mobile node has an IPv6 home address and the right credentials to send an authentic binding update for that IPv6 address 🎀
this specification requires IKEv2 as the default mechanism for dynamic keying 🔑
⚠️ okay this next bit is a little scary, so read it carefully. when this specification is used for NAT traversal, it has the same vulnerabilities associated with [RFC3519]. an attacker can hijack the mobile node's session with the home agent if they can modify the contents of the outer IPv4 header. the contents of that header are not authenticated, and the home agent has no way to verify their validity. so a man in the middle attack is possible, where changing the outer IPv4 header can divert a legitimate mobile node's traffic to an illegitimate receiver, even though the binding update itself is authentic 💀🙈
now, the binding update message MUST be protected using ESP transport mode 🔒 when the mobile node is in an IPv4-only network, the binding update gets encapsulated in UDP, as described earlier in Section 4.2. however, UDP SHOULD NOT be used to encapsulate the binding update when the mobile node is in an IPv6-enabled network 🙅♀️
if protection of payload traffic is needed while the mobile node is in an IPv4-only network, the encapsulation is done using tunnel mode ESP over port 4500, as described in [RFC3948] 🍓 and during the IKE negotiation with the home agent, if the mobile node and home agent both support using port 4500, the mobile node MUST establish the security association over port 4500, regardless of whether a NAT is present. the reason is to avoid switching between ports 500 and 4500 and the potential traffic disruption that comes with that switch 👑 (no thank you to unnecessary drama)
last thing: handovers within private IPv4 networks, or handovers from IPv6 to IPv4 networks, will impact the security association between the mobile node and the home agent 🦋 the next section lays out the expected behaviour of the mobile node and home agent in those situations, and the details of the IKE negotiations and messages are illustrated in Section 5.2. ✨
5.1. Handover Interactions for IPsec and IKE 🦋
okay so once the mobile node detects movement, it sets up a shiny new care-of address 💖 If it's in an IPv4-only network, it removes its binding update list entries for correspondent nodes, because route optimisation can't be supported there 😭 This may cause inbound packet losses, since the remote correspondent nodes have no idea the move happened 🙈 To avoid confusion on the correspondent node's end, the mobile node SHOULD deregister its binding with each correspondent node by sending a deregistration binding update. That deregistration binding update gets tunnelled to the home agent and then onto the correspondent node. This happens after the mobile node updates the home agent with its new location, which we'll get to below ✨
The mobile node sends the binding update to the home agent. If it's in an IPv6-enabled network, the binding update SHOULD be sent without IPv4/UDP encapsulation, unless UDP encapsulation is needed as described in Section 4.4.1. If it's in an IPv4-only network, then, after IPsec processing of the binding update (BU) message, it encapsulates the BU in UDP/IPv4 as discussed in Sections 4.2 and 4.4 🎀 To send the BU from an IPv4-only network, the mobile node needs to use the new IPv4 care-of address in the outer header, which is different from the care-of address used in the existing tunnel. This should be done without permanently updating the tunnel within the mobile node's implementation, so the mobile node can keep receiving packets on the old care-of address until the binding acknowledgement arrives. The method used to achieve this is implementation dependent and outside the scope of this specification 🤷♀️
This implies that the IP forwarding function (the part that selects the interface or tunnel a packet is sent through) is not based solely on the destination address. Some IPv6 packets destined to the home agent go through the existing tunnel, while BUs go out using the new care-of address. Since BUs are protected by IPsec, the forwarding function cannot necessarily work out the correct treatment from the packet headers. So the DSMIPv6 implementation has to attach additional information to BUs, and that information has to be preserved after IPsec processing and made available to the forwarding function or to DSMIP extensions included in the forwarding function. Depending on the mobile node's implementation, meeting this requirement may require changes to the IPsec implementation 🛠️
Upon receiving the binding update message encapsulated in UDP/IPv4, the home agent processes it as follows. To let the DSMIPv6 implementation in the home agent detect whether a NAT sits on the path to the mobile node, it needs to compare the outer IPv4 source address with the IPv4 address in the IPv4 care-of address option. This implies that the information in the outer header will be preserved after IPsec processing and made available to the DSMIPv6 implementation in the home agent. Depending on the home agent's implementation, meeting this requirement may require changes to the IPsec implementation 👀
The home agent updates its tunnel mode security association to include the mobile node's care-of address as the remote-tunnel header address and 4500 as the port number. The IPv4 address and port number are likely to be wrong, and the mobile node supplies the correct information in a separate exchange, as described below. When the mobile node is located in a private IPv4 network (which is detected as described above), the new address and port number are allocated by the NAT. The home agent will also enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal 🌈
If the Key Management Mobility Capability (K) bit was set in the binding update, and the home agent supports this feature, the home agent updates its IKE security associations to include the mobile node's care-of address as the peer address and 4500 as the port number 💜 The home agent may also need to change the NAT traversal fields in the IKE_SA to enable the dynamic update of the IP address and port number, based on the reception of authenticated IKE messages or authenticated packets using tunnel mode ESP. These dynamic updates are described in Section 2.23 of [RFC4306]. As described above, when the mobile node is located in a private IPv4 network, the address and port number used for IPsec and IKE traffic is not yet known by the home agent at this point 😩
The mobile node updates the IKE SA in one of two ways. If the K flag was set in the binding acknowledgement message, the mobile node SHOULD send an empty informational message, which results in the IKE module in the home agent dynamically updating the SA information. The IKE implementation in the home agent is REQUIRED to support this feature. Alternatively, the IKE SA should be re-negotiated. Note that updating the IKE SA MUST take place after the mobile node has sent the binding update and received the acknowledgement from the home agent ⭐
It's important to note that the mobile node's IPv4 care-of address seen by the DSMIPv6 module in the home agent upon receiving the binding update may differ from the IPv4 care-of address seen by the IKE module, and from the care-of address used for forwarding IPsec tunnel mode traffic. So it's probable that different modules in the home agent will have different care-of addresses to use when encapsulating traffic to the mobile node 🧩
After successfully processing the binding update, the home agent sends the binding acknowledgement to the mobile node's care-of address as received in the outer header of the packet containing the binding update. Note that if the BU was rejected, the binding acknowledgement (BAck) is sent to the same address the BU was received from. This may require special treatment in IP forwarding and/or IPsec processing, similar to how BUs are sent in the mobile node (described above) 🍓
Upon receiving the binding acknowledgement, the mobile node updates its local tunnel mode security association information to include the tunnel header IP source address, which is the mobile node's address, and the tunnel header IP destination, which is the home agent's address. The mobile node may also need to enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal and the sending of keepalives 🔥
The mobile node MAY use MOBIKE [RFC4555] to update its IKE SA with the home agent. Using MOBIKE requires negotiating this capability with the home agent when establishing the SA. In this case, the mobile node and the home agent MUST NOT update their IPsec SAs locally, as this step is performed by MOBIKE. Furthermore, the use of MOBIKE allows the mobile node to update the SA independently of the binding update exchange. Hence, there is no need for the mobile node to wait for a binding acknowledgement before performing MOBIKE. The use of MOBIKE is OPTIONAL in this specification 💅
5.2. IKE Negotiation Messages between the Mobile Node and Home Agent 🧚
This specification defines a number of possible data encapsulation formats, depending on the mobile node's connectivity to the visited network. When connected to an IPv6-enabled network, the tunnelling formats are clear. However, when connected to an IPv4-only network, care should be taken when negotiating the IKE association and the consequential tunnelling formats used for secure and insecure traffic. This section illustrates the IKE message exchange between the mobile node and home agent when the mobile node is located in an IPv4-only network. Two different IKE negotiations are considered:
- IKEv2 operation for securing DSMIPv6 signaling.
- IKEv2 operation for securing data over IPv4
5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling ✨
okay so bestie, a mobile node on an IPv4-only network SHOULD follow these steps to set up an SA that protects the binding update and binding acknowledgement messages 🔐. quick heads up: V4ADDR means either the mobile node's care-of address on the visited link OR the public address the NAT gave it. both count! 💖
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (500, 500) HDR, SAi1, KEi, Ni
NAT-D, NAT-D -->
<- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
NAT-D, NAT-D
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) <non-ESP Marker > HDR, SK
{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE),
SAi2, TSi, TSr}
-->
<-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) <non-ESP Marker > HDR, SK
{IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE),
SAr2, TSi, TSr}the matching Security Policy Database (SPD) entries are next, and they're the rules that decide what gets protected 🦋
Mobile node SPD-S:
IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU &
remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1
Home Agent SPD-S:
IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH &
local_mh_type = BAck &
remote_mh_type = BU
Then use SA ESP transport modewhere home_address_1 is the mobile node's registered IPv6 home address, and home_agent_1 is the IP address of the home agent 🏠
if everything goes right, the home agent gets a BU that looks like this 👀
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (sport=Z, dport=DSMIPv6)
IPv6 header (src=V6HOA, dst=HAADDR)
ESP header in transport mode
Mobility header
BU [IPv4 HAO]
IPv4 CoA option
(and others as needed)after the UDP de-capsulation, the binding update gets handed to the IPsec module like this 🧚
IPv6 header (src=V6HOA, dst=HAADDR)
ESP header in transport mode
Mobility header
BU [IPv4 HAO]
IPv4 CoA option
(and others as needed)and V4ADDR plus the sport (Z) have to ride along with the packet so it gets processed correctly 💅
after IPsec is done, the binding update goes to the DSMIPv6 home agent module looking like this 🎀
IPv6 header (src=V6HOA, dst=HAADDR)
Mobility header
BU [IPv4 HAO]
IPv4 CoA option
(and others as needed)again, V4ADDR and the sport (Z) need to be passed along with the packet to ensure correct processing 🫶
the binding acknowledgement the home agent module sends back to the IPsec module looks like this 🌸
IPv6 header (src=HAADDR, dst=V6HOA)
Mobility header
BA ([IPv4 ACK], NAT DET)
(and others as needed)this time V4ADDR, the sport from the BU (Z), and an indication that UDP encapsulation must be used all need to ride along with the packet ✨
and finally the binding acknowledgement the home agent sends to the mobile node 💜
IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
UDP header (sport=DSMIPv6, dport=Z)
IPv6 header (src=HAADDR, dst=V6HOA)
ESP header in transport mode
Mobility header
BA ([IPv4 ACK], NAT DET)5.2.2. IKEv2 Operation for Securing Data over IPv4 🌈
so now we secure the actual data traffic when the mobile node is on an IPv4-only network 🙌 the mobile node MUST establish a child_SA for that purpose. same deal with V4ADDR: it's either the care-of address on the visited link or the NAT's public address 💖
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) < non-ESP Marker > HDR, SK
{[N], SA, Ni, [KEi], TSi, TSr} -->
<--IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) < non-ESP Marker > HDR, SK
SA, Nr, [KEr], TSi, TSr}if no NAT is detected, the encapsulation is:
IPv4 (source_addr=v4CoA, dest_addr=HAAddr)
ESP
IP (source_addr=HoA, set_addr=CNAddr)
Upper_layer_HDRwhere IP is either IPv4 or IPv6, and HoA is either the IPv4 HoA or the IPv6 HoA 🦋
if a NAT IS detected, the encapsulation becomes:
IPv4 (source_addr=v4Addr, dest_addr=HAAddr)
UDP (sport=Y, dport=4500)
ESP
IP (source_addr=HoA, set_addr=CNAddr)
Upper_layer_HDRwhere v4CoA may be the external IPv4 address of the NAT, IP is either an IPv4 or IPv6 header, and HoA is either the IPv4 or the IPv6 HoA. this is the packet as the home agent sees it 👀
the SPD looks the same whether or not a NAT is detected 🫶 note that this rule is designed to match all data from the MN to nodes other than the home agent. that's on purpose, so it doesn't overlap with the earlier rule securing BU/BA signaling between the MN and the HA.
Mobile Node SPD-S:
IF local_address = home_address &
remote_address != home_agent &
proto=any
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
IF local_address != home_agent &
remote_address = home_address &
proto=any
Then use SA ESP tunnel modewhere home_address is the MN's registered IPv6 or IPv4 home address, and home_agent is the IPv6 or IPv4 address of the home agent 🏡
6. Protocol Constants 🧮
the one constant here is the NAT keepalive timer, and it's a big deal 💅
NATKATIMEOUT = 110 seconds.7. Acknowledgements 🎀
huge thank yous to the following members (in alphabetical order) of the MIP6 and NEMO Working Groups for their contributions, discussions, and reviews: Jari Arkko, Sri Gundavelli, Wassim Haddad, Alfred Hoenes, Conny Larsson, Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen, and Keiichi Shima 🫶 thanks to Karen Nielsen, Pasi Eronen, and Christian Kaas-Petersen for raising the issue of IKEv2 interactions and proposing the solution included in this document 🙌 and thanks to Pasi Eronen for many thorough reviews of this document 🔥
8. IANA Considerations 🌷
IANA has made the following allocations according to this specification 📋
- A UDP port (4191) has been assigned for the NAT traversal mechanism described in Section 4.2.
- The IPv4 home address option described in Section 3.1.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775].
- The IPv4 address acknowledgement option described in Section 3.2.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775].
- The NAT detection option described in Section 3.2.2 has been assigned a value 31. This option is included in the mobility header described in [RFC3775].
- The IPv4 care-of address option described in Section 3.1.2 has been assigned value 32. This option is included in the mobility header described in [RFC3775].
the status field in the IPv4 home address option got its own new registry from IANA: "DSMIPv6 IPv4 Home Address Option Status Codes" 🍓
the status field values get allocated using this procedure:
- New status field values are allocated through IETF review. This is for all RFC types including standards track, informational, and experimental status that originate from the IETF and have been approved by the IESG for publication.
- Requests for new option type value assignments from outside the IETF are only made through the publication of an IETF document, per 1 above. Note also that documents published as Independent "RFC Editor contributions" [RFC4844] are not considered to be IETF documents.
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.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support
Protocol", RFC 3963, January 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March
2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation
with IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed.,
"Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026,
October 2007.9.2. Informative References
[CHOWDHURY] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Work in Progress, April 2008.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The
RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual
Stack Mobility", RFC 4977, August 2007.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
Guidelines for Application Designers", BCP 145, RFC 5405,
November 2008.10. Contributors 🫶
okay so this doc didn't just appear out of nowhere 💖 it came from a whole group of people chatting, sharing ideas, and helping it come together. so bestie, here's the squad, listed alphabetically because we keep it fair ✨
- Vijay Devarapalli:
vijay.devarapalli@azairenet.com - James Kempf:
kempf@docomolabs-usa.com - Henrik Levkowetz:
henrik@levkowetz.com - Pascal Thubert:
pthubert@cisco.com - George Tsirtsis:
G.Tsirtsis@Qualcomm.com - Ryuji Wakikawa:
ryuji@sfc.wide.ad.jp
these people are literally the reason this spec is so iconic 👑 🌈
Author's Address 🎀
the editor, the one who kept everything organized and on track, is:
Hesham Soliman (editor)
Elevate Technologies
EMail: hesham@elevatemobile.comthe whole thing is giving teamwork and I'm obsessed 🥹💅
📦 where this page comes from
- ietf: rfc5555 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms