RFC 6521
Home Agent-Assisted Route Optimization between Mobile IPv4 Networks
Home Agent-Assisted Route Optimization between Mobile IPv4 Networks 🦋
Part 1 of 11 💖
Title block tea ☕ This one is by A. Makela (Aalto University/Comnet) and J. Korhonen (Nokia Siemens Networks). It's Experimental 🧪, published February 2012, with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own. ✨
Abstract ✨
okay so this doc describes a home agent-assisted route optimization feature for the IPv4 Network Mobility Protocol 🌸 The whole point is getting optimal routing when every node is hooked up to one single home agent. So the use case is route optimization inside a single organization, or something similar to that. 🏢
It lets nodes find the peers they're eligible to talk to (the info comes from the home agent) and learn those peers' network prefixes. Then they can set up a direct tunnel between each other. Bestie, that's it, that's the whole vibe 💅
Status of This Memo
ngl this part is kinda boring but it's important 🙈 This document is not an Internet Standards Track spec. It's published so people can examine it, try it out in experimental implementations, and evaluate it. 🔬
It defines an Experimental Protocol for the Internet community 🧪 It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details. 🤓
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6521 🔗
Copyright Notice
The copyright line is Copyright (c) 2012 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, which you can find at http://trustee.ietf.org/license-info as they stand on the publication date. Please actually read those, bestie, because they explain your rights and restrictions for this doc. 📜
If you pull Code Components out of this document, you need to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. Those components come with no warranty, same as the Simplified BSD License says. 🫶
Table of Contents 🗂️
1. Introduction and Motivations ....................................3
2. Terms and Definitions ...........................................6
3. Mobile IPv4 Route Optimization between Mobile Networks ..........8
3.1. Maintaining Route Optimization Information .................9
3.1.1. Advertising Route-Optimizable Prefixes ..............9
3.1.2. Route Optimization Cache ...........................11
3.2. Return Routability Procedure ..............................13
3.2.1. Router Keys ........................................15
3.2.2. Nonces .............................................15
3.2.3. Updating Router Keys and Nonces ....................16
3.3. Mobile-Correspondent Router Operations ....................16
3.3.1. Triggering Route Optimization ......................17
3.3.2. Mobile Router Routing Tables .......................17
3.3.3. Inter-Mobile Router Registration ...................18
3.3.4. Inter-Mobile Router Tunnels ........................20
3.3.5. Constructing Route-Optimized Packets ...............21
3.3.6. Handovers and Mobile Routers Leaving Network .......21
3.4. Convergence and Synchronization Issues ....................22
4. Data Compression Schemes .......................................23
4.1. Prefix Compression ........................................23
4.2. Realm Compression .........................................25
4.2.1. Encoding of Compressed Realms ......................25
4.2.2. Searching Algorithm ................................27
4.2.3. Encoding Example ...................................27
5. New Mobile IPv4 Messages and Extensions ........................30
5.1. Mobile Router Route Optimization Capability Extension .....30
5.2. Route Optimization Reply ..................................31
5.3. Mobile-Correspondent Authentication Extension .............32
5.4. Care-of Address Extension .................................33
5.5. Route Optimization Prefix Advertisement Extension .........34
5.6. Home Test Init Message ....................................36
5.7. Care-of Test Init Message .................................36
5.8. Home Test Message .........................................37
5.9. Care-of Test Message ......................................38
6. Special Considerations .........................................39
6.1. NATs and Stateful Firewalls ...............................39
6.2. Handling of Concurrent Handovers ..........................40
6.3. Foreign Agents ............................................40
6.4. Multiple Home Agents ......................................40
6.5. Mutualness of Route Optimization ..........................41
6.6. Extensibility .............................................42
6.7. Load Balancing ............................................43
7. Scalability ....................................................43
8. Example Signaling Scenarios ....................................44
8.1. Registration Request ......................................44
8.2. Route Optimization with Return Routability ................45
8.3. Handovers .................................................46
9. Protocol Constants .............................................48
10. IANA Considerations ...........................................48
11. Security Considerations .......................................50
11.1. Return Routability .......................................50
11.2. Trust Relationships ......................................51
12. Acknowledgements ..............................................51
13. References ....................................................51
13.1. Normative References .....................................51
13.2. Informative References ...................................521. Introduction and Motivations ✨
okay so bestie, let's talk about why this whole doc exists 🫶 Traditionally, Mobile IPv4 [RFC5944] had basically no route optimization method, apart from one early attempt [MIP-RO] 💀. Mobile IPv6 [RFC6275] got route optimization built in from the start, but with Mobile IPv4 it never got a generalized treatment. Not it 🙈
Even so, general route optimization might not be the main vibe for IPv4, and there are still some specific use cases where it slaps in Mobile IPv4 🔥 This document proposes a method to optimize routes between networks behind Mobile Routers (MRs), as defined by Network Mobility (NEMO) [RFC5177]. NAT and the looming shortage of IPv4 addresses make widespread end-to-end route optimization kinda infeasible 😭 but MR to MR route optimization is still a practical scenario, so we're going for it 💅 Also, real talk: this method is only for route optimization between MRs. Any network prefix that an MR doesn't advertise still gets routed via the home agent 🧚 Though an MR could advertise really large address spaces, e.g., by acting as an Internet gateway, so it's not nothing ✨
Now for the enterprise energy 🎀 Lately, customers really want to keep connectivity through multiple service providers, for reasons like redundancy, reliability, and availability. These multihoming situations have traditionally been handled with things like multihoming BGP, but everyone's kinda craving something more lightweight and economical 🍓
From the service provider side, a typical enterprise customer network is one to several sites (usually headquarters plus a bunch of branch offices) 🌸 These sites are usually connected with Layer 2 technologies (ATM or Frame Relay Permanent Virtual Circuits (PVCs)), MPLS VPNs, or Layer 3 site-to-site VPNs. With a Service Level Agreement (SLA), the customer gets super reliable, well-supported intranet connectivity 🦋 But compared to "consumer-grade" broadband Internet access, the SLA version can feel really pricey. And those consumer-grade options? Not a reliable approach for mission-critical applications, sorry bestie 😬
Here's where Mobile IP, especially MRs, comes in as the hero 👑 It can improve connectivity reliability even when it's running over consumer-grade Internet access. The customer becomes a client of a virtual service provider, which doesn't take part in the actual access technology at all 🧚 The service provider runs a backend system and an IP address pool that it hands out to customers. Access comes from multiple, independent, possibly consumer-grade ISPs, and Mobile IP gives seamless handovers if one ISP's service fails 💖 The catch is that this makes a star topology: every Mobile IP tunnel ends up at the service provider-hosted home agent, which puts a heavy load on the backend 😭 Route optimization between mobile networks fixes exactly that, by taking the network load off the home agent and the backend ✨
Here's an example network, screenshot-style 📸
+----------------------------+
| Virtual Operator Backend |
+------------+ +-----+
| Home Agent | | AAA |
+------------+---------+-----+
|
.--.
_(. `)
_( ISP `)_
( Peering `)
( ` . Point ) )
`--(_______)--'
____ / | \
/ | \
.--. .--. .--.
_( `. _( `. _( `.
( ISP A ) ( ISP B ) ( ISP C )
( ` . ) ) ( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-' `--(___.-'
| ______/ \ /
| / \ /
| / \ /
+----+ +----+
|MR A| |MR B|
+----+ +----+
| |
.--. .--.
_( `. _( `.
( Site A ) ( Site B )
( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-'
Virtual Service Provider Architecture Using NEMOv4In this example, the organization network has two sites connected through two ISPs for redundancy 🎀 Mobile IP allows fast handovers without the headaches of multihoming and BGP peering between each individual ISP and the organization, which is so iconic 💅 The traffic, though, takes a non-optimal route through the virtual operator backend 🥲
Route optimization fixes that. It lets traffic between Sites A and B flow directly through ISP B's network or, if there's a link failure, via the ISP peering point (such as the Metropolitan Area Ethernet (MAE), e.g., MAE-West) 🌈 And the backend won't suffer heavy loads anymore 🫶
The specification in this document is meant to be Experimental ⭐ Its primary design goal is keeping the load on the backend to a minimum. Additional design goals include extensibility to a more generalized scope, such as not requiring all MRs to be homed on the same home agent 🦋 Experiences are mostly sought on applicability to real-world operations, and on protocol-specific issues like signaling scalability, interworking with other Mobile IP extensions not specifically addressed in this document, and the behavior of end-user applications over route-optimized paths 🧚
The use case above is the original application ✨ Moving this specification to Standards Track should be considered after enough deployment experience has been gathered 🌸 Besides the issues already mentioned, other elements might need refinement based on real-world experience: delivery of information on networks managed by peer MRs; conducting MR <-> MR authentication; reaction to, and recovery methods for, connectivity breakdowns and other break-before-make topology changes; keepalive timer intervals; formats of signaling extensions; behavior in NAT/firewalled environments; and the prefix and realm compression algorithms 💜
2. Terms and Definitions ✨
okay this part is the glossary, and it matters SO much, so read it carefully 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 RFC 2119 [RFC2119] 📖
Care-of Address (CoA) 🏠
RFC 5944 [RFC5944] defines a care-of address as the termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it's away from home. The protocol can use two different types of CoA: a "foreign agent care-of address", which is an address of a foreign agent the mobile node is registered with, and a "co-located care-of address", which is an externally obtained local address the mobile node has associated with one of its own network interfaces. But in Network Mobility, foreign agents aren't used, so no foreign CoAs get used either 🙅♀️
Correspondent Router (CR) 🛰️
RFC 5944 [RFC5944] defines a correspondent node as a peer that a mobile node is communicating with. A CR is a peer MR that MAY also represent one or more entire networks 🧚
Home Address (HoA) 🏡
RFC 5944 [RFC5944] defines a home address as an IP address assigned for an extended period of time to a mobile node. It stays unchanged no matter where the node is attached to the Internet 💖
Home Agent (HA) 🗼
RFC 5944 [RFC5944] defines a home agent as a router on a mobile node's home network that tunnels datagrams for delivery to the mobile node when it's away from home, and that keeps current location information for the mobile node. For this application, the "home network" sees limited usage 🥹
Host Network Prefix 🎯
A host network prefix is a network prefix with a mask of /32, e.g., 192.0.2.254/32, consisting of a single host 💜
Mobility Binding 🔗
RFC 5944 [RFC5944] defines Mobility Binding as the association of an HoA with a CoA, along with the lifetime remaining for that association ⏳
Mobile Network Prefix 🌐
RFC 5177 [RFC5177] defines a mobile network prefix as the network prefix of the subnet delegated to an MR as the mobile network 🍓
Mobile Router (MR) 🚐
RFC 5177 [RFC5177] and RFC 5944 [RFC5944] define a mobile router as a mobile node that can be a router responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak 🛶✈️
Route Optimization Cache 🗂️
A Route Optimization Cache is defined as a data structure, maintained by MRs, containing possible destinations for route optimization. The cache holds information (HoAs) on potential CRs and their associated mobile networks 🌸
Return Routability (RR) 🔁
Return routability is defined as a procedure to bind an MR's HoA to a CoA on a CR with a degree of trust 🔐
| (Concatenation) 🧩
Some formulas in this specification use the symbol "|" to indicate bytewise concatenation, as in A | B. This concatenation requires that all of the octets of the datum A appear first in the result, followed by all of the octets of the datum B 🫶
First (size, input) ✂️
Some formulas in this specification use a functional form "First (size, input)" to indicate truncation of the "input" data so that only the first "size" bits remain to be used 💅
3. Mobile IPv4 Route Optimization between Mobile Networks ✨
okay bestie, this section is where the HA and the MR get a total glow-up 💅 compared to the base NEMOv4 stuff in [RFC5177]. The basic premise is still the same: when MRs register with the HA, they can tell it which mobile network prefixes they're managing (explicit mode), or the HA may already know the prefix assignments 🌸. The big twist? Right now the prefix <-> MR mapping only lives on the HA and that one MR. With this scheme, the info gets shared with the other MRs too 🦋
Home agent-assisted route optimization is mainly for making traffic between multiple sites in one organization or administrative domain go brrr 🔥. Extranets can also get optimized routes, as long as every MR connects to the same HA. It's built to stay backward compatible: with legacy nodes or routers, full connectivity is always preserved, even though optimal routing can't be guaranteed 🫶
The scheme needs an MR to accept messages from other MRs unsolicited, which means without first sending a request 👀. This is similar to the registration revocation procedure [RFC3543]. A lot of the mechanisms match, including the fact that advertising route optimization support at registration implies the ability to receive Registration Requests and Return Routability messages from other MRs.
Compared to IPv6, where mobile node <-> correspondent node bindings are maintained via Mobility Routing header and home address options, Mobile IPv4 always requires the use of tunnels 🚇. So inter-mobile-router tunnel establishment has to be conducted 💜.
3.1. Maintaining Route Optimization Information 🧠
During registration, a registering MR MAY request information on route-optimizable network prefixes. The MR MAY also allow redistribution of information on its managed network prefixes, regardless of whether they're explicitly registered or already configured. These are indicated with a Mobile Router Route Optimization Capability Extension; see Section 5.1. If the HA accepts the request for route optimization, this is indicated with a Route Optimization Reply Extension (Section 5.2) in the Registration Reply 🎀.
Note that the redistribution of network prefix information from the HA happens only during the registration signaling 🙈. There are no "routing updates" from the HA except during re-registrations triggered by handovers, registration timeouts, and specific solicitation. The solicitation re-registration MAY occur if a CR receives a Registration Request from an unknown MR (see Section 3.3.3). Iconic behavior, honestly 💅.
3.1.1. Advertising Route-Optimizable Prefixes 📣
As noted, an HA that supports NEMO already keeps track of which network prefixes are reachable behind specific MRs. The only change is that this info can now be distributed to other MRs upon request. That request is implied by including a Route Optimization Capability Extension (Section 5.1) and setting the 'R' bit 🦋.
When an HA receives a Registration Request, standard authentication and authorization procedures are conducted 🔐.
If registration is successful and the Route Optimization Capability Extension was present in the Registration Request, the reply message MUST include the Route Optimization Reply Extension (Section 5.2) to indicate that the Route Optimization Capability Extension was understood. The extension also tells the MR whether NAT was detected between the HA and the MR, using the procedure in RFC 3519 [RFC3519], which is based on the discrepancy between the requester's indicated CoA and the packet's source address 👀.
The reply message MAY also include one Route Optimization Prefix Advertisement Extension, which tells the MR about existing mobile network prefixes and the MRs that manage them, if they're eligible for redistribution 🌈. The networks SHOULD be included in order of priority, with the prefixes that policy considers the most desirable targets for route optimization listed first ⭐. The extension is constructed as shown in Section 5.5. It's basically a list where each MR, identified by its HoA, is listed with its corresponding prefix(es) and their respective realm(s) 🍓.
Each network prefix can be associated with a realm [RFC4282], usually in the form organization.example.com. Besides the routers in the customer's own organization, the prefix list may also include other MRs, e.g., a default prefix (0.0.0.0/0) pointing toward an Internet gateway for Internet connectivity, or additional prefixes belonging to possible extranets 🌍. The realm info can be used to make policy decisions on the MR, like preferring optimization within a specific realm only 💖. The unique realm info can also be used to tell apart overlapping address spaces used by the same or different organizations at the same time, and to adjust forwarding policies accordingly 🧚.
In a typical scenario, where network prefixes are allocated to MRs connecting to a single HA, the prefixes are usually either continuous or at least very close to each other. Because of that, an optional prefix compression mechanism is provided ✂️. There's another optional compression scheme for realm info, since realms often share the same higher-level domains. These compression mechanisms are further explained in Section 4.
Upon receiving a Registration Reply with a Route Optimization Prefix Advertisement Extension, the MR SHALL insert the MR HoAs included in the extension as host-prefixes into the local Route Optimization Cache, if they don't already exist. If present, any additional prefix information SHALL also be inserted into the Route Optimization Cache 💜.
The MR MAY discard entries from a desired starting point onward, due to memory or other policy-related constraints. Listing the prefixes in order of priority is meant to give implicit guidance for that decision 🧭. If the capacity of the device allows, the MR SHOULD use information on all advertised prefixes ✨.
3.1.2. Route Optimization Cache 🗂️
MRs supporting route optimization will maintain a Route Optimization Cache 💅.
The Route Optimization Cache contains mappings between potential CR HoAs, the network(s) associated with each HoA, information on reachability related to NAT and other divisions, and information related to the RR procedure. The cache is populated based on information received from the HA in Route Optimization Prefix Advertisement Extensions, and in registration messages from CRs. Portions of the cache may also be configured statically 🎀.
The Route Optimization Cache contains the following information for all known CRs. Some fields may contain multiple entries. For example, during handovers, there may be both old and new CoAs listed 🦋.
CR-HoA: Correspondent router's home address. Primary key identifying each CR 🔑.CR-CoA(s): Correspondent router's care-of address(es). May be empty if none are known. Potential tunnel's destination address(es) 📍.MR-CoA: Mobile router's care-of address currently used with this CR. Tunnel's source address 🚀.Tunnels: Tunnel interface(s) associated with this CR. The tunnel interface itself handles all the necessary operations to keep the tunnel operational, e.g., sending keepalive messages required by UDP encapsulation 💓.NAT states: A table of booleans. It contains entries for all pairs of potential MR-CoAs and CR-CoAs that are known to require NAT awareness. The table is populated either statically or based on information received during operation. A setting of true indicates that the MR can establish a UDP tunnel toward the CR using this pair of CoAs. A received advertisement can indicate that the value should be set to false for all of the respective CR's CoAs. Settings in this table affect tunnel establishment direction; see Section 3.3.4, and the registration procedure when deciding which CoAs to include in the Care-of Address Extension in the Registration Reply. The existence of an entry mandates the use of UDP encapsulation 🌸.RRSTATEs: Return routability state for each CR-HoA - MR-CoA pair. States are INACTIVE, IN PROGRESS, and ACTIVE. If the state is INACTIVE, the RR procedure must be completed before forwarding route-optimized traffic. If the state is IN PROGRESS or ACTIVE, the information concerning this CR MUST NOT be removed from the Route Optimization Cache as long as a tunnel to the CR is established 🔒.KRms: Registration management key for each CR-HoA - MR-CoA pair. This field is only used if configured statically. If the KRm was computed using the RR procedure, it's calculated in situ based on nonces and the router key. If configured statically, RRSTATE is permanently set to ACTIVE 🔑.Care-of nonce indices: If the KRm was established with the RR procedure, contains the care-of nonce index for each MR-CoA - CR-HoA pair 🧩.Care-of keygen token: If the KRm was established with the RR procedure, contains the care-of keygen token for each MR-CoA - CR-HoA pair 🗝️.Home nonce indices: If the KRm was established with the RR procedure, contains the Home nonce index for each CR-HoA 🧩.Home keygen token: If the KRm was established with the RR procedure, contains the home keygen token for each CR-HoA 🗝️.Network prefixes: A list of destination network prefixes reachable via this CR. Includes network and prefix length, e.g.,192.0.2.0/25. It always contains at least a single entry: the CR-HoA host network prefix, in the form192.0.2.1/32🌐.Realms: Each prefix may be associated with a realm. This may also be empty, if the realm is not provided by advertisement or configuration 🏷️.Prefix_Valid: Boolean field for each prefix - CR-HoA pair, which is set to true if this prefix's owner has been confirmed. The host network prefix consisting of the CR itself doesn't need validation beyond the RR procedure. For other prefixes, the confirmation is done by soliciting the information from the HA. Traffic for prefixes with unconfirmed ownership should not be routed through the tunnel 🚫.
Information that is no longer valid due to expirations or topology changes MAY be removed from the Route Optimization Cache as desired by the MR 🧹✨.
3.2. Return Routability Procedure ✨
okay so the whole point of the RR procedure 🔐 is to set up CoA <-> HoA bindings in a way you can actually trust. The RR procedure for Mobile IPv6 is described in [RFC6275], and the Mobile IPv4 version follows the exact same principles 💖. Two messages go out to the CR's HoA. One goes via the HA using the MR's HoA, and the other goes directly from the MR's CoA. Both responses come back through those same routes 🛣️. The registration management key is derived from token information carried on these messages. That registration management key (KRm) can then be used to authenticate Registration Requests, which is comparable to Binding Updates in Mobile IPv6 🎀.
The RR procedure is how Mobile IP sets up the KRm in a relatively lightweight way 🦋. If you want, the KRms can be configured on MRs statically, or through an external secure key provisioning mechanism. If the MRs already know their KRms through some other mechanism, the RR procedure can be skipped 🙈. Those provisioning mechanisms are out of scope for this document, so we're not getting into them here.
The main assumption about traffic patterns is that the MR initiating the RR procedure can always send outbound messages, even when it's sitting behind a NAT or firewall 🧱. This basic assumption, made for NAT Traversal in [RFC3519], also applies here. When the CR is behind obstacles like that, it receives these messages via the reverse tunnel to the CR's HoA. So any problem with the CR's connectivity gets handled during registration with the HA 🌸.
The RR procedure is made up of four Mobile IP messages: Home Test Init (HoTI), Care-of Test Init (CoTI), Home Test (HoT), and Care-of Test (CoT) 🧚. They're constructed as shown in Sections 5.6 through 5.9. If the MR has included the Mobile Router Route Optimization Capability Extension in its Registration Request, it MUST be able to accept Return Routability messages 👑. The messages get delivered as Mobile IP signaling packets. The destination address of the HoTI and CoTI messages is set to the CR's HoA, and the sources are the MR's HoA and CoA, respectively.
The RR procedure kicks off with the MR sending HoTI and CoTI messages. Each one contains a (different) 64-bit random value, which is the cookie 🍓. The cookie is what binds a specific signaling exchange together.
When the CR gets a HoTI or CoTI message, it MUST have a secret correspondent router key (Kcr) and nonce 🔑. If it doesn't have this material yet, it MUST produce it before continuing with the RR procedure ✨.
The CR responds to HoTI and CoTI messages by building HoT and CoT messages as replies. The HoT message contains a home init cookie, current home nonce index, and home keygen token. The CoT message contains a care-of init cookie, current care-of nonce index, and care-of keygen token 💜.
The home keygen token gets built like this:
Home keygen token = First (64, HMAC_SHA1 (Kcr, (home address |
nonce | 0)))And the care-of keygen token gets built like this:
Care-of keygen token = First (64, HMAC_SHA1 (Kcr, (care-of address |
nonce | 1)))Quick note here: the CoA in this case is the source address of the received CoTI message packet 📦. That address may have changed in transit because of network address translation. This doesn't affect the registration process, though, since subsequent Registration Requests are expected to arrive from the same translated address 🫶.
The RR procedure SHOULD be initiated when the Route Optimization Cache's RRSTATE field for the desired CoA with the target CR is INACTIVE 🔄. If the state was INACTIVE, the state MUST be set to IN PROGRESS when the RR procedure starts. If a handover happens, the MR SHOULD only send a CoTI message to get a new care-of keygen token, because the home keygen token may still be valid 🏃♀️. If the reply to a registration says that one or both of the tokens have expired, the RRSTATE MUST be set to INACTIVE 💀. After that, the RR procedure may then be restarted as needed.
When the RR procedure wraps up, the Route Optimization Cache's RRSTATE field is set to ACTIVE, which lets Registration Requests get sent 🎉. The MR establishes a KRm. By default, this is done using the SHA1 hash algorithm, like so:
KRm = SHA1 (home keygen token | care-of keygen token)When de-registering (by setting the Registration Request's lifetime to zero), the care-of keygen token is not used. Instead, the KRm is generated like this:
KRm = SHA1 (home keygen token)Just like in Mobile IPv6, the CR doesn't keep any state for the MR until it has received a Registration Request 🌙.
3.2.1. Router Keys 🗝️
Each MR maintains a Kcr, which MUST NOT be shared with any other entity 🚫. The Kcr is used to authenticate peer MRs in the situation where an MR is acting as a CR. This is analogous to the node key (Kcn) in Mobile IPv6. A CR uses its router key to check that the keygen tokens a peer MR sends in a Registration Request are the CR's own 🕵️♀️. The router key MUST be a random number, 16 octets in length, generated with a good random number generator [RFC4086].
The MR MAY generate a new key at any time to avoid persistent key storage 🧹. If you want, it is RECOMMENDED that the keys be expired in conjunction with nonces. See Section 3.2.3 for that 🎀.
3.2.2. Nonces 🎲
Each MR also maintains one or more indexed nonces. Nonces SHOULD be generated periodically with a good random number generator [RFC4086]. The MR may use the same nonces with all MRs. Nonces MAY be of any length, with the RECOMMENDED length being 64 bits 🔢.
3.2.3. Updating Router Keys and Nonces ⏳
The router key and nonce updating guidelines are similar to the ones for Mobile IPv6. MRs keep both the current nonce and a small set of valid previous nonces whose lifetimes haven't expired yet 🗂️. A nonce should remain valid for at least MAX_TOKEN_LIFETIME seconds (see Section 9) after it has first been used in constructing an RR response. However, the CR MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 9) after the first use 🚫⏰. Since the difference between these two constants is 30 seconds, a convenient way to enforce the above lifetimes is to generate a new nonce every 30 seconds 🌈. The node can then keep accepting keygen tokens that were based on the last 8 (MAX_NONCE_LIFETIME / 30) nonces. This means keygen tokens are acceptable from MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they've been sent to the mobile node, depending on whether the token was sent at the beginning or end of the first 30-second period 🧮.
Note that the correspondent node may also attempt to generate new nonces on demand, or only if the old nonces have been used. This works as long as the correspondent node keeps track of how long ago the nonces were used for the first time, and it doesn't generate new nonces on every return routability request 🧠.
If the Kcr is being updated, the update SHOULD be done at the same time the nonce is updated. That way, nonce indexes can be used to refer to both Kcrs and nonces 💫.
3.3. Mobile-Correspondent Router Operations 🛰️
This section is all about how mobile and correspondent routers behave when they're doing route optimization 💅. In the context of this document, all routers work as both MR and CR. The term "mobile router" applies to the router that starts the route optimization procedure, and "correspondent router" refers to the peer router 👯.
There are two IPv4 issues that are different from Mobile IPv6 route optimization 🧐. First, since Mobile IPv4 always uses tunnels, there must be a tunnel established between the MR's and the CR's CoAs. The CR learns the MR's CoA because it's included in the Registration Request. The MR learns the CR's CoA through a new extension, "Care-of Address", in the Registration Reply. The second issue is a security consideration, and it's a big one 😱: in a Registration Request, the MR claims to represent an arbitrary IPv4 network. If the CR hasn't received this information yet (HoA <-> network prefix), it SHOULD perform a re-registration with the HA to verify the claim 🚨.
There's one more thing 💖. The MR MAY use a different CoA for different CRs (and the HA). This is useful when the network only provides partial-mesh connectivity and specific interfaces have to be used to reach specific destinations. It also allows for load balancing ⚖️.
3.3.1. Triggering Route Optimization 🔫
Since each MR knows the eligible route-optimizable networks, route optimization between all CRs can be set up at any time. A better general practice, though, is to only do route optimization on demand 🎯. It is RECOMMENDED that route optimization be started only when a packet is sent that originates from a local managed network (and if that network is registered as route optimizable), and whose destination address falls within the network prefixes of the Route Optimization Cache. With a small number of MRs, that on-demand behavior may not be necessary, and full-mesh route optimization may be in place all the time 🕸️.
3.3.2. Mobile Router Routing Tables 🗺️
Each MR maintains a routing table. In a typical setup, the MR has one or more interfaces to the local networks, one or more interfaces to wide-area networks (like the ones ISPs provide), and a tunnel interface to the HA. Additional tunnel interfaces get activated as route optimization is being performed 🌐.
The routing table SHOULD typically contain network prefixes managed by CRs associated with established route-optimized tunnel interfaces. A default route MAY point to the reverse tunnel to the HA, if it isn't overridden by prefix information. The routing table MAY also include additional routes if the tunneling implementation requires them 🧭.
The routes for the HoAs of any CRs SHOULD also be pointing toward their respective tunnels that are using the optimized path 🎀.
If two prefixes overlap each other, for example 192.0.2.128/25 and 192.0.2.128/29, the standard longest-match rule for routing is in effect. However, overlapping private addresses SHOULD be considered an error situation 🙅♀️. Any aggregation for routes in private address space SHOULD be conducted only at the HA 🏠.
3.3.3. Inter-Mobile Router Registration 💌
okay bestie, so if an MR and a CR want route optimization between them 👑, then either the RR procedure has already happened (see Section 3.2), or the KRm has to be pre-shared between the MR and the CR. If either of those is true, an MR MAY send a Registration Request to the CR's HoA from the desired interface 🦋
The Registration Request's Source Address and Care-of Address fields get set to the address of the desired outgoing interface on the MR 🎀 That address MAY be the same as the CoA used with the HA. The Home Agent field gets set to the HA of the MR. The Registration Request MUST be sent to (have a destination address of) the HoA of the CR 💅 It MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and SHOULD include a Mobile Network Request Extension (defined in [RFC5177]). If the Mobile Network Request Extension is present, it MUST contain the network prefixes, as if registering in explicit mode. If timestamps are used, the CR MUST check the Identification field for validity. The Authenticator field is hashed with the KRm 🔐
The CR replies with a Registration Reply 💖 The Registration Reply MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and, if a Mobile Network Request Extension was present in the request, a Mobile Network Acknowledgement Extension ✨
The encapsulation can be set however you like, except when the Route Optimization Cache Entry has NAT entries for the CR, or when the MR itself is known to be behind a NAT or firewall 🙈 If either of those applies, the Registration Request MUST specify UDP encapsulation. It is RECOMMENDED that UDP encapsulation always be used, so path failures can be detected via a keepalive mechanism 🌸
The CR first checks the Registration Request's authentication against Kcr and the nonce indexes negotiated during the RR procedure. This makes sure the Registration Request is coming from a valid MR 🧚 If the check fails, an appropriate Registration Reply code is sent (see Section 10). If the failure is because the nonce index expired, the MR sets RRSTATE for the CR to INACTIVE. The RR procedure MAY then be initiated again 🔄
If the check passes, the CR MUST then check its Route Optimization Cache to see whether the MR exists and is associated with the prefixes in the request (i.e., whether prefixes are present and the 'HA' flag is true for each prefix) 👀 Note that the viewpoint is always local. The CR compares CR-HoA entries against the MR's HoA -- from the CR's perspective, the MR is also a "correspondent router" 🪞
If the check against the cache fails, the CR SHOULD send a re-Registration Request to the HA with the 'S' (solicitation) bit set, so it gets the latest information on network prefixes managed by the incoming MR 📬 If, even after this update, the prefixes still don't match, the reply's Mobile Network Acknowledgement code MUST be set to "MOBNET_UNAUTHORIZED". The registration MAY also be rejected completely 🚫 This verification protects against MRs claiming to represent arbitrary networks. However, since the HA is assumed to provide trusted information, it can authorize the MR's claim 🫶 If the environment itself is considered trusted, the CR can, as a policy, accept registrations without this check. Even so, this is NOT RECOMMENDED as a general practice 😬
If the prefixes match, the CR MAY accept the registration 🎉 If the CR chooses to accept, the CR MUST check to determine if a tunnel to the MR already exists. If the tunnel does not exist or has wrong endpoints (CoAs), a new tunnel MUST be established and the Route Optimization Cache updated. The reply MUST include a list of eligible CoAs (see Section 5.4) with which the MR may establish a tunnel. The reply MUST also include the Mobile-Correspondent Authentication Extension (see Section 5.3) 🧾
Upon receiving the Registration Reply, the MR MUST check to determine if a tunnel to the CR already exists. If the tunnel does not exist or has wrong endpoints (CoAs), a new tunnel MUST be established and the Route Optimization Cache updated. This is covered in detail in Section 3.3.4 🌈
The CR's routing table MUST be updated to show that the MR's networks are reachable via the direct tunnel to the MR 🛣️
After the tunnel is established, the MR MAY update its routing tables to reach all of the CR's Prefixes via the tunnel. Even so, it is RECOMMENDED that time be given for the CR to do its own, explicit registration. This is mostly a policy decision, depending on the network environment. See Section 6.5 ⭐
Here's the spicy part 🌶️ Because route optimization procedures may happen concurrently at both MRs, each working as the other's CR, there may be a moment where two routers are trying to set up separate tunnels between them at the same time 😭 If a router with a smaller HoA (meaning a normal 32-bit integer comparison treating IPv4 addresses as 32-bit unsigned integers) receives a Registration Request (in the CR role) while its own Registration Request (sent in the MR role) is pending, the attempt should be accepted with reply code "concurrent registration" (Value 2). If it receives such an indication, the recipient SHOULD consider the registration a success, but only act on it once the peer has completed its own registration 🤝
3.3.4. Inter-Mobile Router Tunnels 🚇
Inter-MR tunnel establishment follows establishing standard reverse tunnels to the HA. The Registration Request to the CR includes information on the desired encapsulation. It is RECOMMENDED that UDP encapsulation be used 💜 For Generic Router Encapsulation (GRE) [RFC2784], IP over IP [RFC2003], or minimal encapsulation [RFC2004], no special reachability considerations are necessary. The tunnel has no stateful information, so packets are simply encapsulated within the GRE, IP, or minimal header 🎁
The tunnel origination point for the CR is its CoA, not the HoA where the Registration Requests were sent. This is different from creating the reverse tunnel to the HA, which reuses the channel from registration signaling 🔁
Special considerations come from using UDP encapsulation, especially when one of the MRs is behind a NAT or firewall 🧱 A deviation from RFC 3519 [RFC3519] is that keepalives should be sent from both ends of the tunnel to detect path failures after the initial keepalive has been sent. This lets both the MR and CR detect path failures 👯
The initial UDP keepalive SHOULD be sent by the MR. Only after the first keepalive is successfully completed SHOULD the tunnel be considered eligible for traffic 🚦 If a reply to the initial keepalive is not received, the MR may opt to attempt sending the keepalive to other CoAs provided by the Registration Reply, to check whether they provide better connectivity. Or, if all of these fail, the MR may perform a re-registration via an alternative interface, or deregister completely. See Section 6.1 🔄 Once the initial keepalive packet has reached the CR and a reply has been sent, the CR MAY start sending its own keepalives 💫
The original specification for UDP encapsulation suggests a keepalive interval default of 110 seconds. However, for fast response and switching to alternate paths, it is RECOMMENDED, if power and other constraints allow, that considerably shorter periods be used, adapting to the perceived latency as needed ⏱️ Even so, the maximum amount of keepalives SHOULD at no point exceed MAX_UPDATE_RATE times per second. The purpose of the keepalive is not to keep NAT or firewall mappings in place. It's a mechanism for fast response in case of path failures 🌷
If both the MR and the CR are behind separate NATs, route optimization cannot be performed between them 🙅♀️ Possible ways to set up mutual tunneling when both routers are behind NATs are outside the scope of this document. However, some of these issues are addressed in Section 6.1.
The designations "MR" and "CR" only apply to the initial tunnel establishment phase. Once a tunnel is established between two routers, either of them can opt to tear down the tunnel or perform a handover. Signaling messages have to be authenticated with a valid KRm 🔐
3.3.5. Constructing Route-Optimized Packets 📦
All packets received by the MR are forwarded using normal routing rules according to the routing table. There are no special considerations when constructing the packets. The tunnel interface's own processes will encapsulate any packet automatically, so you literally don't have to do anything extra 🙌
3.3.6. Handovers and Mobile Routers Leaving Network 🧳
Handovers and connection breakdowns can be categorized as either ungraceful or graceful, also known as "break-before-make" (bbm) and "make-before-break" (mbb) situations 🎭
As with establishment, the "mobile router" here is the router wishing to change connectivity state, with the "correspondent router" being the peer 🫂
When an MR wants to join its home link, it SHOULD, in addition to sending the Registration Request to the HA with lifetime set to zero, also send such a request to all known CRs, to their HoAs 🏠 The CR(s), upon accepting this request and sending the reply, will check whether the Route Optimization Cache contains any prefixes associated with the requesting MR. These entries should be removed and the routing table updated accordingly, so traffic for the prefixes gets forwarded via the HA again. The tunnel MUST then be destroyed. A short grace period SHOULD be used to allow possible in-transit packets to be received correctly 🫧
In the case of a handover, the CR simply needs to update the tunnel's destination to the MR's new CoA 🔀 The MR SHOULD keep accepting packets from both old and new CoAs for a short grace period, typically on the order of ten seconds. For UDP encapsulation, it is RECOMMENDED that the same port numbers be used for both registration signaling and tunneled traffic, if possible. The initial keepalive message sent by the MR will verify that direct connectivity exists between the MR and CR. If the keepalive fails, the MR SHOULD attempt alternate paths 🛤️
If the MR was unable to send the re-Registration Request before handover, it MUST send it immediately after handover has been completed and a tunnel with the HA is established 🚀 Since changing CoA(s) invalidates the KRm, it is RECOMMENDED that partial return routability be conducted by sending a CoTI message via the new CoA and obtaining a new care-of keygen token 🔑 In all cases, necessary tokens also have to be acquired if the existing tokens have expired ⌛
If a reply is not received for a Registration Request to a CR, any routes to the network prefixes managed by the CR MUST be removed from the routing table. This causes the user traffic to be forwarded via the HA instead 🥺✨
3.4. Convergence and Synchronization Issues
okay so the HA keeps info on mobile network prefixes and on the MRs' Route Optimization Caches, but none of that has to be explicitly synced 🫶 why? bc it's assuming that at least some of the traffic between nodes inside mobile networks is always bidirectional. so things sort themselves out ✨ and if you're using on-demand route optimization, it also means that when a node in one mobile network talks to a node in another, if the first packet doesn't trigger route optimization, the reply will 💅
let's run a lil scenario w/ three mobile networks, A, B, and C, handled by MR A, MR B, and MR C, respectively. if they register with an HA in this order, here's the tea:
MR A registers and gets no info on other networks from the HA, bc no other MR has registered yet 🥲
MR B registers and learns that mobile network A is reachable via MR A 🌸
MR C registers and learns about both of the other mobile networks 👑
okay now, if a node in mobile network C is about to send traffic to mobile network A, the route optimization is super straightforward bc MR C already has network A in its Route Optimization Cache 🦋 so the packet transmission triggers route optimization toward MR A. when MR C registers with MR A (after the RR procedure is completed), MR A doesn't have info on mobile network C, so it'll do a re-registration with the HA on demand. this lets MR A verify that MR C is indeed managing network C ✅
if a node in mobile network B sends traffic to mobile network C, MR B has no info on network C, so no route optimization gets triggered 😭 BUT when the node in network C replies and that reply reaches MR C, route optimization happens just like above. more signaling examples are in Section 8 🎀
even in the very rare case of completely unidirectional traffic from an entire network, re-registrations with the HA caused by timeouts will eventually get things to converge. however, this should be treated as a special case 🙈
and just a heads up: all MRs are connected to the same HA. for possibilities concerning multiple HAs, see Section 6.4 🧚
4. Data Compression Schemes ✨
this section defines the two compression formats used in Route Optimization Prefix Advertisement Extensions 💜
4.1. Prefix Compression
prefix compression is built on the idea that prefixes usually share common properties 🍓 the scheme is simple delta compression. in the prefix information advertisement (Section 5.5), the 'D' bit tells you whether you're receiving a "master" or a "delta" prefix. that, combined w/ the Prefix Length info, is what lets you compress and decompress prefix information 🔥
if D = 0, what follows in the "Prefix" field are bits 1..n of the new master prefix, where n is PLen. this gets rounded up to the nearest full octet. so prefix lengths of /4 and /8 take 1 octet, /12 and /16 take 2 octets, /20 and /24 take 3 octets, and longer prefix lengths take a full 4 octets 🌈
if D = 1, what follows in the "Prefix" field are bits m..PLen of the prefix, where m is the first changed bit of the previous master prefix, w/ padding from the master prefix filling the field to a full octet. the maximum value of PLen - m is 8 (that is, the delta MUST fit into one octet). if that's not possible, a new master prefix has to be declared 🙅♀️ and if the prefixes are equal (like when the same prefix shows up in multiple realms), then one octet still gets encoded, made up completely of padding from the master prefix 💀
determining the order of prefix transmission should be based on saving maximum space during transmission 🧠
here's an example of compression and transmitted data, where the network prefixes 192.0.2.0/28, 192.0.2.64/26, and 192.0.2.128/25 are sent. bc of the padding to full octets, some redundant info gets sent too 🙃 the bit patterns being transmitted look like this:
=+= shows the prefix mask
--- shows the master prefix for delta coded prefixes
192.0.2.0/28, D = 0
0 1 2 3
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|0|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+
^ ^
+---------------------------- encoded ------------------------------+
^ ^
+-pad-+
192.0.2.64/26, D = 1
0 1 2 3
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 2
+-------------------------------------------------------------+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|1|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+
^ ^
+--- encoded ---+
^ ^
+-- padding --+
192.0.2.128/25, D = 1
0 1 2 3
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 2
+-------------------------------------------------------------+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|1|0|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+-+
^ ^
+--- encoded ---+
^ ^
+- padding -+
Figure 1: Prefix Compression Examplethe first prefix, 192.0.2.0/28, is the master prefix and gets sent in full 🦕 the PLen of 28 bits means all four octets have to be transmitted. if the prefix had been, e.g., 192.0.2.0/24, three octets would've been enough, since 24 bits fit into 3 octets.
for the following prefixes, D = 1. so they're deltas of the previous prefix, where D was zero 🎀
192.0.2.64/26 includes bits 19-26 (a full octet). bits 19-25 are copied from the master prefix, but bit 26 gets changed to 1. the final notation in binary is "1001", or 0x09 ✨
192.0.2.128/25 includes bits 18-25 (a full octet). bits 18-24 are copied from the master prefix, but bit 25 gets changed to 1. the final notation in binary is "101", or 0x05 🌟
so the final encoding ends up looking like this:
+----------------+--------+-+---------------------+
| Prefix | PLen |D| Transmitted Prefix |
+----------------+--------+-+---------------------+
| 192.0.2.0/28 | 28 |0| 0xc0 0x00 0x02 0x00 |
| 192.0.2.64/26 | 26 |1| 0x09 |
| 192.0.2.128/25 | 25 |1| 0x05 |
+----------------+--------+-+---------------------+it should be noted that in this case, the order of prefix transmission would not affect compression efficiency 🧁 if 192.0.2.128/25 had been picked as the master prefix and the others as deltas instead, the resulting encoding would still fit into one octet for the subsequent prefixes. no need to declare a new master prefix, bestie 💖
4.2. Realm Compression
4.2.1. Encoding of Compressed Realms
in order to shrink the size of messages, the system brings in a realm compression scheme, which makes realms smaller inside a message 📦 it's a simple, dynamically updated dictionary-based algorithm, designed to compress text strings of any length. an entire realm, a single label, or a list of labels can get swapped out for an index pointing to an earlier occurrence of the same string in the dictionary 🔁 the realm compression defined here was inspired by the DNS domain name label compression scheme in RFC 1035 [RFC1035]. this algorithm is improved, though, to gain even more compression 🔥
when compressing realms, the dictionary gets reset first and doesn't contain a single string yet 🫧 the realms are processed one by one, so the algorithm doesn't expect to see them all, or the whole message, at once. the state of the compressor is just the current content of the dictionary. realms are compressed label by label or as a list of labels. the dictionary can hold a maximum of 128 strings. after that, a rollover MUST occur, and existing contents get overwritten. so when adding the 129th string into the dictionary, the first entry of the dictionary MUST be overwritten, and the index of the new string becomes 0 💅
the encoding of an index to the dictionary, or an uncompressed run of octets representing a single label, was purposely kept simple, and the whole encoding works on octet granularity 🍰 the encoding of an uncompressed label takes the form of one octet, like this:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
|0| LENGTH | 'length' octets long string.. |
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+this encoding allows label lengths from 1 to 127 octets. a label length of zero (0) is not allowed. the "label length" tag octet is then followed by up to 127 octets of the actual encoded label string 🩷
the index to the dictionary (the "label index" tag octet) takes the form of one octet like this:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| INDEX |
+-+-+-+-+-+-+-+-+the above encodings do not allow generating an output octet value of zero (0). the encapsulating Mobile IPv4 extension uses that property and treats the value of zero (0) as the marker for the end of the compressed realm, or for an empty realm 🙌 it's also possible to encode the complete realm using only "label length" tags. in that case, no compression takes place. this lets the sender skip compression, for example to cut down on computation when generating messages 🧮 however, the receiver MUST always be prepared to receive compressed realms 🫶
the receiver has to be ready for compressed realms no matter what, so don't skip that part, bestie 😤
4.2.2. Searching Algorithm ✨
okay so when we're compressing the input realm, we search the dictionary for a matching string 🔍. If nothing matches, we chop the last label off the right-hand side of the realm and search again. We keep doing that until the whole input realm has been processed. If we didn't find a match at all, the first label of the original input realm gets encoded with the "label length" tag and gets added to the dictionary. Then we run the same search on whatever's left of the realm, if anything. Once nothing's left, the realm encoding is done 💅
When we DO find a match in the dictionary, the matching part of the input realm gets encoded with the "label index" tag. That matched part gets removed, and we search again with the remaining part, if there is one. When nothing remains, we insert the octet value of zero (0) to mark the end of the encoded realm 🏁
The search algorithm also keeps track of the "longest non-matching string" for each input realm 🧵. Every time a search in the dictionary fails and a new label gets encoded with the "label length" tag and added to the dictionary, that label gets concatenated onto the "longest non-matching string", with the separating "." (dot, i.e., hexadecimal 0x2e) in between. When a match turns up in the dictionary, the "longest non-matching string" gets reset, so it's emptied. After the whole input realm has been processed and encoded, all the possible suffixes that are longer than one label get pulled out of the string and added to the dictionary ✨
4.2.3. Encoding Example 🎀
this section walks through an example of encoding a set of realms with the realm compression algorithm we just talked about 🧠. Say a message needs to compress the realms "foo.example.com", "bar.foo.example.com", "buz.foo.example.org", "example.com", and "bar.example.com.org". The left side of the diagram below shows the input realms being processed, and the right side shows what the dictionary looks like as it grows. The example uses hexadecimal numbers 🌸
COMPRESSOR: DICTIONARY:
1) Input "foo.example.com"
Search("foo.example.com")
Search("foo.example")
Search("foo")
Encode(0x03,'f','o','o') 0x00 "foo"
+-> "longest non-matching string" = "foo"
Search("example.com")
Search("example")
Encode(0x07,'e','x','a','m','p','l','e') 0x01 "example"
+-> "longest non-matching string" = "foo.example"
Search("com")
Encode(0x03,'c','o','m') 0x02 "com"
+-> "longest non-matching string" = "foo.example.com"
0x03 "foo.example.com"
0x04 "example.com"
Encode(0x00)
2) Input "bar.foo.example.com"
Search("bar.foo.example.com")
Search("bar.foo.example")
Search("bar.foo")
Search("bar")
Encode(0x03,'b','a','r') 0x05 "bar"
+-> "longest non-matching string" = "bar"
Search("foo.example.com") -> match to 0x03
Encode(0x83)
+-> "longest non-matching string" = NUL
Encode(0x00)
3) Input "buz.foo.example.org"
Search("buz.foo.example.org")
Search("buz.foo.example")
Search("buz.foo")
Search("buz")
Encode(0x03,'b','u','z') 0x06 "buz"
+-> "longest non-matching string" = "buz"
Search("foo.example.org")
Search("foo.example")
Search("foo") -> match to 0x00
Encode(0x80)
+-> "longest non-matching string" = NUL
Search("example.org")
Search("example") -> match to 0x01
Encode(0x81)
+-> "longest non-matching string" = NUL
Search("org")
Encode(0x03,'o','r','g') 0x07 "org"
+-> "longest non-matching string" = "org"
Encode(0x00)
4) Input "example.com"
Search("example.com") -> match to 0x04
Encode(0x84)
Encode(0x00)
5) Input "bar.example.com.org"
Search("bar.example.com.org")
Search("bar.example.com")
Search("bar.example")
Search("bar") -> match to 0x05
Encode(0x85)
Search("example.com.org")
Search("example.com") -> match to 0x04
Encode(0x84)
Search("org") -> match to 0x07
Encode(0x87)
Encode(0x00)as you can see from the example, the search and the dictionary update aren't the most optimal, because the matching is greedy 🙈 Still, we don't claim this is the most efficient algorithm out there. It works efficiently enough for most inputs, and that's the vibe ✨ In this example, the original input realm data was 79 octets, and the compressed output, not counting the end mark, is 35 octets 📉
5. New Mobile IPv4 Messages and Extensions 💜
this section describes how to build all the new information elements 🧩
5.1. Mobile Router Route Optimization Capability Extension 🦋
this skippable extension MAY be sent by an MR to an HA in the Registration Request message 🙌
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 | Subtype |A|R|S|O| Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional Mobile Router HoA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type is
153(skippable). If the HA doesn't support route optimization advertisements, it can ignore this request and just not put any information in the reply. It uses the "short" extension format ✨ - Subtype is
1🍓 - Reserved is set to zero, and it MUST be ignored on reception 🙈
- A means "Advertise my networks" 📣. If the 'A' bit is set, the HA is allowed to advertise the networks managed by this MR to other MRs. It also tells the HA that this MR can receive route optimization Registration Requests. Basically, this lets the MR work in the CR role 👑
- R means "Request mobile network information" 🔎. If the 'R' bit is set, the HA MAY respond with info about mobile networks in the same domain 🌈
- S means "Solicit prefixes managed by a specific MR" 🎯. The MR gets named in the Optional Mobile Router HoA field
- O explicitly says the requesting router can only start outgoing connections and can't accept any incoming ones 🧱. That's because of a NAT device, a stateful firewall, or something similar on any interface. The HA reflects this in the reply, and it also gets distributed in Prefix Advertisements to other MRs
- Optional Mobile Router HoA is the solicited mobile router's home address 🏠. This field only shows up if the 'S' flag is set
5.2. Route Optimization Reply 🔥
this non-skippable extension MUST be sent by an HA to an MR in the Registration Reply message, but only if the MR said it supports route optimization in its registration message AND the HA supports route optimization too 💯
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 | Subtype |O|N|S| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type is
49(non-skippable) and it uses the "short" extension format 🚫 - Subtype is
1🌷 - O is the 'O' flag from the Mobile Router Route Optimization Capability Extension, and it gets set if it was on during registration 🧱
- N means NAT was detected by the HA 🕵️♀️. This tells the MR it's sitting behind a NAT. The detection procedure is specified in RFC 3519 [RFC3519] and it's based on the mismatch between the registration packet's source address and the CoA it indicated. The MR can use this info to decide how it wants to handle route optimization 🧠
- S means the HA is responding to a solicitation 🎀. If the 'S' bit was in the MR's Route Optimization Capability Extension (Section 5.1), this bit gets set. Otherwise, it stays unset
The Reply code tells you whether route optimization was accepted 💅. Values of 0..15 mean assent, and values 16..63 mean route optimization is not happening 🙅♀️
0: Will do route optimization ✅16: Route optimization declined, reason unspecified 💔
5.3. Mobile-Correspondent Authentication Extension 🔐
the Mobile-Correspondent Authentication Extension gets included in Registration Requests that go from the MR to the CR. Its existence tells you the message isn't destined for an HA, but for another MR 📬. The format is similar to the other authentication extensions defined in [RFC5944], except the Security Parameter Indexes (SPIs) are swapped out for nonce indexes 🪄
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 | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Home Nonce Index tells the CR which nonce value to use when it makes the home keygen token 🗝️. The Care-of Nonce Index gets ignored in requests that remove a binding. Otherwise, it tells the CR which nonce value to use when it makes the care-of keygen token. If you're using a pre-shared key (KRm), the indexes can be set to zero, and they get ignored on reception 🫶
- Type is
49(non-skippable) and it uses the "short" extension format 🚫 - Subtype is
2🍒 - Reserved is set to zero, and it MUST be ignored on reception 🙈
- Home Nonce Index is the Home Nonce Index in use. If you're using a pre-shared KRm, set it to zero and it gets ignored on reception 💜
- Care-of Nonce Index is the Care-of Nonce Index in use. If you're using a pre-shared KRm, set it to zero and it gets ignored on reception 🌸
- Authenticator is the Authenticator field, which by default gets built with
First (128, HMAC_SHA1 (KRm, Protected Data))🔑
the protected data, same as in the other cases where the Authenticator field is used, is made up of:
- the UDP payload (aka the Registration Request or Registration Reply data) 📦
- all prior extensions in their entirety 🧁
- the Type, Length, Home Nonce Index, and Care-of Nonce Index of this extension 🎀
5.4. Care-of Address Extension ✨
okay so this one is the Care-of Address Extension 🎀 and it gets tacked onto a Registration Reply that the CR sends to the MR. its whole job is to tell the MR about the upcoming tunnel endpoint 🦋
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 | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1..n times the following information structure
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 49 (non-skippable); "short" extension format. 💅
- Length: total length of the packet. when you're processing the information structures and you've hit Length octets, that's your sign that the final information structure was reached too 🧚
- Subtype: 3
- Care-of Address: care-of address(es) that may be used for a tunnel with the MR, listed in order of priority. multiple CoAs MAY be listed to make NAT traversal processing faster ✨
5.5. Route Optimization Prefix Advertisement Extension 👑
this non-skippable extension MAY be sent by an HA to an MR in the Registration Reply message 🌸 it only shows up when the MR explicitly asks for it in the Registration Request, by setting the 'R' flag of the Mobile Router Route Optimization Capability Extension. the order of the extensions is what sets prioritization of prefixes, so it's implicit but still very real 💜
the extension is a sequence of information structures. each one is either an MR HoA or a network prefix. any network prefixes that come after an MR HoA belong to that MR. an MR HoA MUST be first in the sequence, since you literally cannot have prefixes without an MR 🙈
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1..n times the following information structure
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|M| PLen/Info | Optional Mobile Router HoA (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Optional Prefix (1, 2, 3, or 4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Realm (1..n characters) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 50 (non-skippable); "long" extension format. 🌈
- Subtype: 1
- Length: total length of the packet. same deal as before: once you've hit Length octets while processing the information structures, the final one has been reached too ✨
- D (Delta): if D = 1, the prefix is a delta from the last Prefix, where D = 0. D MUST be zero on the first information structure containing a Prefix, and MAY be zero or one on subsequent information structures. if D = 1, the Prefix field is one octet long. see Section 4.1 for the details 🦋
- M (Mobile Router HoA bit): if M = 1, the next field is the Mobile Router HoA, and Prefix and Realm get left out. if M = 0, the next field is the Prefix followed by the Realm, and Mobile Router HoA gets left out. for the first information structure, M MUST be set to 1. if M = 1, the 'D' bit is set to zero and ignored on reception 💖
- PLen/Info: this field changes what it means depending on the 'M' bit. if M = 0, it's the PLen field, and the contents tell you the length of the advertised prefix. the 6 bits cover values from 0 to 63, and 33-63 are illegal 🙅♀️ if M = 1, it's the Info field. 0 means no specific information, and 1 means "outbound connections only". that means the target MR can only initiate connections on its interfaces, not receive them (apart from the reverse tunnel to the HA). this gets set when the MR has explicitly requested it through the 'O' flag in the Mobile Router Route Optimization Capability Extension (Section 5.1) 🔥
- Mobile Router HoA: the mobile router's home address. every prefix in the following information structures where M = 0 is maintained by this MR. this field only shows up when M = 1 🏠
- Prefix: the IPv4 prefix being advertised. if D = 0, the field length is PLen bits, rounded up to the nearest full octet. the least-significant bits starting off PLen (the ones that are zeros) get left out. if D = 1, the field length is one octet. this field only shows up when M = 0 🌸
- Realm: the Realm associated with the advertised Mobile Router HoA and prefix. if it's empty, it MUST be set to '\0'. for realm encoding and the optional compression scheme, check out Section 4.2. this field only shows up when M = 0 💅
5.6. Home Test Init Message 🧚
this message gets sent from the MR to the CR when it's doing the RR procedure 🦋 the source and destination IP addresses are set to the MR's HoA and the CR's HoA, respectively. the UDP source port MAY be randomly chosen, and the UDP destination port is 434 ✨
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 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Home Init Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 24
- Reserved: set to zero; MUST be ignored on reception. 🫶
- Home Init Cookie: a 64-bit field holding a random value, the Home Init Cookie 🎀
5.7. Care-of Test Init Message 🌸
same vibe as the Home Test Init, just for the care-of side. this one gets sent from the MR to the CR during the RR procedure too 💜 the source and destination IP addresses are the MR's CoA and the CR's HoA, respectively. the UDP source port MAY be randomly chosen, and the UDP destination port is 434 🍓
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 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Care-of Init Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 25
- Reserved: set to zero; MUST be ignored on reception. 🦋
- Care-of Init Cookie: a 64-bit field holding a random value, the Care-of Init Cookie ✨
5.8. Home Test Message 💖
this one flips the script: it gets sent from the CR to the MR during the RR procedure as a reply to the Home Test Init message 🔥 the source and destination IP addresses, plus the UDP ports, are the reverse of the ones in the Home Test Init message it's built for. so the UDP source port is always 434 👑
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 | Reserved | Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 26
- Reserved: set to zero; MUST be ignored on reception. 🌈
- Nonce Index: the MR echoes this field back to the CR in a later Registration Request's authentication extension 🫶
- Home Init Cookie: a 64-bit field holding a random value, the Home Init Cookie 🎀
- Home Keygen Token: the 64-bit home keygen token used in the RR procedure. it gets generated from cookie + nonce 🔑
5.9. Care-of Test Message 🧚
last one in this batch, and it's the care-of mirror of the Home Test Message 🦋 it gets sent from the CR to the MR during the RR procedure as a reply to the Care-of Test Init message. the source and destination IP addresses, along with the UDP ports, are the reverse of the ones in the Care-of Test Init message it's constructed for. so the UDP source port is always 434 💅
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 | Reserved | Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 27
- Reserved: set to zero; MUST be ignored on reception. 💜
- Care-of Nonce Index: the MR echoes this field back to the CR in a later Registration Request's authentication extension ✨
- Care-of Init Cookie: a 64-bit field holding a random value, the Care-of Init Cookie 🌸
- Care-of Keygen Token: the 64-bit care-of keygen token used in the RR procedure. it gets generated from cookie + nonce 🔑
6. Special Considerations ✨
6.1. NATs and Stateful Firewalls
okay so NAT and stateful firewalls are the drama 💅 but the [RFC3519] Mobile IP NAT traversal mechanisms let the HA work with MRs sitting behind a NAT device or a stateful firewall 🛡️ 🫶. The HA can also figure out whether a NAT device is sitting between the mobile node and the HA ✨. An MR can also explicitly say it's behind a NAT or firewall on all of its interfaces, and that info gets passed along to the other MRs in the Info field of the Route Optimization Prefix Advertisement Extension (Section 5.5) 💌. The HA can also detect NAT and tell the registering MR about it with the 'N' flag in the Route Optimization Reply Extension (Section 5.2) 🦋. And if one or both routers are behind a NAT or are otherwise struggling to accept incoming connections, the tunnel establishment procedure has to account for that 🥺.
so when the MR is behind a NAT (or firewall) and the CR isn't, the MR is gonna send keepalive messages (ICMP echo requests) through the tunnel once it's set up 🏓. Until it gets a reply back, the tunnel SHOULD NOT be considered active 🚫. Once a reply shows up, the NAT mapping is in place and traffic can finally flow 🌈.
The source address might change because of NAT in CoTI and Registration Request messages, and honestly that's fine 🙆♀️. The process is unaffected because the hash values are calculated using the translated address, and the Registration Request will also appear to come from that same translated address 🧚.
Unlike talking to the HA, route optimization's signaling path is NOT the same path the tunneled packets use 🙃. Signaling always uses HoAs, and the MR <-> CR tunnel runs from CoA to CoA 🎀. It's assumed that even if port numbers change, NAT processing rarely gives more than one external IP address to a single internal address, so the IP address seen in the Registration Request and in tunnel packets stays the same 💜. The UDP source port number might differ between the Registration Request and the incoming tunnel packets because of port translation, and that is not supposed to be an error situation 🙅♀️. The CR MUST be able to accept tunneling packets from a different UDP source port than the one used in the Registration Request ✅.
MRs can have multiple interfaces hooked up to lots of different networks, so some MRs might only be able to do route optimization with specific CoA pairs that come from specific networks 🌸. Like, if two MRs have an interface behind the same NAT, or nested NATs are involved, that's a whole thing 😭. In those cases, the MR MAY try to detect eligible CoA pairs by registering and trying to establish a tunnel (sending keepalives) with each CoA listed in the Registration Reply's Care-of Address Extension 🔍. The eligible pairs should be recorded in the Route Optimization Cache 📝. If a tunnel can't be established with any of the CoAs, the MR MAY try repeating the procedure with alternative interfaces 🔁. The network topology info above can also just be configured on the MRs, either statically or through some external feedback mechanism ⚙️.
If both the MR and the CR are behind two separate NATs, some kind of proxy or hole-punching technique might apply 🕳️. That's out of scope for this document, bestie 💀.
6.2. Handling of Concurrent Handovers
if the MR and the CR both move at the exact same time, signaling is totally fine 🙌. All requests are always sent from a CoA to HoAs, so the recipient always gets the request and can send back the reply 💌. This holds even in break-before-make situations where both the MR and the CR get disconnected at once. Once connectivity comes back, one end of the signaling messages is always the HoA of the respective router, and it's up to the HA to provide reachability 🏠✨.
6.3. Foreign Agents
foreign agents got dropped from the work on Network Mobility for Mobile IPv4, so they aren't considered here 👋.
6.4. Multiple Home Agents
MRs can negotiate and perform route optimization without the help of an HA, as long as they can discover each other's existence and therefore know where to send registration messages 🧭. This document only addresses a logically single HA that distributes network prefix information to the MRs 👑. Problems come from possible trust relationships, and in this document the HA acts as a way to verify that a specific network is managed by a specific router 🔐.
If you want route optimization between nodes attached to separate HAs, there are a few possibilities 🤔. Standard high-availability redundancy protocols, like the Virtual Router Redundancy Protocol (VRRP), can be used, but even then the HA is still a single logical entity, even if it's made up of more than one node 🫧.
There are several ways to get route optimization between MRs attached to separate HAs, like a new discovery/probing protocol, a routing protocol between HAs, DNS SRV records, or a common Authentication, Authorization, and Accounting (AAA) architecture 🗺️. There's already a framework for HA to retrieve information from AAA, so it's honestly the most viable option 🏆. See Section 6.6 for info on a possible way to generalize the method ✨.
Any discovery/probing protocols are out of scope for this document 🙈.
6.5. Mutualness of Route Optimization
the procedure as specified is asymmetric 🙃. That means if you want bidirectional route optimization while keeping things consistent, the route optimization (RR check and registration) has to happen in both directions, but that's not strictly necessary 🤷♀️. It's mostly a policy decision that depends on how often the mobile prefixes get reconfigured 📅.
Let's say two networks, A and B, are handled by MRs A and B, respectively 🧁. If the routers are set up so that route optimization gets triggered when the router is forwarding a packet destined to a network prefix in the Route Optimization Cache, here's what happens when a node in network A starts sending ICMP echo requests (ping packets) to a node in network B 🏓.
MR A sees the incoming ICMP echo request from the local network destined for network B 👀. Since network B is in MR A's Route Optimization Cache, the route optimization process gets triggered 🚀. The original packet still goes out through the reverse tunnel toward the HA like normal 🔄.
MR A completes the RR procedure and registration with MR B, which then becomes a CR for MR A 🫶. A tunnel gets created between the routers 🌉. MR B updates its routing tables so network A is reachable via the MR A <-> MR B tunnel 🗺️.
Now the traffic pattern is: packets from network B to network A go over the direct tunnel, but packets from A to B still go via the HA and reverse tunnels 🤪. The echo reply that the node in network B sends toward network A triggers route optimization at MR B in a similar way 💫. So MR B does its own registration toward MR A too 📬. When that's done, MR B notices a tunnel to MR A already exists, and it updates its routing table so network A is reachable via the (existing) MR A <-> MR B tunnel 🎉. From then on, traffic is bidirectional 💖.
Now, in this scenario, if MR A does NOT wait for a separate route optimization process (RR check and registration) from MR B, and instead just updates its routing table to reach network B via the tunnel, things can go wrong 😬. If MR B has started managing another network, B', before that info has been propagated to MR A, then MR B starts getting packets from network A to network B' via the HA, and packets to network B via the direct tunnel 🌀. If reverse path checking or a similar mechanism is in use on MR B, some of the packets from network A could get black-holed 🕳️💀.
So whether to do this mutual registration depends on the situation, and on whether MRs are going to start managing additional network prefixes during operation 🧐.
6.6. Extensibility
the design includes a few mechanisms that might not be strictly necessary if route optimization were only wanted between individual customer sites in a managed network 🏢. The registration procedure (with the optional return routability part), which lets CRs learn an MR's CoAs, isn't strictly necessary 🙂. The CoAs could've just been handed over by the HA directly 📦.
BUT this approach lets the method extend to a more generic route optimization, which is iconic 🤩. The main reason the HA works as a centralized info distributor is so MRs know not only about the other routers, but also which networks are managed by which routers 🗂️.
The HA provides info on all feasible nodes that route optimization can be established with 🌐. If representing a whole mobile network isn't necessary (basically the typical mobile node <-> correspondent node situation), the mechanisms in this document work just as well 🎀. The only problem is figuring out whether the target correspondent node can actually provide route optimization capability 🤔. You can handle that by not including any prefixes in the information extension, and just including the HoA of the MR 🧸.
Also, with route optimization for a single node, checks for whether an MR is allowed to represent specific networks are unnecessary, because there aren't any networks to check 🙌.
Correspondent node/router discovery protocols (whether they're based on probing or a centralized directory beyond the single HA) are outside the scope of this document 🙅♀️.
6.7. Load Balancing
this design just makes it possible to create optimal paths between MRs 🛣️. It doesn't dictate what user traffic should use those paths 🤷♀️. One possible approach to help with load balancing and using all available paths is presented in [MIPv4FLOW], which effectively allows multiple CoAs for a single HoA 🌈. Also, per-tunnel load balancing is possible by using separate CoAs for separate tunnels 🎀.
7. Scalability ✨
Home agent-assisted route optimization scalability issues come from the general Mobile IPv4 architecture, which is based on tunnels 🚇. Creating, maintaining, and destroying tunnel interfaces can put load on the MRs 😮💨. Still, the MRs can always fall back to normal, reverse-tunneled routing if resource constraints show up 🛟.
If there are a large number of optimization-capable prefixes, maintaining state for all of them can be an issue too, because of limits on routing table sizes 📉.
Registration responses from the HA to the MR might carry info on a large number of network prefixes 📚. If thousands of networks are involved, the Registration Reply messages are bound to get really huge 🫠. The prefix and realm compression mechanisms defined in Section 4 help with this problem, to an extent 🗜️. There will still be some practical upper limit, after which some other delivery mechanism for the prefix information will be needed 🚚💜.
8. Example Signaling Scenarios 🦋
8.1. Registration Request 💖
Okay so picture this: there are three mobile routers, MR A, MR B, and MR C, and each one manages its own network prefix (A, B, and C) 🌸. At the very start, nothing is registered with the HA. Any AAA processing at the HA gets left out of the diagram, because we're focused on the main storyline here 💅
+--------+ +--------+ +--------+ +--------------+
| [MR A] | | [MR B] | | [MR C] | | [Home Agent] |
+--------+ +--------+ +--------+ +--------------+
| | | |
x------------------------------->| Registration Request
| | | | includes Mobile Router
| | | | Route Optimization
| | | | Capability Extension
| | | |
|<-------------------------------x Registration response;
| | | | no known networks from HA
| | | | in response
| | | |
| x-------------------->| Registration Request similar
| | | | to the one sent by MR A
| | | |
| |<--------------------x Registration Reply includes
| | | | network A in Route Optimization
| | | | Prefix Advertisement Extension
| | | |
| | x--------->| Registration Request similar
| | | | to the one sent by MR A
| | | |
| | |<---------x Registration Reply includes
| | | | networks A and B in Route
| | | | Optimization Prefix
| | | | Advertisement Extension.
| | | | Network B is sent in
| | | | compressed form.
| | | |8.2. Route Optimization with Return Routability 🦋
This example has the same network setup as the one in Section 8.1, so that's three MRs, each hanging out with its own network. Node A lives in network A, and Node C lives in network C 🧚
At the beginning, none of the MRs know each other's KRms. If the KRms were pre-shared or provisioned some other way, the Return Routability messages could be skipped. The signaling from Section 8.1 has already happened, so MR A doesn't know about the other networks, but MR C knows about networks A and B 🫶
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
+----------+ +--------+ +------+ +--------+ +----------+
| [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
+----------+ +--------+ +------+ +--------+ +----------+
| | | | |
x------------O==========O=========O------>| Mobile Router A is
| | | | | unaware of network C;
| | | | | thus, nothing happens
| | | | |
|<-----------O==========O=========O-------x Mobile Router C
| | | | | notices packet to
| | | | | network A - begins
| | | | | route optimization
| | | | |
| | | | | Return Routability (if
| | | | | no pre-shared KRms)
| | | | |
| |<=========O---------x | CoTI
| |<=========O=========x | HoTI
| | | | |
| x==========O-------->| | CoT
| x==========O========>| | HoT
| | | | |
| | | | | KRm between MR A <-> C
| | | | | established
| | | | |
| |<=========O---------x | Registration Request
| | | | |
| x--------->| | | Registration Request
| | | | | to HA due to MR A
| | | | | being unaware of
| | | | | network C.
| | | | | Solicit bit set.
| | | | |
| |<---------x | | Registration Reply
| | | | | contains info on
| | | | | network A
| | | | |
| x==========O-------->| | Registration Reply
| | | | | includes MR A's CoA in
| | | | | Care-of Address
| | | | | Extension
| | | | |
| |<= = = = =O= = = ==>| | Optional mutual
| | | | | registration from
| | | | | MR A to MR C
| | | | | (same procedure as above,
| | | | | multiple packets);
| | | | | possible keepalive checks
| | | | |
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Packet from Node C -> A
| | | | | routed to direct tunnel
| | | | | at MR C, based on
| | | | | MR C now knowing MR A's
| | | | | CoA and tunnel being up
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Packet from Node A -> C
| | | | | routed to direct tunnel
| | | | | at MR A, based on MR A
| | | | | now knowing MR C's CoA
| | | | | and tunnel being up8.3. Handovers 🔥
In this signaling example, MR C changes its CoA while route optimization between MR A and MR C is running and data is flowing. Graceful handovers ("make before break") and ungraceful ones ("break before make") both happen in a similar way, except that in the graceful version no packets get lost. This diagram looks at the case where MR C gets immediate notice that it lost connectivity, for example from a link status indication. MR A would eventually notice the breakdown, once its keepalive messages start failing 😭
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
+----------+ +--------+ +------+ +--------+ +----------+
| [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
+----------+ +--------+ +------+ +--------+ +----------+
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Nodes A and C are
|<-----------O=-=-=-==-=-=-=-==-=-O-------x exchanging traffic
| | | | |
| | xxxxxxxxxxx | Break occurs: MR C
| | | | | loses connectivity to
| | | | | current attachment point
| | | | |
x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C
| | | | | lost, and
| | | x<=-=-O-------x vice versa
| | | | |
| | |<--------x | MR C finds a new
| | | | | point of attachment,
| | | | | registers with the HA,
| | | | | clears routing tables
| | | | |
| | x-------->| | Registration Reply
| | | | |
x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C lost
| | | | | (reverts to routing via
| | | | | HA if enough keepalives
| | | | | fail)
| | | | |
|<-----------O==========O=========O-------| Traffic from C -> A
| | | | | sent via HA
| | | | |
| O<=========O---------x | CoTI message
| | | | | (partial RR check)
| | | | |
| x==========O-------->| | CoT message
| | | | |
| |<=========O---------x | Registration Request
| | | | | reusing newly calculated
| | | | | KRm
| | | | |
| x==========O-------->| | Registration Reply
| | | | |
| O<=-=-=-=-=-=-=-=-=-=x | First keepalive check if
| | | | | using UDP encapsulation;
| | | | | also creates holes in
| x=-=-=-=-=-=-=-=-=-=>| | firewalls
| | | | |
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Traffic from A -> C
| | | | | forwarded directly again
| | | | |
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Traffic from C -> A
| | | | | switches back to direct
| | | | | tunnel
| | | | |9. Protocol Constants ⭐
Here are the protocol constants. Think of them as the magic numbers everything else is built around 🔢✨
MAX_NONCE_LIFETIME 240 seconds
MAX_TOKEN_LIFETIME 210 seconds
MAX_UPDATE_RATE 5 times10. IANA Considerations ✨
okay bestie, let's talk IANA 💅 IANA already has rules for the existing registries "Mobile IP Message Types" and "Extensions to Mobile IP Registration Messages", which are specified in RFC 5944 [RFC5944]. New Mobile IP message types and extension code allocations have been made for the messages and extensions listed in Section 5 🎀
the route optimization authentication processing needs four new message type numbers, so here they are in Table 1 🦋
+-------+---------------------------+
| Value | Name |
+-------+---------------------------+
| 24 | Home Test Init message |
| 25 | Care-of Test Init message |
| 26 | Home Test message |
| 27 | Care-of Test message |
+-------+---------------------------+
Table 1: New Values and Names for Mobile IP Message Typeswe also need three new registration message extension types, listed in Table 2 🫶 the first one, 153, is skippable and comes from the range 128-255. the other two, 49 and 50, are non-skippable and come from the range 0-127, with 49 being the "short" format and 50 being the "long" format. none of these messages are permitted for notification messages 🙈
+--------------+---------------------------------------------+
| Value | Name |
+--------------+---------------------------------------------+
| 153, 128-255 | Mobile Router Route Optimization Indication |
| 49, 0-127 | Route Optimization Extensions |
| 50, 0-127 | Route Optimization Data |
+--------------+---------------------------------------------+
Table 2: New Values and Names for Extensions in Mobile IP
Registration Messagesthe registry "Code Values for Mobile IP Registration Reply Messages" has also been modified 🌸 a new success code, 2, should be allocated like this:
2 Concurrent registration (pre-accept)and there's a brand-new allocation range called "Error Codes from the Correspondent Node", governed by Expert Review [RFC5226] ✨ the range is 201-210, and three new Registration Reply codes were taken from it. they're in Table 3:
+-------+-----------------------------+
| Value | Name |
+-------+-----------------------------+
| 201 | Expired Home nonce Index |
| 202 | Expired Care-of nonce Index |
| 203 | Expired nonces |
+-------+-----------------------------+
Table 3: New Code Values and Names for Mobile IP
Registration Reply Messagesthree new number spaces were needed for the subtypes of the extensions in Table 2 💜 there's a new registry called "Route Optimization Types and Subtypes", with an allocation policy of RFC Required [RFC5226]. each registration entry has a Type, a Subtype, and a Name. both Type and Subtype range over 0-255. Types point back to registration message extension types. the initial Subtypes are allocated as in Table 4:
+------+---------+--------------------------------------------------+
| Type | Subtype | Name |
+------+---------+--------------------------------------------------+
| 153 | 0 | Reserved |
| 153 | 1 | Mobile Router Route Optimization Capability |
| | | Extension |
| 49 | 0 | Reserved |
| 49 | 1 | Route Optimization Reply |
| 49 | 2 | Mobile-Correspondent Authentication Extension |
| 49 | 3 | Care-of Address Extension |
| 50 | 0 | Reserved |
| 50 | 1 | Route Optimization Prefix Advertisement |
| | | Extension |
+------+---------+--------------------------------------------------+
Table 4: Initial Values and Names for Registry Route Optimization
Types and Subtypes11. Security Considerations 🔥
this part is serious, so pay attention 👀 there are two main security issues. one is the RR check, which confirms that a specific CoA is really managed by a specific HoA. the other is trust relationships, and the risk of an arbitrary router claiming to represent an arbitrary network 😭
end-user traffic can be protected with normal IPsec mechanisms 🔐
11.1. Return Routability
the RR check's security has already been vetted with Mobile IPv6 ✨ the differences are small, and they come down to two things: the connectivity check and replay attack protection. the connectivity check happens through a separate ICMP message exchange. replay attack protection uses Mobile IPv4 timestamps in the Registration Request's Identification field, which is different from the sequence numbers Mobile IPv6 uses 🦋
the RR procedure doesn't create any state information on the CR, and that's what helps mitigate denial-of-service attacks 🛡️ state information is only kept after a Registration Request has been accepted 💖
11.2. Trust Relationships
the web of trust relationships in home agent-assisted route optimization handles the possible trust issues 🌈 an arbitrary CR can trust an arbitrary MR to be the proper route to reach an arbitrary mobile network 👑
it's assumed that every MR has a trust relationship with the HA, so they trust whatever information the HA provides 🫶
the HA provides information matching HoAs to network prefixes, and every MR trusts that information 🎀
MRs may perform the RR procedure between each other. this creates a trusted association between the MR's HoA and CoA 🦋 the MR also claims to represent a specific network, but that claim isn't trustworthy on its own 🙈
the claim can be verified by checking it against the HoA <-> network prefix information the MR received earlier, or got through an on-demand request to the HA. if they match, the MR's claim is authentic ✅ if the network is considered trusted, a policy decision can be made to skip this check. exactly when such decisions can be made is out of scope for this document 🌸 the RECOMMENDED general practice is to perform the check 💅
12. Acknowledgements ✨
thanks to Alexandru Petrescu for constructive comments and support 🫶 thanks to Jyrki Soini and Kari Laihonen for the initial reviews 💖 this work was supported by TEKES as part of the Future Internet program of TIVIT (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT) 🌟
13. References 📚
13.1. Normative References
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP",
RFC 2004, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
"Network Mobility (NEMO) Extensions for Mobile IPv4",
RFC 5177, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4,
Revised", RFC 5944, November 2010.13.2. Informative References
[MIP-RO] Perkins, C. and D. Johnson, "Route Optimization in
Mobile IP", Work in Progress, September 2001.
[MIPv4FLOW] Gundavelli, S., Ed., Leung, K., Tsirtsis, G., Soliman,
H., and A. Petrescu, "Flow Binding Support for Mobile
IPv4", Work in Progress, February 2012.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.Authors' Addresses 🎀
Antti Makela
Aalto University
Department of Communications and Networking (Comnet)
P.O. Box 13000
FIN-00076 Aalto
FINLAND
EMail: antti.t.makela@iki.fi
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
FINLAND
EMail: jouni.nospam@gmail.com📦 where this page comes from
- ietf: rfc6521 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms