RFC 4857
Mobile IPv4 Regional Registration
RFC 4857 🎀 Mobile IPv4 Regional Registration
Okay bestie, here's the title block 💅
- Stream: Network Working Group 🌸
- Number and title: RFC 4857, "Mobile IPv4 Regional Registration" ✨
- Authors: E. Fogelstroem and A. Jonsson (both Ericsson), and C. Perkins (Nokia Siemens Networks) 🫶
- Category: Experimental 🧪
- Date: June 2007 📅
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🦋
Status of This Memo ✨
So this memo defines an Experimental Protocol for the Internet community 🔬. It is not an Internet standard of any kind, so don't treat it like one 🙅♀️. The authors actively want feedback and suggestions for improvement, so share your thoughts! 💜 Distribution of this memo is unlimited 🌈.
Copyright Notice 🌸
Copyright (C) The IETF Trust (2007). 💖
Abstract 🦋
Okay so with Mobile IP, a mobile node registers with its home agent every single time it changes its care-of address 🧳. This doc introduces "regional registrations" 🗺️, which are registrations that stay local to the visited domain. They're handled by a brand new network entity called a Gateway Foreign Agent (GFA) 👑, and they add a layer of hierarchy inside the visited domain 🪜. The payoff? Way fewer signaling messages going back to the home network 📉, and a shorter signaling delay when a mobile node hops from one foreign agent to another inside the same visited domain ⚡. This document is an optional extension to the Mobile IPv4 protocol 🎀.
Table of Contents 📖
1. Introduction ....................................................3
2. Overview of Regional Registrations ..............................4
3. Terminology .....................................................5
4. Description of the Protocol .....................................7
4.1. General Assumptions ........................................7
4.1.1. Visited Domain ......................................8
4.1.2. Authentication ......................................8
4.2. Protocol Overview ..........................................9
4.3. Advertising Foreign Agent and GFA .........................10
4.4. Backwards Compatibility with RFC 3344 .....................10
5. Home Registration ..............................................11
5.1. Mobile Node Considerations ................................11
5.2. Foreign Agent Considerations ..............................12
5.3. GFA Considerations ........................................13
5.4. Home Agent Considerations .................................14
6. Regional Registration ..........................................14
6.1. Mobile Node Considerations ................................15
6.2. Foreign Agent Considerations ..............................16
6.3. GFA Considerations ........................................16
7. Dynamic GFA Assignment .........................................17
7.1. Mobile Node Considerations for Dynamic GFA Assignment .....17
7.2. Foreign Agent Considerations for Dynamic GFA Assignment ...17
7.3. GFA Considerations for Dynamic GFA Assignment .............18
7.4. Home Agent Considerations for Dynamic GFA Assignment ......18
7.5. Regional Registration .....................................19
8. Router Discovery Extensions ....................................19
8.1. Regional Registration Flag ................................19
8.2. Foreign Agent NAI Extension ...............................19
9. Regional Extensions to Mobile IPv4 Registration Messages .......20
9.1. GFA IP Address Extension ..................................20
9.2. Hierarchical Foreign Agent Extension ......................21
9.3. Replay Protection Style ...................................22
9.4. Regional Registration Lifetime Extension ..................23
9.5. New Code Values for Registration Reply ....................24
10. Regional Registration Message Formats .........................25
10.1. Regional Registration Request ............................26
10.2. Regional Registration Reply ..............................27
10.3. New Regional Registration Reply Code Values ..............28
11. Authentication Extensions .....................................29
12. Security Considerations .......................................29
13. IANA Considerations ...........................................30
14. Acknowledgements ..............................................31
15. References ....................................................32
15.1. Normative References .....................................32
15.2. Informative References ...................................32
Appendix A. Authentication, Authorization, and Accounting (AAA)
Interactions ..........................................33
Appendix B. Anchoring at a GFA ....................................331. Introduction 💖
Okay so this document is an optional extension to the Mobile IPv4 protocol 🎀, and it proposes a way for mobile nodes to register locally inside a visited domain 🏡. Registering locally keeps the number of signaling messages going to the home network to a minimum 📉, and it cuts down the signaling delay ⏱️. Iconic behaviour, honestly 😭.
Let me explain the problem first 🧠. In Mobile IP, as specified in [RFC3344], a mobile node registers with its home agent each time it changes care-of address 🧳. If the visited network is really far away from the mobile node's home network 🌍, those registrations can take a long time to finish, and that's the signaling delay we're talking about 🐢. So the fix we're proposing is to do the registrations locally inside the visited domain, which is what we call regional registrations 🗺️. Regional registrations cut down the number of signaling messages to the home network, and they reduce the signaling delay when a mobile node moves from one foreign agent to another inside the same visited domain ⚡. Bonus: this takes some load off the home network AND makes handover inside the visited domain faster. Two wins, no cap 👑.
Regional registrations bring in a new network node called the Gateway Foreign Agent (GFA) 👸. The foreign agents in a visited domain advertise the GFA's address 📣. When a mobile node first shows up in that visited domain, it does a home registration, which just means registering with its home agent 🏠. During that registration, the mobile node registers the GFA's address as its care-of address with its home agent 💌. After that, when it moves between different foreign agents inside the same visited domain, the mobile node only has to make a regional registration to the GFA 🦋. It's giving efficiency, bestie ✨.
In their simplest form, regional registrations happen transparently to the home agent 🫥, so the home agent doesn't even have to notice 🙈. They can also allow dynamic assignment of the GFA 🎲. The dynamic GFA assignment solution needs support from the mobile node, the foreign agent, the GFA, and the home agent all together 🤝, so it's a team effort 🧚.
The proposed regional registration protocol supports one level of foreign agent hierarchy beneath the GFA 🪜. The protocol may be used to support several levels of hierarchy, but this document doesn't discuss multiple levels at all 🙃.
This doc focuses on regional registrations in visited domains, but regional registrations are also possible in the home domain 🏠💜.
Foreign agents that support regional registrations are also required to support registrations according to Mobile IPv4 [RFC3344] 🔁. So they've got to be able to do the regular stuff too 💅.
The following section gives an overview of regional registrations 🌸. Stay tuned, there's more to come! 🫶
2. Overview of Regional Registrations ✨
okay so in standard Mobile IP there are three entities of interest 🧚: the Mobile Node (MN), the Foreign Agent (FA), and the Home Agent (HA). the MN talks to the HA either through an FA or directly (if it has a co-located care-of address) 🫶. with Regional Registrations, a brand new entity shows up: the Gateway Foreign Agent (GFA) 👑. the GFA sits between the MN/FA and the HA, and to the HA it looks like the MN's temporary care-of address is the GFA's. so when a MN moves around inside a site, it only has to chat with the GFA, which keeps track of the temporary address where the MN is currently reachable 💅.
Two types of registration messages are in play 🎀. the regular [RFC3344] Registration Requests/Replies are still used when the MN swaps Registration Requests/Replies with the HA, but these get forwarded through a GFA and include new extensions.
Then there's a new pair, Regional Registration Requests/Replies 🦋. these are used between MNs/FAs/GFAs for intra-site signaling. a MN uses them to tell the GFA its new addresses as it moves around within a site.
There are two models of how the MN uses Regional Registrations 🌈. the FA can advertise a GFA to the MN. or the FA can indicate that dynamic assignment of GFA is to be used. with dynamic GFA assignment, the MN doesn't pick the GFA. instead the FA (or GFA) picks one after it receives a Registration Request from the MN. BUT in this mode the HA must understand (and support) Regional Registrations in order for them to be used 💀. this last form isn't transparent, because the MN doesn't know in advance which GFA will be used, so it can't include it in a signed message to the HA 🙈.
When a MN moves to a new domain (figured out by comparing its Network Access Identifier (NAI) [RFC4282] with the FA-NAI included in received Agent Advertisements), it can opt in to Regional Registrations 🍓. a site says it supports them by setting the I-bit of the Mobile IP Agent Advertisement extension. the advertisements also include a list of one or more care-of addresses. if there's only one, it's the address of the FA itself. the advertisement may also include the address of the GFA. a GFA care-of address of all-ones means dynamic GFA assignment is supported.
A MN requests its initial Regional Registration by sending a normal Registration Request to the FA 🧁. it sets the care-of address to that of the GFA (i.e., if it has selected the GFA and wishes to use it) or to all-zeros (which signals a dynamic GFA assignment request). the FA then adds a Hierarchical FA (HFA) extension and relays the request to the appropriate GFA. the HFA extension contains a single field: the IP address of the FA.
Note: the algorithm for MNs with co-located care-of addresses is similar, except that there is no FA, so the MN behaves as the FA in terms of the messages it sends. 🫶
A GFA receives Registration Requests relayed from an FA 📬. if the care-of address in the received Registration Request is zero, the GFA assigns one. then a GFA IP Address extension gets added to the Registration Request, and the message is forwarded to the HA. the GFA IP Address extension contains a single field: the IP address of the GFA. (a separate field is needed for this because the Registration Request message between the MN/HA is signed and cannot be modified. 🔐)
HAs process received Registration Requests the same way as before, except in the case of dynamic GFA assignment ✨. in that case, the HA uses the GFA address from the GFA IP Address extension as the MN's current care-of address. on top of that, the Registration Reply message must include the GFA IP Address extension.
The regular Registration Requests/Replies are protected as described in [RFC3344], using the mobility security association between the MN and the HA 🔒. for regional registrations, it's assumed that a mobility security association is established between the MN and GFA during registration with the HA. Regional Registration Requests/Replies are protected by this security association between the MN and the GFA, e.g., by use of a MN-GFA Authentication extension 🎀.
HFA extensions, which an FA adds to a Registration Request or Regional Registration Request, are protected by an FA-FA Authentication extension 🧚. security associations between FAs and GFAs within a domain are assumed to exist before regional registrations happen.
Dynamic GFA assignment requires a way to securely send Registration Requests from the GFA to the HA, so that the GFA IP Address extension is protected 🫣.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms 📖:
Critical type A type value for an extension in the range 0-127, which indicates that the extension MUST either be known to the recipient, or that the message containing the extension MUST be rejected. In other words, an extension with a critical type value is non-skippable. 🚫
Domain A collection of networks sharing a common network administration. 🏠
Foreign Agent (FA) As defined in [RFC3344]. 🧚
Gateway Foreign Agent (GFA) A Foreign Agent which has a publicly routable IP address. A GFA may, for instance, be placed in or near a firewall. 👑
Home Agent (HA) As defined in [RFC3344]. 🏡
Home domain The domain where the home network and home agent are located. 🌸
Home network As defined in [RFC3344]. 🌸
Home Registration A registration, processed by the home agent and the GFA, using the specification in [RFC3344] possibly with additional extensions defined in this document. 📝
Local Care-of Address A care-of address that is assigned to either a mobile node or a foreign agent offering local connectivity to a mobile node. A registration message from the mobile node is subsequently sent to a GFA via the local care-of address. 📍
Mobile Node (MN) As defined in [RFC3344]. 📱
Mobility Agent (MA) As defined in [RFC3344]. 🛰️
Network Access Identifier(NAI) Some features of this protocol specification rely on use of the Network Access Identifier (NAI) [RFC2794]. 🪪
Regional Registration A mobile node performs registration locally at the visited domain, by sending a Regional Registration Request to a GFA, and receiving a Regional Registration Reply in return. 🦋
Registration Key A key used by mobile nodes and mobility agents to secure certain signals and control messages specified by Mobile IP. 🗝️
Visited domain The domain where the visited network, the current foreign agent, and the GFA are located. 🌈
Visited network As defined in [RFC3344]. 🌈
4. Description of the Protocol 🎀
This section gives you the overview of the regional registration protocol 💖.
4.1. General Assumptions
Our general model of operation is illustrated in Figure 1, which shows a visited domain with an FA and a GFA, and a home network with an HA 🗺️:
+---------------------------+ +----------------+
| Visited Domain | | Home |
| | +---------+ | Network |
| | | | | |
| +------+ +-------+ | | Public | | +------+ |
| | FA |------| GFA |-------------------------| HA | |
| +--+---+ +-------+ | | Network | | +------+ |
| | | | | | |
+-----|---------------------+ +---------+ +----------------+
|
+--+---+
| MN |
+------+Figure 1: Model of Operation
For MNs that cannot process a NAI, or with mobility agents that are not configured to advertise their NAI, regional registration is still useful. but processing the NAI makes it easier for the mobile node to reliably detect domain changes 🫶.
4.1.1. Visited Domain
We assume two hierarchy levels of FAs in the visited domain 🏗️. at the top level of the hierarchy, there is at least one GFA, which is an FA with additional features. a GFA must have a publicly routable address. beneath a GFA, there are one or more FAs. we assume that established security associations exist between a GFA and the FAs beneath it. when designing a domain that supports regional registrations, the FAs and GFAs in this domain must be compatible. that is, they should support the same encapsulation types, compression mechanisms, etc. 💅
When a MN changes care-of address under the same GFA, it MAY perform a regional registration. If the MN changes GFA, within a visited domain or between visited domains, it MUST perform a home registration. 🔥
4.1.2. Authentication
With regional registrations, a GFA address is registered at the HA as the care-of address of the MN. If a Mobile-Foreign (MN-FA) Authentication extension is present in a Registration Request message directed to the HA, the GFA will perform the authentication. Similarly, if a Foreign-Home (FA-HA) Authentication extension is present in a Registration Request message, the authentication is performed between the GFA and the HA. To summarize, the GFA takes the role of an FA with regard to security associations in the home registrations 🔐.
Regional registration messages also need to be protected with authentication extensions in the same way as registrations with the HA. This means that the MN and the GFA MUST have received the keys needed to construct the authentication extensions before any regional registration is performed. As described above, since the GFA address is the registered care-of address of the MN at its home network, the GFA is the agent within the visited domain that has to have the appropriate security associations with the HA and the MN. The GFA's security association with the MN is then used to enable proper authentication for regional registrations (see Section 6). How the keys are distributed is outside the scope of this draft. One example is to distribute the keys as part of the home registration, for example according to [RFC4004] and [RFC3957]. Another example is pre-configured keys. 🗝️✨
4.2. Protocol Overview 🦋
okay so bestie, here's the vibe. When a MN first shows up at a visited domain, it registers with its home network 🏠✨ During that registration, the HA writes down the care-of address of the MN. If the visited domain does regional registrations, the care-of address that gets stored at the HA is the address of a GFA 💅 The GFA keeps a visitor list of every MN currently registered with it 📋
Here's the iconic part 👑 Since the HA is storing the GFA address, that address doesn't change when the MN hops to a different FA under the same GFA. So the HA doesn't need to hear about every little move the MN makes inside the visited domain. Literally so efficient 😭🫶
Figure 2 shows the message flow for home registration. During home registration, the HA records the GFA address as the care-of address of the MN 🍓
MN FA1 GFA HA
| | | |
| Registration Request | | |
|---------------------->| Reg. Request | |
| |---------------------->| Reg. Request |
| | |--------------->|
| | | Reg. Reply |
| | Reg. Reply |<---------------|
| Registration Reply |<----------------------| |
|<----------------------| | |
| | | |
Figure 2: Home RegistrationFigure 3 shows regional registration 🧚 Even though the MN's local care-of address changes, the HA keeps using the GFA address as the care-of address of the MN. We also introduce two brand new message types just for regional registrations: Regional Registration Request and Regional Registration Reply ✨
MN FA2 GFA HA
| | | |
| Regional Reg. Req. | | |
|---------------------->| Regional Registration Req. | |
| |----------------------------->| |
| | Regional Registration Reply | |
| Regional Reg. Reply |<-----------------------------| |
|<----------------------| | |
| | | |
Figure 3: Regional Registration4.3. Advertising Foreign Agent and GFA 📣
An FA usually announces that it's there with an Agent Advertisement message [RFC3344] 💖 If the domain that an FA belongs to supports regional registrations, a few changes apply to that Agent Advertisement, so pay attention bestie 👀
The 'I' flag (see Section 8.1) MUST be set to show that the domain supports regional registrations. If the 'I' flag is set, there MUST be at least one care-of address in the Agent Advertisement. If the 'I' flag is set and there's only one care-of address, it's the address of the FA. If the 'I' flag is set and there's more than one care-of address, the first one is the local FA and the last one is the GFA. (Any extra care-of addresses beyond those two are out of scope for this document 🙃)
The FA-NAI (see Section 8.2) SHOULD also be in the Agent Advertisement so the MN can tell whether it has moved to a new domain since its last registration 🦋 The call is made by checking whether the realm part of the advertised FA-NAI matches the realm of the FA-NAI that the MN's previous FA advertised 🔍
4.4. Backwards Compatibility with RFC 3344 🫶
A domain that supports regional registrations should also be backwards compatible 💅
An FA MUST support registrations according to Mobile IPv4 as defined in [RFC3344]. This means MNs that don't support regional registrations can still register through this FA using standard Mobile IPv4 🌸 If the FA advertises both its own care-of address and a GFA care-of address, a MN that supports regional registrations but has an HA that doesn't will still be able to use regional registrations through that GFA care-of address. Main character energy for the MN 👑
The advertised GFA care-of address MAY be set to all-ones to indicate dynamic GFA assignment. If the MN supports regional registrations and an all-ones GFA care-of address is advertised, the MN SHOULD use dynamic GFA assignment (see Section 7.1) ✨
5. Home Registration 🏠
This section gives a detailed walkthrough of home registration, which is registration with the HA on the home network 💖 Home registration happens when a MN first arrives at a visited domain, when it requests a new HA, or when it changes GFA. It also happens to renew bindings that would otherwise expire ⏰
5.1. Mobile Node Considerations 📱
When the MN gets an Agent Advertisement with the 'I' flag set and an FA-NAI extension, it compares the domain part of the FA NAI with the one from the previous Agent Advertisement 🔍 That tells it whether it has moved to a new domain since its last registration. If the NAIs don't match, the MN MUST assume it has moved to a new domain 🚨
If the MN figures out that it has moved to a new domain, it SHOULD put the advertised GFA address in the care-of address field of the Registration Request message. For dynamic GFA assignment, see Section 7.1 ✨
A MN with a co-located care-of address might also want to use regional registrations 🧚 It can find the address of a GFA either from Agent Advertisements sent by an FA or by some means not described in this document. The MN MAY then generate a Registration Request message with the GFA address in the care-of address field and send it directly to the GFA (not via an FA) 🎀 In this case, the MN MUST add a Hierarchical Foreign Agent (HFA) extension (see Section 9.2), including its co-located care-of address, to the Registration Request before sending it. The HFA extension MUST be protected by an authentication extension. If the MN has set up a mobility security association with the GFA, the HFA extension MUST be placed before the MN-FA Authentication extension, and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication extension. Otherwise, if the MN has no established mobility security association with the GFA, the HFA extension MUST be placed before the MN-HA authentication extension 🔥
If the MN gets an Agent Advertisement with the 'R' bit set, it still builds the same Registration Request message with extensions, even if it has a co-located care-of address 💅 The difference is that it sends the message to the advertising FA instead of the GFA 🫶
If the home registration is about to expire, the MN does a new home registration using the same GFA care-of address to refresh the binding [RFC3344] ⏳ If the MN has just moved to a new FA and hasn't sent a Regional Registration Request yet when the home registration is due to expire, it sends only a Registration Request, since this updates both the GFA and the HA 🌈
If the Registration Reply includes a Replay Protection Style extension, the value in the Initial Identification field is the value to use for replay protection in the next Regional Registration Request (see Section 6.1) 🔐
5.2. Foreign Agent Considerations 🛸
When the FA gets a Registration Request message from a MN, it reads the care-of address field to find the GFA that the message shall be relayed to. All FAs that advertise the 'I' flag MUST also be able to handle Registration Requests with an all-zeros care-of address (used for dynamic GFA assignment) 💖
If the FA gets a Registration Request where the care-of address is set to all-ones (which could happen if a MN that doesn't support Regional Registrations copied an all-ones care-of address from an Agent Advertisement), it MUST reply with the Code field set to "poorly formed request" [RFC3344] 🙈
If the Registration Request has the 'T' bit set, the MN is asking for Reverse Tunneling [RFC3024]. In this case, the FA has to tunnel packets from the MN to the GFA for further handling 🚇
If the care-of address in the Registration Request is the address of the FA, the FA relays the message directly to the HA, as described in [RFC3344]. For each pending or current home registration, the FA keeps a visitor list entry as described in [RFC3344]. If reverse tunneling is being used, the visitor list MUST contain the address of the GFA, in addition to the fields required in [RFC3344] 📋
Otherwise, if the care-of address in the Registration Request is the address of a GFA (or all-zeros), the FA adds a Hierarchical Foreign Agent (HFA) extension, including its own address, to the Registration Request and relays it to the GFA 🧚 The HFA extension MUST be appended at the end of all the previous extensions that were included in the Registration Request when the FA received it, and it MUST be protected by a Foreign-Foreign (FA-FA) Authentication extension (see Section 11) 🎀
5.3. GFA Considerations 🏠✨
okay so for every home registration that's pending or current, the GFA keeps a visitor list entry, just like [RFC3344] says 💖. and that entry also gets updated for the regional registrations the MN does 🦋. on top of the fields [RFC3344] already needs, the list entry MUST contain:
- the current care-of address of the MN (i.e., the FA or co-located address) received in the HFA extension
- the remaining Lifetime of the regional registration
- the style of replay protection in use for the regional registration
- the Identification value for the regional registration.
the default replay protection style for regional registrations is timestamp-based replay protection, as defined in Mobile IPv4 [RFC3344] ⏰. if the timestamp the MN sends in the Registration Request isn't close enough to the GFA's time-of-day clock, the GFA adds a Replay Protection Style extension (see Section 9.3) to the Registration Reply. it puts the GFA's time of day in the Identification field so the MN can sync up with the GFA for regional registrations 🫶.
if nonce-based replay protection is being used, the GFA adds a Replay Protection Style extension to the Registration Reply, and the high-order 32 bits of the Identification fields are the nonce the MN should use in its next regional registration 🔐.
if the Registration Request has a Replay Protection Style extension (see Section 9.3) asking for a style the GFA doesn't support, the GFA MUST reject the Registration Request and send a Registration Reply with the Code field set to REPLAY_PROT_UNAVAIL (see Section 9.5). not supported = not it bestie 🙅♀️
if the Hierarchical Foreign Agent (HFA) extension comes after the MN-FA Authentication extension, the GFA MUST remove it from the Registration Request. then the GFA sends the Registration Request on to the HA. when the Registration Reply comes back, the GFA checks its pending registration record to find the care-of address inside its domain that the MN is currently using, and it sends the Registration Reply to that care-of address 📬.
if the Replay Protection Style extension (see Section 9.3) is in a Registration Request and comes right after the MN-HA Authentication extension, the GFA SHOULD remove the Replay Protection Style extension after doing any processing it needs and before it sends the Registration Request to the HA 🧹.
if the GFA gets a Registration Request from an MN it already has a mobility binding for, that's an update to a binding that's about to expire ⏳. if the address in the Hierarchical Foreign Agent (HFA) extension is the same as the current care-of address in the MN's visitor list, the regional registration entries stay the same, except the lifetime gets updated. if the address in the HFA extension is a new one, the regional registration values get updated 🔄.
if the Registration Request has the 'T' bit set, the GFA has to decapsulate the packets from the FA and re-encapsulate them to send back to the HA 🎀. this is needed because the HA has to receive those packets from the expected care-of address (i.e., the GFA's) instead of the local care-of address (i.e., the FA's).
when the GFA gets a Registration Reply from the HA, it MAY add a Regional Registration Lifetime extension to the message before it relays it to the FA 🌸. this extension defines the lifetime the GFA gives the MN before the MN has to renew its regional registration. the GFA MUST set the lifetime of the regional registration to be no greater than the remaining lifetime of the MN's registration with its HA. if it's used, the Regional Registration Lifetime extension MUST be added after any other extensions, and MUST be protected by an MN-FA Authentication extension 🔏.
5.4. Home Agent Considerations 🏡
the HA processes the Registration Request as described in [RFC3344], nothing new here, the HA is just doing its thing 💅.
6. Regional Registration 🌈
okay this section is about regional registrations 🗺️. once the HA has registered the GFA address as the MN's care-of address, the MN may do regional registrations. when it does, the MN may register either an FA care-of address or a co-located address with the GFA. for the rest of this, we assume a home registration already happened (like Section 5 describes) and that the GFA has a mobility security association with the MN 🤝.
so say the MN moves from one FA to another FA inside the same visited domain 🚶♀️. it'll get an Agent Advertisement from the new FA. now say that advertisement says the visited domain supports regional registrations, AND either the advertised GFA address is the same one the MN registered as its care-of address during its last home registration, OR the realm part of the newly advertised FA-NAI matches the FA-NAI advertised by the MN's previous FA. then the MN can do a regional registration with this FA and GFA 🎉. the MN sends a Regional Registration Request to the GFA through the new FA. the request is authenticated with the existing mobility security association between the GFA and the MN, and the message is authenticated by the MN-GFA Authentication extension (see Section 11). the care-of address should be set to the address of the local FA.
if the Regional Registration Request has a care-of address field of all-zeros, the FA adds a Hierarchical Foreign Agent (HFA) extension to the message and relays it to the GFA 🧭. based on what's in the HFA extension, the GFA updates the MN's current point of attachment in its visitor list. then the GFA sends a Regional Registration Reply to the MN through the FA ✅.
if the advertised GFA isn't the same as the one the MN registered as its care-of address, AND the MN is still in the same domain it was in when it registered that care-of address, the MN MAY try a regional registration with its registered GFA 🤞. if the FA can't support regional registration to a GFA other than the advertised one, the FA denies the Regional Registration Request with code UNKNOWN_GFA (see Section 10.3). in that case, the MN has to do a new home registration through the new GFA 😭.
new message types are introduced for the Regional Registration Request and Reply 📨. why not just use the Registration Request and Reply from [RFC3344]? two reasons. (1) the MN has to be able to tell regional registrations apart from home registrations, because for the first one the timestamps/nonces are synced with its GFA, and for the second one they're synced with its HA. (2) a home registration MUST be sent to the home network before the lifetime of the GFA care-of address runs out ⏰.
6.1. Mobile Node Considerations 📱
for each pending or current home registration, the MN keeps the information described in [RFC3344]. that information also gets updated for the regional registrations the MN does 🔁. on top of what [RFC3344] describes, the MN MUST keep the following information, if it's present:
- the GFA address
- the remaining Lifetime of the regional registration
- the style of replay protection in use for the regional registration
- the Identification value for the regional registration.
replay protection for home registrations and regional registrations is done as described in [RFC3344]. the MN does regional registrations at the GFA at the same time as home registrations at the HA, so the MN MUST be able to keep one replay protection mechanism and sequence for the GFA, and a separate mechanism and sequence for the HA 👯♀️. that's a whole double life, iykyk.
for regional registrations, replay protection can also be provided at the FA by the challenge-response mechanism, as described in [RFC4721] 🔑.
6.2. Foreign Agent Considerations 🛜
when the FA gets a Regional Registration Request from an MN addressed to a GFA, it generally handles the message using the rules for a Registration Request addressed to a HA (see Section 5.2) 🧠. the only difference is that the GFA IP address field takes the place of the HA address field. if that address belongs to a known GFA, the FA forwards the request to the GFA it named. otherwise, the FA MUST generate a Regional Registration Reply with error code UNKNOWN_GFA 🚫.
for each pending or current registration, the FA keeps a visitor list entry as described in [RFC3344]. if reverse tunneling is being used, the visitor list MUST contain the address of the GFA, in addition to the fields [RFC3344] requires 📋. this is needed so the FA can tunnel datagrams the MN sends over to the GFA. then the GFA decapsulates the datagrams, re-encapsulates them, and sends them on to the HA 🚇.
6.3. GFA Considerations 🏰
if the GFA accepts a Regional Registration Request, it MUST set the lifetime of the regional registration to be no greater than the remaining lifetime of the MN's registration with its HA, and it puts that lifetime into the matching Regional Registration Reply 💌. the GFA MUST NOT accept a request for a regional registration if the MN's lifetime with its HA has already expired. in that case, the GFA sends a Regional Registration Reply with the Code field set to NO_HOME_REG 🙅♀️.
if the GFA gets a tunneled packet from an FA in its domain, then after decapsulating it, the GFA checks whether it has an entry in its visitor list for the source IP address of the inner IP header 🕵️♀️. if it does, the GFA checks the visitor list to see whether reverse tunneling was requested. if it was, the GFA re-encapsulates the packet with its own address as the source IP address, and the HA's address as the destination IP address 🌊.
7. Dynamic GFA Assignment 🎲
regional registrations can also allow dynamic assignment of a GFA to an MN ✨. the visited network (i.e., the FA) shows that it supports dynamic GFA assignment by advertising an all-ones care-of address in the Agent Advertisement. the MN then sets the care-of address in the Registration Request to all-zeros to ask for a dynamically assigned GFA 🙋♀️. when the FA gets this Registration Request, it relays it to the appropriate GFA, and the GFA assigns its address to the MN using a GFA IP Address extension added to the Registration Request 🪄.
for dynamic GFA assignment to work, the MN, GFA, and HA each MUST support the GFA IP Address extension. the FA MUST also be able to advertise an all-ones care-of address and handle a Registration Request with an all-zeros care-of address 💪.
also, protecting the GFA IP Address extension that's added to the Registration Request requires either an FA-HA Authentication extension or some other way to secure the Registration Request when the GFA forwards it to the HA 🔒.
7.1. Mobile Node Considerations for Dynamic GFA Assignment 📲
if the 'I' flag in the Agent Advertisement sent by the FA is set, and the care-of address indicating the GFA is set to all-ones, that means dynamic GFA assignment is supported 🚦.
if the MN supports dynamic GFA assignment, and the advertised GFA address is all-ones, the MN SHOULD set the care-of address field in the Registration Request to all-zeros to ask to be assigned a GFA 🙏.
when it asks for dynamic GFA assignment, the MN MUST check that it gets a GFA IP Address extension in the Registration Reply 🔍.
7.2. Foreign Agent Considerations for Dynamic GFA Assignment 🧚
okay so if an FA supports dynamic GFA assignment and gets a Registration Request with the care-of address field set to all-zeros, the FA assigns a GFA to the MN 💅 it can either have a default GFA that it gives to every MN, or it can assign a GFA some way that this spec doesn't describe 🌸
if an FA that doesn't support dynamic GFA assignment gets that all-zeros request, it'll deny it like [RFC3344] says, by sending a Registration Reply with the Code field set to "invalid care-of address" 🙈 not the vibe, but it's a clean no
7.3. GFA Considerations for Dynamic GFA Assignment 🦋
if a GFA supports dynamic GFA assignment and gets a Registration Request with the care-of address field set to all-zeros, the GFA assigns its own IP address as the care-of address for this MN. then it adds a GFA IP Address extension with that address to the Registration Request 🫶
the GFA MUST NOT put the GFA IP address straight into the care-of address field in the Registration Request, because that would make the MN-HA authentication fail 😭 so don't do that, bestie
the GFA IP Address extension has to be protected so a malicious node can't change it when the Registration Request gets forwarded to the HA 🔥 if the HA and the GFA have a mobility security association, the GFA IP Address extension MUST be protected by the FA-HA authentication extension. if they don't, the Registration Request MUST be sent to the HA in a secure way, like through a secure AAA protocol (for example, [RFC4004] or [RFC3957]) 🔐
if the GFA doesn't support dynamic GFA assignment, it'll deny the request by sending a Registration Reply with the Code field set to ZERO_COA_NOT_SUPP (see Section 9.5) 💀
7.4. Home Agent Considerations for Dynamic GFA Assignment 👑
if a HA gets a Registration Request with a GFA IP Address extension, and the HA doesn't allow that extension, the HA MUST return a Registration Reply with the Code value set to DYN_GFA_NOT_SUPP (see Section 9.5) 🙅♀️
if a HA gets a Registration Request with the care-of address set to all-zeros but no GFA IP Address extension, it MUST deny the request by sending a Registration Reply message with the Code field set to ZERO_CAREOF_ADDRESS (see Section 9.5) 💅
if a HA that doesn't support dynamic GFA assignment gets a Registration Request with a GFA IP Address extension, the HA will deny the request, as described in [RFC3344] 🌈
if a HA that does support dynamic GFA assignment gets a Registration Request with the care-of address set to all-zeros and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the MN in its mobility binding list ✨ and if the Registration Request gets accepted, the HA MUST include the GFA IP Address extension in the Registration Reply, before the MN-HA Authentication extension 🎀
7.5. Regional Registration 🌸
if the MN gets an Agent Advertisement with the care-of address field indicating the GFA set to all-ones, and the MN figures out it's still in the same visited domain as when it did its last home registration, it MAY send a Regional Registration Request to its current GFA 🦋 otherwise, it MUST send a Registration Request to its HA, as described in Section 7.1 💖
8. Router Discovery Extensions 🧚♀️
this section adds a new flag to the Mobile IP Agent Advertisement, plus an optional extension to the ICMP Router Discovery Protocol ([RFC1256]) 🌈
8.1. Regional Registration Flag 🫧
the only change to the Mobility Agent Advertisement Extension from [RFC3344] is a flag saying that the domain the FA belongs to, the one that made the Agent Advertisement, supports regional registrations 💜 the flag goes after the flags already defined in [RFC3344], [RFC3024], and [RFC3519] 🍓
Regional Registration flag:
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|U|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |the flag works like this 👇
Type:16(Mobility Agent Advertisement)I: Regional Registration. This domain supports regional registration as specified in this document. 🎉
8.2. Foreign Agent NAI Extension 🪄
the FA-NAI extension is subtype 3 of the NAI Carrying Extension ([RFC3846]) 🫶
the FA SHOULD include its NAI in the Agent Advertisement message 💅 if it's there, the Foreign Agent NAI (FA-NAI) extension MUST appear in the Agent Advertisement message after any of the advertisement extensions defined in [RFC3344] ✨
and here's the cute part: by comparing the domain part of the FA-NAI with the domain part of the FA-NAI it got in the previous Agent Advertisement, the MN can figure out whether it has moved to a new domain since it last registered 🥹🦋
9. Regional Extensions to Mobile IPv4 Registration Messages 💖
in this section we define new Mobile IP registration extensions for managing regional registrations 🌷
9.1. GFA IP Address Extension 🌸
the GFA IP Address extension exists to support dynamic GFA assignment 🎀 if the MN asks for a dynamically assigned GFA, the GFA adds a GFA IP Address extension to the Registration Request before relaying it to the HA. the MN says it wants a GFA assigned by sending a Registration Request with the care-of address field set to all-zeros 🙌 the GFA IP Address extension MUST appear in the Registration Request before the FA-HA Authentication extension, if that's present 🔐
if a HA gets a Registration Request with the care-of address set to all-zeros and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the MN. when it makes a Registration Reply, the HA MUST include the GFA IP Address extension from the Registration Request in that Registration Reply message 💜 and the GFA IP Address extension MUST appear in the Registration Reply message before the MN-HA Authentication extension 🫧
the GFA IP Address Extension looks like this 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields 🧾
Type:46(GFA IP Address) (non-skippable)Length:6GFA IP Address: this field holds the Gateway Foreign Agent's (GFA) publicly routable address. 🌐
9.2. Hierarchical Foreign Agent Extension 🧚♀️
the Hierarchical Foreign Agent (HFA) extension may be present in a Registration Request or a Regional Registration Request 💫 when an FA adds this extension to a Registration Request, the receiving mobility agent (GFA) sets up a pending registration record for the MN, using the IP address in the HFA extension as the care-of address for the MN. also, in this case, the extension MUST be appended at the end of all the previous extensions that were included in the registration message as the FA received it 🙌 the HFA extension MUST be protected by an FA-FA Authentication extension. once the receiving mobility agent (GFA) gets the registration message, it MUST remove the HFA extension that the sending FA added 🧹
if a MN with a co-located care-of address adds the HFA extension to a Registration Request, the receiving mobility agent (GFA) sets up a pending registration record for the MN, using the IP address in the HFA extension as the care-of address for the MN 🦋 the extension MUST be protected by an authentication extension. if the MN has set up a mobility security association with the GFA, the HFA extension MUST be placed before the MN-FA Authentication extension, and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication extension. otherwise, if the MN has no mobility security association with the GFA, the HFA extension MUST be placed before the MN-HA authentication extension 🔐 if the HFA extension ends up after all the other extensions, the receiving mobility agent (GFA) MUST remove the HFA extension that the MN added. otherwise, when the HA gets the registration message, it ignores the HFA extension 🙈
the Hierarchical Foreign Agent (HFA) Extension looks like this 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields 🧾
Type:140(Hierarchical Foreign Agent) (skippable)Length:6FA IP Address: the IP Address of the FA relaying the Registration Request. 🫶
9.3. Replay Protection Style 🎀
okay so bestie, when an MN uses Mobile IPv4 to register a care-of address with its HA, the replay protection style is already known, because there's a mobility security association that's required to exist between the MN and the HA that gets the request 🔐. No such pre-existing security association between the MN and the GFA is likely to be available 🙈. So by default, the MN SHOULD treat replay protection for Regional Registration messages exactly as Mobile IPv4 [RFC3344] specifies for timestamp-based replay protection ⏰.
If the MN needs nonce-based replay protection, also as specified in Mobile IPv4, it MAY append a Replay Protection Style extension to a Registration Request 🧚. Registration Requests get forwarded to the HA by way of the GFA, so the GFA will be able to set up the chosen replay protection (see Section 5.3) 💅.
The GFA also uses this extension! It adds a Replay Protection Style extension to a Registration Reply to synchronize the replay protection for Regional Registrations (see Section 5.3) 🔄.
The format of the Replay Protection Style extension is:
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 | Replay Protection Style |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Initial Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🏷️ 141 (Replay Protection Style) (skippable)
Length 📏 2
Replay Protection Style 🎛️ An integer specifying the style of replay protection desired by the MN.
Initial Identification 🪪 The timestamp or nonce to be used for initial synchronization for the replay mechanism.
Admissible values for the Replay Protection Style are as follows:
+-------+-------------------------+
| Value | Replay Protection Style |
+-------+-------------------------+
| 0 | timestamp [RFC3344] |
| 1 | nonce [RFC3344] |
+-------+-------------------------+The Replay Protection Style extension MUST be protected by an authentication extension 🛡️. If the MN has an established mobility security association with the GFA, the Replay Protection Style extension MUST be placed before the MN-FA Authentication extension in the Registration Request, and SHOULD be placed after the MN-HA Authentication extension 📍. Otherwise, the Replay Protection Style extension MUST be placed before the MN-HA Authentication extension in the Registration Request 📍.
If the GFA adds a Replay Protection Style extension to a Registration Reply, it SHOULD be placed before the MN-FA Authentication extension 🦋. The MN-FA Authentication extension should be based on security associations between the MN and GFA established during home registration 🤝.
Replay protection MAY also be provided through a challenge-response mechanism, at the FA issuing the Agent Advertisement, as described in [RFC4721] 🌸.
9.4. Regional Registration Lifetime Extension ⏳
The Regional Registration Lifetime extension lets the GFA set a lifetime for the regional registration with an MN during its home registration 💜. When the GFA gets a Registration Reply from the HA, it MAY add this extension to the Registration Reply before relaying it to the FA ✨. The GFA MUST set the Regional Registration Lifetime to be no greater than the remaining lifetime of the MN's home registration ⚠️.
The Regional Registration Lifetime Extension is defined like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regional Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🏷️ 142 (Regional Registration Lifetime) (skippable)
Length 📏 6
Regional Registration Lifetime ⌛ If the Code field indicates that the registration was accepted, the Regional Registration Lifetime field is set to the number of seconds remaining before the regional registration is considered expired. A value of zero indicates that the MN has been deregistered with the GFA. A value of 0xffff indicates infinity. If the Code field indicates that the home registration was denied, the contents of the Regional Registration Lifetime field are unspecified and MUST be ignored on reception 🙅.
If the GFA adds a Regional Registration Lifetime extension to a Registration Reply, it MUST be placed before the MN-FA Authentication extension 📍. The MN-FA Authentication extension should be based on security associations between the MN and GFA established during home registration 🤝.
9.5. New Code Values for Registration Reply 🔢
The values to use within the Code field of the Registration Reply are defined in [RFC3344] 📚. On top of those, the following values are defined 🆕:
Registration denied by the GFA:
+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| REPLAY_PROT_UNAVAIL | 110 | Section 5.3 |
| ZERO_COA_NOT_SUPP | 111 | Section 7.3 |
+---------------------+-------+---------------------+Registration denied by the HA (for dynamic GFA assignment):
+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| ZERO_CAREOF_ADDRESS | 145 | Section 7.4 |
| DYN_GFA_NOT_SUPP | 146 | Section 7.4 |
+---------------------+-------+---------------------+10. Regional Registration Message Formats 📨
okay this section is where the two new registration message types show up, bestie 💖. They're Regional Registration Request and Regional Registration Reply. The MN uses these instead of the existing Mobile IPv4 Registration Request and Registration Reply, as described in Section 6 🦋.
Regional registration messages get protected by required authentication extensions, the same way existing Mobile IPv4 registration messages are protected 🔐. These rules apply to authentication extensions:
- The MN-GFA Authentication extension [RFC3344] MUST be included in all regional registration messages.
- The MN-FA Authentication extension [RFC3344] MAY be included in regional registration messages.
- The FA-HA Authentication extension [RFC3344] MUST NOT be included in any regional registration message 🚫.
10.1. Regional Registration Request 📤
The Regional Registration Request is how an MN registers with its current GFA 🗺️.
Regional Registration Request:
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 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-The Regional Registration Request is defined as the Registration Request in [RFC3344], but with the following changes 🎀:
Type 🏷️ 18 (Regional Registration Request)
Lifetime ⌛ The number of seconds remaining before the Regional Registration is considered expired. A value of zero indicates a request for deregistration with the GFA. A value of 0xffff indicates infinity.
GFA IP Address 🌐 The IP address of the Gateway Foreign Agent (GFA). (Replaces Home Agent field in Registration Request message in [RFC3344].)
Care-of Address 🏠 Care-of address of local FA; MAY be set to all-ones.
Identification 🪪 A 64-bit number, constructed by the MN, used for matching Regional Registration Requests with Regional Registration Replies, and for protecting against replay attacks of regional registration messages.
Extensions 🧩 For the Regional Registration Request, the Hierarchical Foreign Agent (HFA) Extension is an allowable extension (in addition to those which are allowable for the Registration Request).
10.2. Regional Registration Reply 💌
okay so the Regional Registration Reply is the message that tells the MN whether its regional registration got accepted or denied 💅 (MN = mobile node, bestie 🦋). After the UDP header, it carries these Mobile IP fields:
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-This message is basically the Registration Reply message from [RFC3344], just with a few glow-ups ✨:
- Type: 19 (Regional Registration Reply) 🎀
- Code: A value indicating the result of the Regional Registration Request. See [RFC3344] for a list of currently defined Code values. 📋
- Lifetime: If the Code field indicates that the regional registration was accepted, the Lifetime field is set to the number of seconds remaining before the regional registration is considered expired. A value of zero indicates that the MN has been deregistered with the GFA. A value of
0xffffindicates infinity. If the Code field indicates that the regional registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception. ⏳ (denied means the Lifetime field is basically noise, so ignore it!) - GFA IP Address: The IP address of the Gateway Foreign Agent (GFA) generating the Regional Registration Reply. (Replaces Home Agent field specified in Mobile IPv4 [RFC3344].) 🌸
- Identification: A 64-bit number used for matching Regional Registration Requests with Regional Registration Replies, and for protecting against replay attacks of regional registration messages. The value is based on the Identification field from the Regional Registration Request message from the MN, and on the style of replay protection used in the security context between the MN and its GFA (defined by the mobility security association between them). 🔐
10.3. New Regional Registration Reply Code Values 🚫
For a Regional Registration Reply, these extra Code values are defined on top of the ones from Mobile IPv4 [RFC3344]. 🧚
Registration denied by the FA:
+----------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+----------------------+-------+---------------------+
| UNKNOWN_GFA | 112 | Section 6.2 |
| GFA_UNREACHABLE | 113 | |
| GFA_HOST_UNREACHABLE | 114 | |
| GFA_PORT_UNREACHABLE | 115 | |
+----------------------+-------+---------------------+
Registration denied by the GFA:
+-------------+-------+---------------------+
| Error Name | Value | Section of Document |
+-------------+-------+---------------------+
| NO_HOME_REG | 193 | Section 6.3 |
+-------------+-------+---------------------+The first four Code values get sent back to the MN when the FA receives ICMP errors. 💀 (that's the whole drama arc, honestly)
11. Authentication Extensions 🔑
okay so in this section we get two brand new subtypes for the Generalized Authentication Extension [RFC4721] 🎀. First up, the FA-FA Authentication extension, which FAs use to lock down the HFA extension on Registration Requests and Regional Registration Requests 🔒. We need a new one because the HFA extension usually gets added after the MN-HA Authentication extension or, e.g., the MN-AAA Authentication extension [RFC4721]. Lowkey iconic 👑.
The MN-GFA Authentication extension is used whenever the MN has a co-located address 📍. It's also used to provide authentication for a Regional Registration Request 🫶.
The subtype values for these new subtypes look like this:
+-----------------------+-------+
| Subtype Name | Value |
+-----------------------+-------+
| FA-FA authentication | 2 |
| MN-GFA authentication | 3 |
+-----------------------+-------+And the default algorithm for computing the authenticator is the same as for the MN-AAA Authentication subtype defined in [RFC4721] 🧮.
12. Security Considerations 🚨
okay bestie, this part is serious 😭 but I'm still going to make it readable 💖.
This document proposes a method for a MN to register locally in a visited domain 🏠. The authentication extensions to be used are those defined in [RFC3344] and [RFC4721]. Key distribution, assumed to take place during home registration, is to be performed, for instance, according to [RFC4004] or [RFC3957]. Alternatively, the keys can be pre-configured 🗝️.
If the Hierarchical Foreign Agent (HFA) extension is appended to a Registration Request, this extension is to be followed by an FA-FA Authentication extension (see Section 11) to prevent any modification to the data 🛡️. Security associations between FAs and GFAs within a domain are assumed to exist prior to regional registrations 🤝.
If the GFA IP Address extension is added to a registration message, it is to be followed by a authentication extension 🔏. If the GFA IP Address extension is added to a Registration Request, it should be protected by an FA-HA Authentication extension. If no security association exists between the GFA and the HA, the Registration Request needs to be protected by other means not defined in this document 🚧. When a GFA IP Address extension is added to a Registration Reply, it is protected by the Mobile-Home Authentication extension as defined in [RFC3344] 🔐.
Replay protection for regional registrations is defined similarly to [RFC3344], with the addition of a Replay Protection Style extension 🔁. If this extension is added to a Registration Reply by a GFA, it needs to be protected by a MN-FA Authentication extension 🎟️.
⚠️ A co-operating malicious MN-HA pair can trick the GFA into setting up state for an incorrect MN home address. This would result in redirection of data of the node that actually owns that IP address to the malicious MN. Given that the forwarding happens based on the home address at the GFA, such an attack is scoped to the prefix of the HA, not that of the GFA. This type of attack, or its consequences, is not considered in this document. 💀
13. IANA Considerations 📚
This document defines:
- A subtype for the NAI Carrying Extension [RFC3846] is specified in Section 8.2, which needs to have a value assigned from the space of NAI Carrying Extension subtypes. 🏷️
- Four new extensions to Mobile IP Registration messages: GFA IP Address, Hierarchical Foreign Agent, Replay Protection Style, and Regional Registration Lifetime (see Sections 9.1, 9.2, 9.3, and 9.4). The Type values for the GFA IP Address extension must be within the range 0 through 127, while the other three must be within the range 128 through 255. 🎀
- New Code values for Registration Reply messages (see Section 9.5). ✨
- Two new subtypes for the Generalized Authentication Extension [RFC4721]; see Section 11. 🔑
- Two new message types for Mobile IP: Regional Registration Request and Regional Registration Reply (see Sections 10.1 and 10.2). 📨
- Code values for Regional Registration Reply messages (see Section 10.3). 🌈
14. Acknowledgements 💜
This document is a logical successor to documents written with Pat Calhoun and Gabriel Montenegro; thanks to them and their many efforts to help explore this problem space. Many thanks also to Jari Malinen for his commentary on a rough version of this document 🙌.
15. References 📖
15.1. Normative References
- [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
- [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
- [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003.
- [RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.
- [RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
15.2. Informative References
- [RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
- [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
Appendix A. Authentication, Authorization, and Accounting (AAA) Interactions 🛂
When the mobile node has to obtain authorization by way of Authentication, Authorization, and Accounting (AAA) infrastructure services, the control flow implicit in the main body of this specification is likely to be modified. Typically, the mobile node will supply credentials for authorization by AAA as part of its registration messages. The GFA will parse the credentials supplied by the mobile and forward the appropriate authorization request to a local AAA server (see [RFC3012] and [RFC4004]) 🧾.
Concretely, this means that:
- The GFA MAY include the Mobile IP Registration Request data inside an authorization request, directed to a local AAA server. 📬
- The GFA MAY receive the Mobile IP Registration Reply data from a message granting authorization, received from the AAA infrastructure. 🎉
Appendix B. Anchoring at a GFA ⚓
As described earlier in this draft, once a mobile node has registered the address of a GFA as its care-of address with its home agent, it MAY perform regional registrations when changing foreign agent under the same GFA 🦋. When detecting that it has changed foreign agent, and if the new foreign agent advertises the 'I' flag, the mobile node MAY address a Regional Registration Request message to its registered GFA, even if the address of that particular GFA is not advertised by the new foreign agent 💌. The foreign agent MAY then relay the request to the GFA in question, or deny the request with error code UNKNOWN_GFA 🌸.
Authors' Addresses 💌
okay bestie, here are the three people who wrote this 🫶 first up is Eva Fogelstroem at Ericsson in Stockholm, Sweden. Her email is eva.fogelstrom@ericsson.com (yes, the spelling is fogelstrom in the email, not fogelstroem, so don't mix them up 😭).
Eva Fogelstroem
Ericsson
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: eva.fogelstrom@ericsson.comnext is Annika Jonsson, also at Ericsson, but in Hagersten, Sweden 🌸 her email is annika.jonsson@ericsson.com.
Annika Jonsson
Ericsson
Tellusborgsvagen 83-87
S-126 37 Hagersten
Sweden
EMail: annika.jonsson@ericsson.comand last but definitely not least, Charles E. Perkins at Nokia Siemens Networks in Mountain View, California, USA 🦋 his email is charles.perkins@nsn.com.
Charles E. Perkins
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, California 94043
USA
EMail: charles.perkins@nsn.comFull Copyright Statement ⚖️
the legal bit, so read it even though it's a little boring 🙈 the copyright belongs to The IETF Trust (2007) 🌈
this document is subject to the rights, licenses and restrictions in BCP 78. except for what's set out there, the authors keep all their rights.
the document and the info in it are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property 🔥
the IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this document are valid or how far they reach. it also doesn't say whether a license for those rights would be available, and it hasn't made any independent effort to find out what rights exist. 🤷♀️ if you want the procedures for rights in RFC documents, check BCP 78 and BCP 79.
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be made available, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr ✨
the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 🎀
funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society 🧚
📦 where this page comes from
- ietf: rfc4857 2007-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms