RFC 5648
Multiple Care-of Addresses Registration
Multiple Care-of Addresses Registration 🦋
okay bestie, the header is giving 🎀 This is RFC 5648, a Standards Track doc from October 2009. The editor is R. Wakikawa, Ed. (Toyota ITC), and the co-authors are V. Devarapalli (Wichorus), G. Tsirtsis (Qualcomm), T. Ernst (INRIA), and K. Nagami (INTEC NetCore). It doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅
Abstract ✨
okay so the current Mobile IPv6 spec says a mobile node may have a bunch of care-of addresses, but only ONE of them, called the primary care-of address, can be registered with its home agent and the correspondent nodes 🙈 that's lowkey a bummer, because for cost, bandwidth, delay, and stuff, it's really useful for the mobile node to get Internet access through multiple accesses at the same time. Then it would have multiple active IPv6 care-of addresses. This doc proposes extensions to Mobile IPv6 so you can register and use multiple care-of addresses 🔥 The extensions can also be used by mobile routers running the NEMO (Network Mobility) Basic Support protocol. It's giving main character energy 👑
Status of This Memo 🌸
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the 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 and License 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the BSD License 🫶
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Overview ...............................................4
4. Mobile IPv6 Extensions .........................................10
4.1. Binding Cache Structure and Binding Update List ...........10
4.2. Binding Update Message ....................................10
4.3. Binding Identifier Mobility Option ........................11
4.4. New Status Values for Binding Acknowledgement .............13
5. Mobile Node Operation ..........................................14
5.1. Management of Care-of Address(es) and Binding
Identifier(s) .............................................14
5.2. Binding Registration ......................................15
5.3. Bulk Registration .........................................16
5.4. Binding De-Registration ...................................16
5.5. Returning Home with Complete Binding
De-Registration: Using a Single Interface .................17
5.5.1. Using Only the Interface Attached to the
Home Link ..........................................17
5.5.2. Using Only the Interface Attached to the
Visited Link .......................................17
5.6. Returning Home: Simultaneous Home and Visited Link
Operation .................................................18
5.6.1. Problems of Simultaneous Home and Foreign
Attachments ........................................18
5.6.2. Overview and Approach ..............................18
5.6.3. Home Binding Support ...............................19
5.6.4. Sending Packets from the Home Link .................20
5.6.5. Leaving from the Home Link .........................20
5.7. Receiving Binding Acknowledgement .........................21
5.8. Receiving Binding Refresh Request .........................22
5.9. Bootstrapping .............................................22
6. Home Agent and Correspondent Node Operation ....................22
6.1. Searching Binding Cache with Binding Identifier ...........22
6.2. Processing Binding Update .................................23
6.3. Sending a Binding Acknowledgement for Home Link
Registration ..............................................25
6.4. Sending Binding Refresh Request ...........................27
6.5. Receiving Packets from Mobile Node ........................27
7. Network Mobility Applicability .................................27
8. DSMIPv6 Applicability ..........................................27
8.1. IPv4 Care-of Address Registration .........................28
8.2. IPv4 Home Address Management ..............................29
9. IPsec and IKEv2 Interaction ....................................30
9.1. Use of Care-of Address in the IKEv2 Exchange ..............31
9.2. Transport Mode IPsec-Protected Messages ...................31
9.3. Tunnel Mode IPsec-Protected Messages ......................31
9.3.1. Tunneled Home Test Init and Home Test Messages .....31
9.3.2. Tunneled Payload Traffic ...........................32
10. Security Considerations .......................................33
11. IANA Considerations ...........................................34
12. Acknowledgements ..............................................35
13. References ....................................................35
13.1. Normative References .....................................35
13.2. Informative References ...................................351. Introduction ✨
A mobile node may use various kinds of network interfaces to get durable, wide-area network connectivity. This is increasingly true now that mobile nodes have multiple interfaces, like 802.2, 802.11, 802.16, cellular radios, and more 📱 The reasons for using multiple points of attachment, and the benefits, are covered in [MOTIVATION]. When a mobile node with multiple interfaces uses Mobile IPv6 [RFC3775] for mobility management, the problem is that it can't use all of those interfaces to send and receive packets and still get the session continuity Mobile IPv6 provides 😭 That's because Mobile IPv6 only lets the mobile node bind ONE care-of address at a time with its home address. For a deeper dive into using multiple interfaces and addresses with Mobile IPv6, see [MIP6ANALYSIS] 🧠
This document extends Mobile IPv6 so a mobile node can register multiple care-of addresses for a home address and create multiple binding cache entries 💅 Each binding the mobile node wants to create gets its own new Binding Identification (BID) number, and that number is sent in the Binding Update. The home agent that receives the Binding Update creates a separate binding for each BID, and the BID is stored in the matching binding cache entry. Now the BID can be used to tell individual bindings apart. The same extensions can also be used in Binding Updates sent to correspondent nodes 🦋
2. Terminology 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Terms used in this document are defined in [RFC3775], [RFC3753], and [RFC4885]. On top of those, or instead of some of them, the following terms are defined or redefined 🌈
Binding Identification Number (BID)
The BID is an identification number used to tell apart multiple bindings registered by the mobile node. Giving each binding a distinct BID lets a mobile node register multiple binding cache entries for a given home address. BIDs assigned to the same home address must not be duplicated at the same time. The value zero is reserved for future extensions. Each BID is generated and managed by a mobile node. The BID is stored in the Binding Update List and sent by the mobile node in the Binding Update. A mobile node may change the value of a BID at any time according to its administrative policy, for instance to protect its privacy 🙈 An implementation must carefully assign the BID so it keeps using the same BID for the same binding even when that binding's status changes. More details are in Section 5.1 ✨
Binding Identifier Mobility Option
The Binding Identifier mobility option is used to carry the BID information 🍓
Bulk Registration
A mobile node can register multiple bindings at once by sending a single Binding Update. It can also replace some or all of the bindings at the home agent with new ones by using bulk registration. Bulk registration is only supported for home registration (i.e., with the home agent), as explained in Section 5.3. A mobile node must not perform the bulk registration mechanism described in this specification with a correspondent node 💖
3. Protocol Overview ✨
okay so bestie, this is where the BID (Binding Identification number) shows up 🦋 It's a brand new extension that lets the home agent tell apart multiple bindings that all belong to the same home address 💖 If a mobile node has several IPv6 global addresses on one or more of its interfaces, it can register all of them with its home agent as care-of addresses. Iconic behaviour, honestly 👑
If the mobile node wants to register multiple bindings, it MUST generate a BID for each care-of address and store the BID in the Binding Update List 🎀 Once that's set up, the node can manipulate each binding on its own using the BIDs 🧚 Then it registers its care-of addresses by sending a Binding Update that carries a Binding Identifier mobility option 💅
The BID rides inside that Binding Identifier mobility option 🌸 When the home agent gets a Binding Update with that option, it MUST copy the BID from the option into the matching field in the binding cache entry 🫶 Now here's the plot twist 😭 If there's already a binding cache entry for the mobile node and the BID in the Binding Update doesn't match the one in the existing entry, the home agent MUST create a brand new binding cache entry for that new care-of address and BID 🔥 The mobile node can register several care-of addresses all at once in a single Binding Update, or do it separately with individual Binding Updates, whichever it likes ✨
Now, if the mobile host wants to register its binding with a correspondent node, it has to do return routability operations as described in [RFC3775] 🌈 That means managing a Care-of Keygen token per care-of address and swapping Care-of Test Init and Care-of Test messages with the correspondent node for each care-of address 💜 The mobile node MAY reuse the same BID it used with the home agent for a particular care-of address 🦋 For protocol simplicity, bulk registration to correspondent nodes is NOT supported in this document 🙈 Why? Because the return routability mechanism from [RFC3775] can't easily be extended to verify multiple care-of addresses stored in a single Binding Update 💀
Figure 1 shows the setup where the mobile node picks up multiple care-of addresses at foreign links, and it can use all of them 🍓 Here the home address of the mobile node (MN) is 2001:db8::EUI 🎀 The mobile node has 3 different interfaces and might acquire care-of addresses 1-3 (CoA1, CoA2, CoA3) 🌸 It assigns BID1, BID2, and BID3 to each care-of address 💖
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +--------+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
Figure 1: Multiple Care-of Addresses RegistrationIf the mobile node decides to act like a regular mobile node that's compliant with [RFC3775], it sends a Binding Update without any Binding Identifier mobility options 🙈 The receiver of that Binding Update deletes all the bindings registered with a BID and keeps only a single binding for the mobile node 🧹 Also, the mobile node can keep using the BID even when it only has one binding that's active 💅
Binding cache lookup is done based on the home address and BID information whenever a BID is available 🔍 This is different from RFC 3775, where only the home address gets used for the lookup 💁♀️ The lookup happens for either protocol signaling or data packets 📦 For protocol signaling, like a Binding Update, the BID SHOULD always be carried in a BID sub-option in the signaling 🫶 So a correspondent binding cache that matches the specified BID MUST be found in the binding cache database 🔥 For data packets, though, no BID is carried in the packet 😭 The lookup might involve policy or flow filters to retrieve a correspondent BID per packet, in cases where some policy or flow filters are used to send a certain packet or flow to a particular care-of address 🌈 However, binding cache lookup using policy or flow filters is out of scope for this document 🚫 If no such mechanism is available and no BID is found for a packet, a node SHOULD use the binding that was last verified by receiving data packets or signaling from the mobile node ✨ If the lookup for data packets using the combination of home address and BID doesn't return a valid binding cache entry, the home agent SHOULD do the lookup based only on the home address, as described in [RFC3775] 🎀
Also, to avoid problems with upper-layer protocols and TCP in particular, a single packet flow identified by the 5-tuple SHOULD only be sent to a single care-of address at a time 🦋 Be consistent, bestie 💅
The mobile node may return to the home link through one of its interfaces 🏠 There are two options when it comes back home, and Sections 5.5.1 and 5.6 walk through the returning-home procedures in more detail 📖
- The mobile node uses only the interface it attaches to the home link with, and takes back full ownership of its HoA (home address) on the home link 👑 This is shown in Figure 2 🌸 It de-registers all bindings with the home agent related to all care-of addresses 🧹 The interfaces still attached to visited links are no longer going to receive any encapsulated traffic from the home agent 😭 Meanwhile, the mobile node can keep talking to correspondent nodes from the other interfaces attached to foreign links using route optimization 🚀 Even when it's attached to the home link, it can still send Binding Updates for other active care-of addresses (CoA1 and CoA2) to correspondent nodes 💖 Since the correspondent node has bindings, packets get routed from and to each care-of address directly 🧚
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
none
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
Figure 2: Using Only an Interface Attached to the Home Link- The mobile node may use the interface attached to the home link and the interfaces still attached to visited links at the same time, as shown in Figure 3 🎀 There are two possible topologies, depending on whether or not the home agent is the only router on the home link 🧐 Neighbor Discovery [RFC4861] works differently in the two topologies 🫠 More details are in Section 5.6 📖 In both topologies, the home agent and the correspondent node have the binding entries listed in Figure 3 in their binding cache database 💜 The home agent also knows the mobile node is attached to the home link 🏡 All traffic from the Internet is intercepted by the home agent first and routed either to the interface attached to the home link or to one of the foreign links 🌈 How the home agent decides which flow goes to the home link interface and which goes to a foreign link is out of scope for this document 🚫
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
Figure 3: Simultaneous Home and Visited Link OperationThis specification keeps backwards compatibility with [RFC3775] 🫶 If a receiver (either a home agent or a correspondent node) doesn't support this specification, it doesn't understand the Binding Identifier mobility option 🙈 It skips the unknown mobility option (the Binding Identifier mobility option) and processes the Binding Update as defined in [RFC3775] 💅 To keep backwards compatibility with [RFC3775], when a mobile node sends a Binding Update with the extensions in this document, the receiver needs to reflect the Binding Identifier mobility option in the Binding Acknowledgement 🔁 If the mobile node finds no Binding Identifier mobility options in the received Binding Acknowledgement, it assumes the other end doesn't support this specification 😭 In that case, the mobile node needs to fall back to a legacy [RFC3775]-compliant mobile node 🕰️ If it's a home registration, the mobile node MAY try to discover another home agent that supports the Binding Identifier mobility option for the home registration 🔍
4. Mobile IPv6 Extensions 💖
This section sums up the extensions to Mobile IPv6 that are needed to manage multiple bindings 🧚
4.1. Binding Cache Structure and Binding Update List 🗂️
okay so first things first, the BID has to be stored in the binding cache AND the Binding Update List structure. no skipping it, bestie 💅
The sequence number value MUST be shared among all the Binding Update List entries related to Binding Updates sent to a particular home agent or correspondent node. 🔢 So every time a mobile node sends a Binding Update, whether it's an individual one or a bulk one, the sequence number goes up by one. ✨ And when a home agent gets an individual Binding Update, it should update the sequence number for all the bindings for that particular mobile node, using the sequence number from the one it just received. it's giving teamwork 🫶
4.2. Binding Update Message 💌
this spec adds a brand new flag to the Binding Update message. here's the layout, it's so pretty 🎀
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Update MessageOverwrite (O) flag 🔄
when this flag is set, all the binding cache entries for a mobile node get replaced by the new entries that this Binding Update is registering. 💫 Only use it when the BID mobility option is riding along with the Binding Update.
Reserved 🫥
it's a 6-bit Reserved field, so just leave it alone.
4.3. Binding Identifier Mobility Option 🏷️
the Binding Identifier mobility option shows up in the Binding Update, Binding Acknowledgement, Binding Refresh Request, and Care-of Test Init and Care-of Test messages. 📬 It has an alignment requirement of 2n if the Care-of Address field isn't there. Otherwise, the alignment requirement is 8n + 2. 📏
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 = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 care-of address (CoA) :
+ +
+---------------------------------------------------------------+
Figure 5: BID Mobility OptionType 🔢
the Type value for Binding Identifier is 35. 🦋
Length 📐
this is an 8-bit unsigned integer, and it's the length of the option in octets, not counting the Type and Length fields. 🧮 It MUST be set to either 4, 8, or 20, depending on the Care-of Address field. When the care-of address isn't carried by this option, the length value MUST be set to 4. If the IPv4 care-of address is stored in the Care-of Address field, the length MUST be 8. Otherwise, the length value MUST be set to 20 for IPv6 care-of addresses.
Binding ID (BID) 🆔
this is the BID assigned to the binding that the care-of address in the Binding Update or the Binding Identifier mobility option points to. It's a 16-bit unsigned integer. The value of zero is reserved and SHOULD NOT be used. 🚫
Status 🚦
this field is an 8-bit unsigned integer. When the Binding Identifier mobility option is included in a Binding Acknowledgement, this field overwrites the Status field in the Binding Acknowledgement, but only for this BID. ✂️ If this field is set to zero, the receiver ignores it and uses the registration status stored in the Binding Acknowledgement message instead. The receiver MUST ignore this field if the Binding Identifier mobility option isn't carried within either the Binding Acknowledgement or the Care-of Test messages. The possible status codes are the same as the status codes of the Binding Acknowledgement. 🎯 This Status field is also used to carry error information related to the care-of address test in the Care-of Test message. 🧪
Simultaneous Home and Foreign Binding (H) flag 🏠
this flag tells you the mobile node is registering multiple bindings to the home agent while it's attached to the home link. 🏡 It's only valid for a Binding Update sent to the home agent.
Reserved 🫥
it's a 7-bit Reserved field. The sender MUST initialize it to zero, and the receiver SHOULD ignore it.
Care-of Address 📍
if a Binding Identifier mobility option is included in a Binding Update for the home registration, either an IPv4 or IPv6 care-of address for the matching BID can be stored in this field. 🌍 For the binding registration to correspondent nodes (aka route optimization), only IPv6 care-of addresses can be stored here. 🛣️ If no address is specified in this field, the length of this field MUST be zero, which means it doesn't even show up in the option. And if the option is included in any message other than a Binding Update, the length of this field MUST also be zero.
4.4. New Status Values for Binding Acknowledgement 🌟
these are the brand new status values for the Status field in a Binding Acknowledgement, made for handling multiple care-of address registration. 🧩
MCOA NOTCOMPLETE (4)
this one shows up in bulk registration when not every Binding Identifier mobility option got registered successfully. Some of them got rejected 😬. The error status value for each failed mobility option gets stored in the Status field of that Binding Identifier mobility option.
MCOA RETURNHOME WO/NDP (5)
when a mobile node returns home, it MUST NOT use the Neighbor Discovery Protocol (NDP) for the home address on the home link. 🏠 This is explained in more detail in Section 5.6.
MCOA MALFORMED (164)
registration failed because the Binding Identifier mobility option wasn't formatted correctly. 🙈 This value gets used in these cases:
- when the wrong length value is specified (neither 4, 8, nor 20) in the Length field of the Binding Identifier mobility option.
- when a unicast routable address is not specified in the Care-of Address field of the Binding Identifier mobility option.
- when a care-of address does not appear in the Care-of Address field of the Binding Identifier mobility option stored in an IPsec Encapsulating Security Payload (ESP)-protected Binding Update. 🔐
MCOA NON-MCOA BINDING EXISTS (165)
this one indicates that a bootstrapping multiple care-of addresses registration was performed without the 'O' flag set. 🥾
MCOA UNKOWN COA (167)
this indicates that a Binding Identifier mobility option didn't include a Care-of Address field, and the receiver has no record for the Binding ID in that same option. 🤷♀️
MCOA PROHIBITED (166)
this one implies that the multiple care-of addresses registration is administratively prohibited. 🚷
MCOA BULK REGISTRATION PROHIBITED (168)
bulk binding registration is either not permitted or not supported. 📦 Heads up, bulk registration is an optional procedure and might not be available on a home agent.
MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
simultaneous home and foreign attachment is neither supported nor permitted. 🙅♀️
5. Mobile Node Operation 🧳
5.1. Management of Care-of Address(es) and Binding Identifier(s) 🗝️
there are two cases where a mobile node might acquire several care-of addresses, and a mix of the two is also possible. 🎭 Also, a mobile node can use BID no matter how many interfaces and care-of addresses it has. Whether or not it uses BID is decided by a local configuration. ⚙️
- A mobile node is using several physical network interfaces and acquires a care-of address on each of its interfaces. 📡
- A mobile node uses a single physical network interface but receives advertisements for multiple prefixes on the link to which the interface is attached. This results in the mobile node configuring several global addresses on the interface, one from each of the announced prefixes. 🌐
the difference between those two cases is only the number of physical network interfaces, so it doesn't matter for this document. 🙌 What matters is that the mobile node has several addresses it can use as care-of addresses.
a mobile node assigns a BID to each care-of address when it wants to register them all at once with its home address. The BID MUST be unique for a given home address. The value is an integer between 1 and 65535. A zero value SHOULD NOT be used as a BID. 🔢 If a mobile node has only one care-of address, it doesn't need to assign a BID until it has multiple care-of addresses to register. At that point, all of the care-of addresses MUST be mapped to BIDs. 🗺️
when a mobile node registers a given BID for the first time, it MUST include the Care-of Address field in the Binding Identifier mobility option. 🥇 For any later registrations that either re-register or de-register the same BID, the MN doesn't need to include the Care-of Address field in the Binding Identifier mobility option. 🙆♀️
5.2. Binding Registration ✨
okay so for registering multiple care-of addresses, the mobile node MUST include a Binding Identifier mobility option(s) in the Binding Update 🎀 like it's shown in Figure 6.
when IPsec ESP is protecting the Binding Update, a care-of address MUST be carried in an alternate Care-of Address mobility option, as described in [RFC4877] 💅 BUT in this spec, the care-of address MUST be carried in the Care-of Address field of the Binding Identifier mobility option instead 🫶 and to save bits in the Binding Update, the alternate Care-of Address option MUST NOT be included. bits matter bestie 🤏
for binding registration to a correspondent node, the mobile node MUST have both active Home and Care-of Keygen tokens for Kbm (binding management key; see Section 5.2.5 of [RFC3775]) before sending the Binding Update 🔑 the care-of Keygen tokens MUST be maintained for each care-of address the mobile node wants to register to the correspondent node. the Binding Update to the correspondent node is protected by the Binding Authorization Data mobility option, and it's placed after the Binding Identifier mobility option 🧚
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header*
Mobility header
Binding Update
Mobility Options
Binding Identifier mobility option
Binding Authorization mobility option+
(*) if necessary, for home registration
(+) if necessary, for route optimizationFigure 6: Binding Update for Binding Registration 📸
if the mobile node wants to replace the existing registered bindings on the home agent with the single binding in the sent Binding Update, it sets the 'O' flag 🔥 if the 'O' flag is not set, the binding gets added to the existing bindings in the home agent. the single binding gets registered with the assigned BID. Section 6.2 walks through this registration procedure in detail 💜
5.3. Bulk Registration 🌈
bulk registration is an optimization for binding multiple care-of addresses to one home address using a single Binding Update 🧺 it's SO useful if the mobile node doesn't want to send a lot of signaling messages through an interface where the bandwidth is scarce 🥺 this document specifies bulk registration ONLY for the mobile node's home registration. a mobile node doing bulk registration with a correspondent node is out of scope 🙅♀️
to use bulk registration, the mobile node includes a Binding Identifier mobility option for each BID it wants to register in the same Binding Update message 🦋 just like with single registrations (see Section 5.1), the Care-of Address field is included for each BID registered for the first time. check Figure 7 👀 the rest of the fields and options in the Binding Update (like Lifetime, Sequence Number, and the flags in the Binding Update) are common across all care-of addresses.
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header
Mobility header
Binding Update
Mobility Options
Binding Identifier1 (including Care-of Address)
Binding Identifier2 (including Care-of Address)
Binding Identifier3 (no Care-of Address)
Binding IdentifierN (no Care-of Address)
:Figure 7: Binding Update for Bulk Registration 🎀
same energy as regular registrations 💅 if the mobile node wants to replace the existing registered bindings on the home agent with the multiple bindings in the sent Binding Update, it sets the 'O' flag in the Binding Update. otherwise, the bindings get added to the existing bindings in the home agent ✨
5.4. Binding De-Registration 🧹
when a mobile node decides to delete ALL the bindings for its home address, it sends a regular de-registration Binding Update with lifetime set to zero, as defined in [RFC3775] 🫠 the Binding Identifier mobility option is not required here.
if a mobile node wants to delete a particular binding(s) from its home agent and correspondent nodes, it sends a Binding Update with lifetime set to zero and includes a Binding Identifier mobility option(s) with the BID(s) it wants to de-register 🗑️ the receiver removes ONLY the care-of address(es) that match the specified BID(s). and since de-registration is trying to remove a BID that already exists, the sender can leave out the Care-of Address field in each Binding Identifier option, as defined in Section 5.1 🙌
5.5. Returning Home with Complete Binding De-Registration: Using a Single Interface 🏠
the mobile node may return to the home link by attaching to the home link through one of its interfaces 🏡 when the mobile node wants to return home, it should be configured with info on which interface it needs to use.
5.5.1. Using Only the Interface Attached to the Home Link 🎯
the mobile node returns home and de-registers ALL the bindings it has with the home agent, as shown in Figure 2 and as defined in [RFC3775] 💖 after the de-registration step, all the packets routed by the home agent are only forwarded to the interface attached to the home link, even if there are other active interfaces attached to the visited link(s). while the mobile node de-registers all the bindings from the home agent, it may keep registering bindings, with the correspondent node, for interfaces attached to visited links, as shown in Figure 2 🦋
5.5.2. Using Only the Interface Attached to the Visited Link 🌸
the mobile node returns home physically but shuts down the interface attached to the home link 😬 as a result, the mobile node does NOT return home even though it's attached to the home link through one of its interfaces. before shutting down the interface, any binding for the care-of address previously associated with that interface should be deleted, as defined in Section 5.4 🧹
in this scenario, even though the mobile node is connected to its home link, all of its traffic is sent and received via the home agent and its foreign links 💀
5.6. Returning Home: Simultaneous Home and Visited Link Operation 👑
5.6.1. Problems of Simultaneous Home and Foreign Attachments 🙈
the mobile node returns home and keeps using all the interfaces attached to both foreign and home links, as shown in Figure 3 🧚
in [RFC3775], the home agent intercepts packets meant for the mobile node using proxy Neighbor Discovery [RFC4861] while the mobile node is away from the home link. when the mobile node returns home, the home agent deletes the binding cache and stops proxying for the home address, so the mobile node can configure its home address on the interface attached to the home link 🏠 in this specification, a mobile node may return home and configure the home address on the interface attached to the home link, but STILL use the interfaces attached to the foreign links. in this case, a possible conflict pops up when both the home agent and the mobile node try to defend the home address 😭 if the home agent stops proxying for the home address, packets always get routed to the interface attached to the home link and NEVER to the interfaces attached to the visited links. deployments using multiple care-of addresses MUST avoid configuration conflict between the home agent and the mobile node, while still allowing simultaneous use of home and foreign links 🫶 here's how to do it:
5.6.2. Overview and Approach 🗺️
the home agent MUST intercept all the packets meant for the mobile node, whether or not the mobile node is attached to the home link, and decide whether to send the traffic directly to the home address on the link or tunnel it to the care-of address 💅
two scenarios are illustrated in Figure 3, depending on whether or not the home agent is the only router at the home link 🔍 the difference is about who defends the home address with (Proxy) Neighbor Discovery on the home link.
- Mobile node defends the home address with the regular Neighbor Discovery protocol (illustrated as topology-a in Figure 3) 💜 the home agent is the only router on the home link. so the home agent can intercept packets WITHOUT relying on the proxy Neighbor Discovery protocol, and the mobile node can manage the neighbor cache entry of the home address on the home link like a regular IPv6 node 🎀 BUT there's one limitation. if a correspondent node is located at the home link, the home agent may not intercept the packets destined to the mobile node. those packets get routed only via the home link, but honestly that's the most optimal path for the mobile node to talk to nodes on the home link ✨
- if there are routers other than the home agent on the home link, then it can't be guaranteed that all packets meant for the mobile node are routed to the home agent 😵 in this case, the mobile node MUST NOT operate the Neighbor Discovery protocol for the home address on the home link 🙅♀️ this lets the home agent keep using proxy Neighbor Discovery, so it keeps receiving ALL the packets sent to the mobile node's home address 🧲 if the home agent, based on its local policy, needs to deliver packets to the mobile node over the home link, an issue pops up about how the home agent discovers the mobile node's link-local address 🤔 this specification uses the Mobility Header Link-Layer Address option defined in [RFC5568] to carry the mobile node's link-layer address in the Binding Update 📦 likewise, the mobile node would also know the link-layer address of the default router address, so it can send packets from the home link WITHOUT Neighbor Discovery 🛰️ the link-layer address is used to transmit packets from and to the mobile node on the home link. the packets are transmitted without the Neighbor Discovery protocol by manually constructing the link-layer header 🛠️ this operation is similar to Mobile IPv6 [RFC3775] when a mobile node sends a de-registration Binding Update to the home agent's link-layer address in the operation for returning home 🦋
5.6.3. Home Binding Support 🏠💖
okay bestie, when the home binding is in use, the mobile node MUST send a registering Binding Update with a Binding Identifier mobility option with the 'H' flag set. The lifetime MUST be set to a non-zero lifetime of the home binding, and the Care-of Address field MUST be set to the home address. The mobile node registers only one home binding at a time, even if it attaches to the home link by multiple interfaces. main character energy, but only one home binding 🎀
The mobile node SHOULD also include the Mobility Header Link-Layer Address option [RFC5568] to tell the home agent its link-layer address too ✨ The option code of the Mobility Header Link-Layer Address option MUST be set to '2' (link-layer address of the mobile node). This link-layer address is required for the home agent to send the Binding Acknowledgement and to forward the mobile node's packets 🫶
According to [RFC3775], the mobile node MUST start responding to Neighbor Solicitation for its home address right after it sends the de-registration Binding Update to the home agent. BUT in this spec, the mobile node MUST NOT respond to Neighbor Solicitation before receiving a Binding Acknowledgement, since the home agent may keep proxying for the home address 🙈 If the mobile node receives the [MCOA RETURNHOME WO/NDP (5)] status value in the received Binding Acknowledgment, it MUST NOT respond to Neighbor Solicitation even after that Binding Acknowledgement. no cap, this part is so important 💅
The management of the home binding is the same as the binding management described in this specification. The home binding can be included in a bulk binding registration (Section 5.3). The MN SHOULD refresh the lifetime of the home binding by sending appropriate Binding Updates, same as any other binding 🌸
5.6.4. Sending Packets from the Home Link 📦✨
- When the mobile node receives the Binding Acknowledgement with the status value 'Binding Update Accepted' and the BID option, it can configure its home address on the interface attached to the home link and start operating Neighbor Discovery for the home address on the home link. Packets can be sent from and to the mobile node as if it were a regular IPv6 node. it's giving full IPv6 citizen 🦋
- If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in the Binding Acknowledgement, it MUST NOT operate Neighbor Discovery for the home address. When the mobile node sends packets from the interface attached to the home link, it MUST learn the link-layer address of the next hop (i.e., the default router of the mobile node). A mobile node learns the default router's link-layer address from a Source Link-Layer Address option in Router Advertisements. The mobile node sends packets directly to the default router's link-layer address, by constructing the packet to include a link-layer header with the learned link-layer address of the default router. The home agent also forwards the packet to the mobile node on the home link by using the mobile node's link-layer address. The link-layer address SHOULD be cached when the home agent receives the de-registration Binding Update message. Note that the default router MUST NOT cache the mobile node's link-layer address in the neighbor cache when it forwards the packet from the mobile node to the home agent. okay that's a lot of rules but they're all giving precision 🧚
5.6.5. Leaving from the Home Link 🚪
When the mobile node detaches from the home link, it SHOULD immediately send a Binding Update for one of the active care-of addresses with the 'H' flag unset. When the 'H' flag of the BID option is unset in any Binding Update, the home agent stops forwarding the mobile node's packets to the home link. bye home link 👋
5.7. Receiving Binding Acknowledgement 📬
The verification of a Binding Acknowledgement is the same as Mobile IPv6 (Section 11.7.3 of [RFC3775]). The operation for sending a Binding Acknowledgement is described in Section 6.2.
If a mobile node includes a Binding Identifier mobility option in a Binding Update with the 'A' flag set, a Binding Acknowledgement SHOULD carry a Binding Identifier mobility option. According to [RFC3775], the receiver of the Binding Update ignores unknown mobility options and processes the Binding Update without the unknown mobility option. So if no such mobility option is included in the Binding Acknowledgement in response to a Binding Update for a multiple care-of addresses registration, that means the originating node of the Binding Acknowledgement doesn't support processing the Binding Identifier mobility option, regardless of status value 🫠 In that case, the receiver of the Binding Update MAY create a regular binding. The mobile node then SHOULD no longer attempt a multiple care-of addresses registration with that node. If this happens with home registration, the mobile node MAY attempt to discover another home agent that supports the Binding Identifier mobility option for the home registration.
If a Binding Identifier mobility option is present in the received Binding Acknowledgement, the mobile node checks the Status field in the option. If the status value in the Binding Identifier mobility option is zero, the mobile node uses the value in the Status field of the Binding Acknowledgement. Otherwise, it uses the value in the Status field of the Binding Identifier mobility option.
If the status code is greater than or equal to 128, the mobile node starts relevant operations according to the error code. Otherwise, the mobile node assumes that the originator (home agent or correspondent node) successfully registered the binding information and BID for the mobile node. 🎉
- If the status value is [MCOA PROHIBITED], the mobile node MUST stop registering multiple bindings with the node that sent the Binding Acknowledgement. 🚫
- If the status value is [MCOA BULK REGISTRATION PROHIBITED], the mobile node needs to stop using bulk registrations with the node that sent the Binding Acknowledgement. It SHOULD assume that none of the attempted registrations were successful.
- If [MCOA MALFORMED] is specified, it indicates that the Binding Identifier mobility option is formatted wrong, presumably due to a programming error or major packet corruption. 💀
- If [MCOA NON-MCOA BINDING EXISTS] is specified, there is a non-MCoA binding entry in the receiver. The mobile node MUST set the 'O' flag so that all the registered bindings are replaced by an MCoA registration, as described in Section 5.9.
- If [MCOA UNKNOWN COA] is specified, the mobile node sent a Binding Identifier mobility option without a Care-of Address field, but the receiver couldn't find an entry for the BID indicated. If the mobile node is trying to de-register a BID, it need not do anything further. If the mobile node is trying to refresh a binding, it SHOULD send a Binding Identifier mobility option including the Care-of Address field.
5.8. Receiving Binding Refresh Request 🔁
The verification of a Binding Refresh Request is the same as in Mobile IPv6 (Section 11.7.4 of [RFC3775]). The operation of sending a Binding Refresh Request is described in Section 6.4.
If a mobile node receives a Binding Refresh Request with a Binding Identifier mobility option, it means the node sending the Binding Refresh Request is asking the mobile node to send a new Binding Update for the BID. The mobile node SHOULD then send a Binding Update at least for the respective binding, as described in Sections 5.2 and 5.3. 🫶
5.9. Bootstrapping 🥾
When a mobile node bootstraps and registers multiple bindings for the first time, it MUST set the 'O' flag in the Binding Update message. If old bindings still exist at the home agent, the mobile node has no way of knowing which bindings still exist there. This happens when a mobile node reboots and loses state about its registrations. If the 'O' flag is set, all the bindings are replaced by the new binding(s). clean slate, iconic 🧼
6. Home Agent and Correspondent Node Operation 🏡🛰️
6.1. Searching Binding Cache with Binding Identifier 🔍
If either a correspondent node or a home agent has multiple bindings for a mobile node in their binding cache database, it can use any of the bindings to communicate with the mobile node. This section explains how to retrieve the desired binding for binding management. This document does not provide any mechanism to select the suitable binding for forwarding data packets.
A node that is either a correspondent node or a home agent SHOULD use both the home address and the BID as the search key of the binding cache if it knows the corresponding BID (for example, when processing signaling messages). In the example below, if a node searches for the binding with the home address and BID2, it gets binding2 for this mobile node.
binding1 [2001:db8::EUI, care-of address1, BID1]
binding2 [2001:db8::EUI, care-of address2, BID2]
binding3 [2001:db8::EUI, care-of address3, BID3]
Figure 8: Searching the Binding CacheThe node learns the BID when it receives a Binding Identifier mobility option. At that point, the node MUST look up its binding cache database with the home address and the BID retrieved from the Binding Update. If the node doesn't know the BID, it searches for a binding with only the home address. In that case, the first matched binding is found. If the node doesn't want to use multiple bindings for a mobile node, it can simply ignore the BID. ✨
6.2. Processing Binding Update 💅
okay so this is where the home agent gets a Binding Update and has to decide what to do with it 🫶 If a Binding Update does not contain a Binding Identifier mobility option, it gets processed exactly like in [RFC3775] 🎀 If the receiver already has multiple bindings for the home address, it MUST replace all the existing bindings with the received binding ✨ And if the [RFC3775] Binding Update is for de-registration, the receiver MUST delete all existing bindings from its binding cache 🧹
If the Binding Update does contain Binding Identifier mobility option(s), it gets validated first, according to Section 9.5.1 of [RFC3775] 🔍 After that, the receiver handles the Binding Identifier mobility option(s) step by step, like this:
- The length value gets checked. The length value MUST be either 4, 8, or 20, depending on the Care-of Address field. If the length is wrong, the receiver MUST reject the Binding Update and return the status value set to
[MCOA MALFORMED]💀 - When the length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the unicast routable address [RFC3775] is not in the Care-of Address field, the receiver MUST reject the Binding Identifier mobility option and return the status value set to
[MCOA MALFORMED]🙈 - When there are multiple Binding Identifier mobility options in the Binding Update, that counts as bulk registration. If the receiving node is a correspondent node, it MUST reject the Binding Update and return the status value set to
[MCOA BULK REGISTRATION PROHIBITED]in the binding Acknowledgement 🚫 - If the Lifetime field in the Binding Update is set to zero, the receiving node deletes the binding entry that matches the BID in the Binding Identifier mobility option 🗑️ If the receiving node doesn't have an appropriate binding for the BID, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to
133[not home agent for this mobile node]😭 - If the 'O' flag is set in the de-registering Binding Update, it gets ignored 🙃 If the 'H' flag is set, the home agent stores a home address in the Care-of Address field of the binding cache entry. The home agent MUST follow the descriptions in Section 5.6 💜
- If the Lifetime field is not set to zero, the receiving node registers a binding with the specified BID as a mobile node's binding 🦋 The care-of address comes from the Binding Update packet, like so:
- If the length value of the Binding Identifier mobility option is 20, the care-of address is the IPv6 address copied from the Care-of Address field in the Binding Identifier mobility option 🌸
- When the length value is 8, the address MUST be the IPv4 valid address. How to get an IPv4 care-of address is described in Section 8 🍓
- When the length value is 4 and the Binding Identifier is already in the binding cache, the receiving node MUST update the associated binding entry. Otherwise, the receiving node MUST reject that Binding Identifier mobility option and send a Binding Acknowledgement with the status for that Binding Identifier mobility option set to
[MCOA UNKNOWN]🧚
- Once the care-of address(es) have been pulled out of the Binding Update, the receiving nodes create new binding(s) 🎉
- If the 'O' flag is set in the Binding Update, the receiving node removes all the existing bindings and registers the received binding(s) 👑
- If the 'O' flag is unset in the Binding Update and the receiver has a regular binding that doesn't have a BID for the mobile node, it must not process the Binding Update. The receiver should send a Binding Acknowledgement with status set to
[MCOA NON-MCOA BINDING EXISTS]🙅♀️ - If the receiver already has a binding with the same BID but a different care-of address, it MUST update the binding and respond with a Binding Acknowledgement with status set to
0[Binding Update accepted]✅ - If the receiver doesn't have a binding entry for the BID, it registers a new binding for the BID and responds with a Binding Acknowledgement with status set to
0[Binding Update accepted]🌈
If all of the above gets completed successfully and the 'A' flag is set in the Binding Update, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to the mobile node 💖 Whenever a Binding Acknowledgement goes out, all the Binding Identifier mobility options stored in the Binding Update MUST be copied into the Binding Acknowledgement, except the Status field. The Care-of Address field in each Binding Identifier mobility option MAY be left out, though, because the mobile node can match the right Binding Update List entry using the BID 🫧
When a correspondent node sends a Binding Acknowledgement, the status value MUST always be stored in the Status field of the Binding Acknowledgement, and the Status field of the Binding Identifier mobility option MUST always be set to zero 🔒
When the home agent sends a Binding Acknowledgement, the status value can go in the Status field of either the Binding Acknowledgement or a Binding Identifier mobility option 🤔 If the status value is specific to one of the bindings in the bulk registration, it MUST be stored in the Status field of the corresponding Binding Identifier mobility option. In that case, the Status field of the Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so the receiver can look at the Status field of each Binding Identifier mobility option for further steps 👀 Otherwise, the Status field of the Binding Identifier mobility option MUST be set to zero and the home agent Status field of the Binding Acknowledgement gets used instead 🎀
6.3. Sending a Binding Acknowledgement for Home Link Registration 🏡
this section is all about returning home while you're still using the home and foreign links at the same time 🌍
- When the home agent sends the Binding Acknowledgement after successfully processing the home binding registration, it MUST set the status value to either
0[Binding Update Accepted]or[MCOA RETURNHOME WO/NDP (5)]in the Status field of the Binding Acknowledgment, depending on how the home agent is configured at the home link. The new values are:Binding Update Accepted (0): Neighbor Discovery is permitted for the home address at the home link. This is the regular returning home operation of [RFC3775] ✨MCOA RETURNHOME WO/NDP (5): Neighbor Discovery is prohibited for the home address at the home link 🙅♀️
The respective Binding Identifier mobility options need to be included in the Binding Acknowledgement 📦
- If the Binding Update is rejected, the right error value MUST be set in the Status field. In that case, the home agent operation is the same as in [RFC3775] 🫡
- Only if the home agent is the only router in the home link MAY it turn off Neighbor Discovery for the requested home address and respond with the
[Binding Update Accepted]status value to the mobile node 🥹 Since the mobile node won't reply to Neighbor Solicitation for the home address before it gets the Binding Acknowledgement, the home agent SHOULD use the link-layer address carried by the Mobility Header Link-Layer Address option [RFC5568] in the received Binding Update 🔗 After the home binding registration is done, the mobile node starts regular Neighbor Discovery operations for the home address on the home link. The neighbor cache entry for the home address gets created by the regular exchange of Neighbor Solicitation and Neighbor Advertisement 💫 - If the home agent is not the only router in the home link, the home agent returns the
[MCOA RETURNHOME WO/NDP]value in the Status field of the Binding Identifier mobility option 🧃 The home agent learns the mobile node's link-layer address by receiving the Mobility Header Link-Layer Address option carried by the Binding Update. It stores that link-layer address as a neighbor cache entry for the mobile node, so it can send packets to the mobile node's link-layer address 📬 - Quick note: proxy Neighbor Discovery is an easier way to intercept the mobile nodes' packets instead of IP routing in some deployment scenarios. So even if a home agent is the only router, it's an implementation and operational choice whether the home agent returns
[Binding Update Accepted]or[MCOA RETURNHOME WO/NDP]🤷♀️ - If the BID option is not included in the Binding Acknowledgement, the home agent might not recognize the home registration 😬 It might have processed the home registration Binding Update as a regular de-registration, as described in [RFC3775], and deleted all the registered binding cache entries for the mobile node. So the mobile node SHOULD stop using the interface attached to the foreign link and use only the interface attached to the home link 🏠
6.4. Sending Binding Refresh Request 🔄
When a node (home agent or correspondent node) sends a Binding Refresh Request for a particular binding created with the BID, the node SHOULD include the Binding Identifier mobility option in the Binding Refresh Request 💅 The node MAY include multiple Binding Identifier mobility options if there are several bindings that need refreshing 🌷
6.5. Receiving Packets from Mobile Node 📥
When a node gets packets with a Home Address destination option from a mobile node, it MUST check that the care-of address in the Source Address field of the IPv6 header equals one of the care-of addresses in the binding cache entry 🔍 If no binding is found, the packets MUST be discarded. The node MUST also send a Binding Error message as specified in [RFC3775] 🚨 This verification MUST NOT be done for a Binding Update 🙅♀️
7. Network Mobility Applicability 🌐
The binding management mechanisms are the same for a mobile host that uses Mobile IPv6 and for a mobile router that uses the NEMO Basic Support protocol [RFC3963] 🫶 So the extensions described in this document can also be used to support a mobile router with multiple care-of addresses 🚐 [RFC4980] has an analysis of NEMO multihoming, so go check that out if you're curious 🧠
8. DSMIPv6 Applicability 🌸
Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555] extends Mobile IPv6 so a mobile node can register an IPv4 care-of address instead of an IPv6 care-of address when it's attached to an IPv4-only access network 🛜 It also lets the mobile node get an IPv4 home address in addition to an IPv6 home address, for use with IPv4-only correspondent nodes 💜 This section explains how multiple care-of addresses registration works with IPv4 care-of and home addresses ✨
8.1. IPv4 Care-of Address Registration 🦋
okay so the mobile node can use these extensions to register multiple care-of addresses, and yes, that includes IPv4 ones too 💖
Bulk registration MUST NOT be used for the initial binding registration from an IPv4 care-of address 🙈 The reason is that the Binding Update and Binding Acknowledgement exchange is what detects a NAT on the path between the mobile node and the home agent. So the mobile node has to check for a NAT between each IPv4 care-of address and the home agent. Non-negotiable bestie 💅
The Binding Update MUST be sent to the IPv4 home agent address using UDP and IPv4 headers, like in Figure 9. It's similar to [RFC5555], except the IPv4 care-of address option MUST NOT be used when the BID mobility option is used ✨
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header
IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv4 CoA)
*V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [RFC5555]Figure 9: Initial Binding Update for IPv4 Care-of Address
If NAT is not detected, the mobile node can update the IPv4 care-of address using bulk registration 🌈 It can register that IPv4 care-of address together with other IPv4 and IPv6 care-of addresses. Figure 10 shows the Binding Update format when the mobile node sends a Binding Update from one of its IPv6 care-of addresses. But if the mobile node sends a Binding Update from an IPv4 care-of address, it MUST follow the format in Figure 9. Also, the IPv4 care-of address must be registered by a non-bulk binding registration whenever it changes, so keep that in mind 👑
As Figure 9 shows, the IPv4 care-of address shows up in the Binding Identifier mobility option. The IPv4 Care-of Address mobility option defined in [RFC5555] MUST always be omitted 😭 The receiver of a Binding Update for an IPv4 care-of address MUST treat the IPv4 address stored in the Binding Identifier mobility option as the one in the IPv4 Care-of Address mobility option of [RFC5555]. If the IPv4 address in the Binding Identifier mobility option is different from the one in the Source Address field of the IPv4 header of the Binding Update (that's V4ADDR in Figure 9), then the source address is used as the IPv4 care-of address. Otherwise, the IPv4 address in the Binding Identifier mobility option is used as the IPv4 care-of address. So many rules, but they're all lowkey logical 🧚
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA)
- ...Figure 10: Binding Bulk Registration for an IPv4 Care-of Address
When the home agent returns a Binding Acknowledgement for an IPv4 care-of address registration, it SHOULD NOT use the IPv4 Address Acknowledgement mobility option, and it SHOULD use only the Binding Identifier mobility option 🍓 The registration status for that IPv4 care-of address is stored in the Status field of the Binding Identifier mobility option. However, if the home agent needs to store a status value that's specially defined for the IPv4 Address Acknowledgement mobility option, it MUST store that value in the IPv4 Address Acknowledgement mobility option and MUST NOT store it in the Binding Identifier mobility option. In that case, the home agent MUST include both the IPv4 Address Acknowledgement mobility option and the Binding Identifier mobility option. Main character energy for the home agent, honestly 👑
8.2. IPv4 Home Address Management 🎀
when the mobile node wants an IPv4 home address in addition to its IPv6 home address, it can ask for one using the IPv4 Home Address option in the Binding Update. If the home agent accepts that Binding Update, the mobile node can then register multiple care-of addresses for the IPv4 home address as well as the IPv6 home address. The mobile node MUST always use the IPv4 Home Address mobility option for anything involving IPv4 home address management 🫶 The same set of care-of addresses gets registered for both the IPv6 and IPv4 home addresses. The mobile node cannot bind a different set of care-of addresses to each home address, so no mixing and matching, periodt 💅
According to [RFC5555], the home agent includes the IPv4 Address Acknowledgement option in the Binding Acknowledgement only when the mobile node requested an IPv4 home address in the matching Binding Update. The IPv4 Address Acknowledgement option MUST be present before any Binding Identifier mobility option ✨ Its Status field contains only the error code defined in Section 3.2.1 of [RFC5555]. And the home agent MUST always include the IPv4 Address Acknowledgement mobility option in the Binding Acknowledgement for an IPv4 home address registration. Iconic consistency 🦋
9. IPsec and IKEv2 Interaction ✨
Mobile IPv6 [RFC3775] and the NEMO protocol [RFC3963] require the use of IPsec to protect signaling messages, including Binding Updates, Binding Acknowledgements, and return routability messages. IPsec may also be used to protect all tunneled data traffic 🔐 The Mobile IPv6-IKEv2 specification [RFC4877] explains how IKEv2 can be used to set up the required IPsec security associations. [RFC3775], [RFC3963], and [RFC4877] all make the following assumptions about IKEv2 and IPsec:
- There is only one primary care-of address per mobile node.
- The primary care-of address is stored in the IPsec database for tunnel encapsulation and decapsulation.
- When the home agent receives a packet from the mobile node, the source address is verified against the care-of address in the corresponding binding cache entry. If the packet is a reverse-tunneled packet from the mobile node, the care-of address check is done against the source address on the outer IPv6 header. The reverse-tunneled packet could either be a tunneled Home Test Init message or tunneled data traffic to the correspondent node.
- The mobile node runs IKEv2 (or IKEv1) with the home agent using the care-of address. The IKE SA is based on the care-of address of the mobile node.
Those assumptions may not hold up when the mobile node uses multiple care-of addresses 🙈 So in the following sections, we'll look at the main issues with using multiple care-of addresses with IPsec. Buckle up 🎢
9.1. Use of Care-of Address in the IKEv2 Exchange 🌸
For each home address the mobile node sets up security associations for with the home agent, the mobile node must pick one care-of address and use it as the source address for all IKEv2 messages exchanged to create and maintain the IPsec security associations tied to that home address. The resulting IKEv2 security association is created based on that care-of address.
If the mobile node needs to change its care-of address, it just sends a Binding Update with the new care-of address it wants to use, along with the corresponding Binding Identifier mobility option and the 'K' bit set 🦋 That forces the home agent to update the IKEv2 security association to use the new care-of address. If the 'K' bit isn't supported on the mobile node or the home agent, the mobile node MUST re-establish the IKEv2 security association with the new care-of address. This also results in new IPsec security associations being set up for the home address 😭
9.2. Transport Mode IPsec-Protected Messages 🧚
For Mobile IPv6 signaling messages protected with IPsec in transport mode, it doesn't matter which care-of address you pick from the multiple care-of addresses for IPsec processing. Easy 💖
The home agent processes Mobile Prefix Discovery messages using the same rules as the data packets described in Section 6.5 ✨
9.3. Tunnel Mode IPsec-Protected Messages 🌈
Using IPsec in tunnel mode with multiple care-of addresses causes a few issues, so the way the mobile node and the home agent send and receive tunneled traffic needs some changes 👑 The route optimization mechanism described in [RFC3775] mandates IPsec protection in tunnel mode for Home Test Init and Home Test messages. The mobile node and the home agent may also choose to protect all reverse-tunneled payload traffic with IPsec in tunnel mode. The next sections cover multiple care-of address support for these two types of messages 🍓
9.3.1. Tunneled Home Test Init and Home Test Messages 🎀
The mobile node MAY use the same care-of address for all Home Test Init messages sent reverse tunneled through the home agent. It can use the same care-of address no matter which correspondent node the Home Test Init message is headed to 💅 [RFC3775] requires the home agent to verify that the mobile node is using the care-of address stored in the binding cache entry when it receives a reverse-tunneled Home Test Init message. If a different address is used as the source address, the home agent silently drops the message. This document requires the home agent implementation to decapsulate and forward the Home Test Init message as long as the source address is one of the care-of addresses in the binding cache entry for the mobile node 🫶
When the home agent tunnels a Home Test message to the mobile node, the care-of address in the outer IPv6 header isn't relevant to the Home Test message. So regular IPsec tunnel encapsulation, using the care-of address that the IPsec implementation on the home agent knows about, is enough ✨
9.3.2. Tunneled Payload Traffic ✨
Okay so when the mobile node is sending and receiving several IPsec-protected traffic flows going to different care-of addresses 🦋, picking the right care-of address for each flow is a big deal 💅. The home agent needs to handle two things to make this work 🫶:
- Okay, bestie, when the home agent gets a reverse-tunneled payload message protected by IPsec in tunnel mode, the source address in the outer IPv6 header doesn't matter to IPsec at all 🙈. That's because the tunnel mode security association is based on the addresses in the inner IPv6 header. So the same IPsec security association can cover payload traffic tunneled from any of the care-of addresses 💖. The care-of address used in the reverse-tunneled traffic can be different from the care-of address used as the source address in the IKEv2 exchange. That's still fine, for the reason above ✨.
- Going the other way, the IPsec implementation on the home agent won't know which care-of address to use when it does IPsec tunnel encapsulation for traffic headed to the mobile node 😭. The Mobile IP stack on the home agent is the one that knows this 🧚, since it uses the binding cache entries the mobile node created and knows which care-of address each flow's packets need to be tunneled to. So the destination address for the outer IP header either has to be passed to the IPsec stack dynamically, per packet, when it does the encapsulation, or the Mobile IPv6 stack has to get the packet after IPsec processing is done and change the destination address itself. The first option requires changes to the IPsec implementation. The second option needs special processing in the forwarding function to swap in the correct care-of address on the outer header. The exact technique is implementation specific 💜.
10. Security Considerations 🔐
Okay, this part is seriously important, so listen up 👑. Securing the Binding Update and Binding Acknowledgement messages with multiple care-of addresses is very similar to securing the Binding Update and Binding Acknowledgement messages in general. Please see [RFC3775] for more information. These messages get securely exchanged as described in [RFC3775], [RFC4877], and Section 9 of this document. There are some additional security considerations, and they're below 👇.
With simultaneous binding support, a malicious mobile node could successfully bind a bunch of victims' addresses as valid care-of addresses for itself with its home agent 💀. Once those addresses are bound, the malicious mobile node can run a re-direction attack, like telling the home agent (for example, by setting filtering rules) to tunnel packets to the victims' addresses so a large file transfer gets sent their way 😱. This risk is highlighted in [MIP6ANALYSIS]. These attacks are possible because the home agent doesn't verify the care-of addresses the mobile node sends in the Binding Update messages. In other words, the home agent doesn't check whether the mobile node is actually at the care-of address it claims to be at. The Mobile IPv6 security model assumes there's a trust relationship between the mobile node and its home agent. Any malicious attack by the mobile node is traceable by the home agent, and that acts as a deterrent for the mobile node to try this stuff 🙅♀️.
This risk already exists in Mobile IPv6, but it gets bigger when simultaneous multiple care-of address bindings are in play 🚨. In Mobile IPv6, a mobile node can only have a single care-of address binding per home address at any given time. With simultaneous multiple care-of address bindings, a mobile node can have more than one care-of address binding per home address at a given time. That means a mobile node using simultaneous binding support can effectively bind more than one victim's address. The degree of risk is different too. In the single care-of address binding case, once the re-direction attack starts, the malicious mobile node can't use its home address to communicate, like to receive control packets for the file transfer. But with simultaneous binding support, a malicious mobile node could bind a valid care-of address on top of multiple victims' addresses. That valid care-of address could then be used by the malicious mobile node to set up flow filtering rules at its home agent, which lets it control and/or launch new re-direction attacks 😈.
So, given all these risks, it's advisable for a home agent to use some form of care-of address verification mechanism before it treats care-of addresses as valid routing paths to a mobile node 🛡️. These mechanisms are out of scope for this document.
In Mobile IPv6 binding registration, a home agent always verifies a care-of address by checking that it's reachable. This reachability test may reduce the risks above 🌸. However, when bulk registration is used, a home agent can't verify the reachability of care-of addresses carried in a Binding Identifier mobility option 😬. So the home agent can choose to reject bulk registration by using [MCOA BULK REGISTRATION PROHIBITED] in a Binding Acknowledgement. Another option: when a mobile node first registers a care-of address, it uses individual Binding Updates for the first care-of address that shows up. During that initial binding registration, the home agent can verify the reachability of that care-of address. After that, the mobile node can use bulk registration to refresh the care-of address 🎀.
11. IANA Considerations 🌈
Here's what IANA has assigned for us ✨:
- Binding Identifier mobility option type: (35) has been assigned from the same space as the mobility option in [RFC3775].
- New Successful Status of Binding Acknowledgement: These status codes have been assigned from the same space as the Binding Acknowledgement status codes in [RFC3775].
MCOA NOTCOMPLETE (4)MCOA RETURNHOME WO/NDP (5)
- New Unsuccessful Status of Binding Acknowledgement: These status codes have also been assigned from the same space as the Binding Acknowledgement status codes in [RFC3775].
MCOA MALFORMED (164)MCOA NON-MCOA BINDING EXISTS (165)MCOA PROHIBITED (166)MCOA UNKNOWN COA (167)MCOA BULK REGISTRATION PROHIBITED (168)MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
12. Acknowledgements 🫶
Ryuji Wakikawa and Thierry Ernst are grateful to Keio University for its initial support on this specification back when they were working there 🎓. The authors would also like to thank Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Martti Kuparinen, Romain Kuntz, Benjamin Lim, Heikki Mahkonen, Nicolas Montavont, and Chan-Wah Ng for their discussions and inputs 💅. Thanks to Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Uehara, Masafumi Watari, and Jun Murai for earlier work on this subject 🌷.
13. References 📚
13.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
- [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
- [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
- [RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
13.2. Informative References
- [MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Work in Progress, May 2008.
- [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007.
- [MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008.
- [RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
- [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
Authors' Addresses 💌
Ryuji Wakikawa (Editor) TOYOTA InfoTechnology Center Co., Ltd. EMail: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
Vijay Devarapalli Wichorus EMail: vijay@wichorus.com
George Tsirtsis Qualcomm EMail: Tsirtsis@gmail.com
Thierry Ernst INRIA EMail: thierry.ernst@inria.fr
Kenichi Nagami INTEC NetCore Inc. EMail: nagami@inetcore.com
📦 where this page comes from
- ietf: rfc5648 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms