summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4857.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4857.txt')
-rw-r--r--doc/rfc/rfc4857.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc4857.txt b/doc/rfc/rfc4857.txt
new file mode 100644
index 0000000..4d39c3e
--- /dev/null
+++ b/doc/rfc/rfc4857.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group E. Fogelstroem
+Request for Comments: 4857 A. Jonsson
+Category: Experimental Ericsson
+ C. Perkins
+ Nokia Siemens Networks
+ June 2007
+
+
+ Mobile IPv4 Regional Registration
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ Using Mobile IP, a mobile node registers with its home agent each
+ time it changes care-of address. This document describes a new kind
+ of "regional registrations", i.e., registrations local to the visited
+ domain. The regional registrations are performed via a new network
+ entity called a Gateway Foreign Agent (GFA) and introduce a layer of
+ hierarchy in the visited domain. Regional registrations reduce the
+ number of signaling messages to the home network, and reduce the
+ signaling delay when a mobile node moves from one foreign agent to
+ another within 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
+
+
+
+Fogelstroem, et al. Experimental [Page 1]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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 ....................................33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 2]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+1. Introduction
+
+ This document is an optional extension to the Mobile IPv4 protocol,
+ and proposes a means for mobile nodes to register locally within a
+ visited domain. By registering locally, the number of signaling
+ messages to the home network are kept to a minimum, and the signaling
+ delay is reduced.
+
+ In Mobile IP, as specified in [RFC3344], a mobile node registers with
+ its home agent each time it changes care-of address. If the distance
+ between the visited network and the home network of the mobile node
+ is large, the signaling delay for these registrations may be long.
+ We propose a solution for performing registrations locally in the
+ visited domain: regional registrations. Regional registrations
+ minimize the number of signaling messages to the home network, and
+ reduce the signaling delay when a mobile node moves from one foreign
+ agent to another within the same visited domain. This will both
+ decrease the load on the home network, and speed up the process of
+ handover within the visited domain.
+
+ Regional registrations introduce a new network node: the Gateway
+ Foreign Agent (GFA). The address of the GFA is advertised by the
+ foreign agents in a visited domain. When a mobile node first arrives
+ at this visited domain, it performs a home registration -- that is, a
+ registration with its home agent. At this registration, the mobile
+ node registers the address of the GFA as its care-of address with its
+ home agent. When moving between different foreign agents within the
+ same visited domain, the mobile node only needs to make a regional
+ registration to the GFA.
+
+ In their simplest form, regional registrations are performed
+ transparently to the home agent. Additionally, regional
+ registrations may also allow dynamic assignment of GFA. The solution
+ for dynamic GFA assignment requires support in the mobile node, the
+ foreign agent, the GFA, and the home agent.
+
+ The proposed regional registration protocol supports one level of
+ foreign agent hierarchy beneath the GFA, but the protocol may be
+ utilized to support several levels of hierarchy. Multiple levels of
+ hierarchy are not discussed in this document.
+
+ Although this document focuses on regional registrations in visited
+ domains, 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].
+
+ The following section gives an overview of regional registrations.
+
+
+
+Fogelstroem, et al. Experimental [Page 3]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+2. Overview of Regional Registrations
+
+ 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 communicates with the HA, either through an FA or directly (if
+ it has a co-located care-of address). With Regional Registrations, a
+ new entity is defined: the Gateway Foreign Agent (GFA). The GFA sits
+ between the MN/FA and HA, and to the HA, it appears as if the MN's
+ temporary care-of address is that of the GFA. When a MN moves within
+ a site, it only need interact with the GFA, so that the GFA knows at
+ what temporary address the MN is currently reachable.
+
+ Two types of registration messages are used. Regular [RFC3344]
+ Registration Requests/Replies are still used for when the MN
+ exchanges Registration Requests/Replies with the HA, but these
+ messages get forwarded through a GFA, and include new extensions.
+
+ In addition, a new pair of registration messages, Regional
+ Registration Requests/Replies, are used between MNs/FAs/GFAs for
+ intra-site signaling. A MN uses these messages to communicate its
+ new addresses to the GFA 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. Alternatively, the FA can indicate
+ that dynamic assignment of GFA is to be used. With dynamic GFA
+ assignment, the MN does not choose the GFA, rather the FA (or GFA)
+ does so after receiving a Registration Request from the MN. However,
+ in this mode the HA must understand (and support) Regional
+ Registrations in order for them to be used. This last form is not
+ transparent because the MN doesn't know in advance what GFA will be
+ used, and cannot include it in a signed message to the HA.
+
+ When a MN moves to a new domain (determined by comparing its Network
+ Access Identifier (NAI) [RFC4282] with the FA-NAI included in
+ received Agent Advertisements), it can opt to use Regional
+ Registrations. A site indicates support for Regional Registrations
+ by setting the I-bit of the Mobile IP Agent Advertisement extension.
+ In addition, such advertisements include a list of one or more care-
+ of addresses. If there is only one care-of address, this is the
+ address of the FA itself. In addition, the advertisement may include
+ the address of the GFA. A GFA care-of address of all-ones indicates
+ that dynamic assignment of GFA is supported.
+
+ A MN requests initial Regional Registration by sending a normal
+ Registration Request to the FA, but setting the care-of address to
+ that of the GFA (i.e., if it has selected it wishes to use this GFA)
+ or all-zeros (which signals a dynamic GFA assignment request). The
+ FA adds a Hierarchical FA (HFA) extension and relays the request to
+
+
+
+Fogelstroem, et al. Experimental [Page 4]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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. A GFA IP Address extension is then 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 in the same way as before,
+ except in the case of dynamic GFA assignment. In this case, the HA
+ uses the GFA address from the GFA IP Address extension as the MN's
+ current care-of address. In addition, the Registration Reply message
+ must include the GFA IP Address extension.
+
+ The regular Registration Requests/Replies are protected as described
+ in [RFC3344], by use of the mobility security association between the
+ MN and the HA. For regional registrations, it is 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 use of this security association between the
+ MN and the GFA, e.g., by use of a MN-GFA Authentication extension.
+
+ HFA extensions, added by an FA 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 prior to regional registrations.
+
+ Dynamic GFA assignment requires means for securely sending
+ Registration Requests from the GFA to the HA, in order to protect the
+ GFA IP Address extension.
+
+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].
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 5]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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].
+
+
+
+
+Fogelstroem, et al. Experimental [Page 6]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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 provides an overview of the regional registration
+ protocol.
+
+4.1. General Assumptions
+
+ Our general model of operation is illustrated in Figure 1, showing a
+ visited domain with FA and GFA, and a home network with a 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.
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 7]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+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
+ there exist established security associations between a GFA and the
+ FAs beneath it. When designing a domain supporting 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.
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 8]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+4.2. Protocol Overview
+
+ When a MN first arrives at a visited domain, it performs a
+ registration with its home network. During this registration, the HA
+ registers the care-of address of the MN. In case the visited domain
+ supports regional registrations, the care-of address that is
+ registered at the HA is the address of a GFA. The GFA keeps a
+ visitor list of all the MNs currently registered with it.
+
+ Since the care-of address registered at the HA is the GFA address, it
+ will not change when the MN changes FA under the same GFA. Thus, the
+ HA does not need to be informed of further MN movements within the
+ visited domain.
+
+ Figure 2 illustrates the signaling message flow for home
+ registration. During the 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 Registration
+
+ Figure 3 illustrates the signaling message flow for regional
+ registration. Even though the MN's local care-of address changes,
+ the HA continues to use the GFA address as the care-of address of the
+ MN. We introduce two new message types for regional registrations:
+ Regional Registration Request and Regional Registration Reply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 9]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ MN FA2 GFA HA
+ | | | |
+ | Regional Reg. Req. | | |
+ |---------------------->| Regional Registration Req. | |
+ | |----------------------------->| |
+ | | Regional Registration Reply | |
+ | Regional Reg. Reply |<-----------------------------| |
+ |<----------------------| | |
+ | | | |
+
+ Figure 3: Regional Registration
+
+4.3. Advertising Foreign Agent and GFA
+
+ A FA typically announces its presence via an Agent Advertisement
+ message [RFC3344]. If the domain to which an FA belongs supports
+ regional registrations, the following changes apply to the Agent
+ Advertisement.
+
+ The 'I' flag (see Section 8.1) MUST be set to indicate 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 is only one care-of
+ address, it is the address of the FA. If the 'I' flag is set, and
+ there is more than one care-of address, the first care-of address is
+ the local FA, and the last care-of address is the GFA. (Any care-of
+ addresses advertised in addition to these two are out of scope for
+ this document).
+
+ The FA-NAI (see Section 8.2) SHOULD also be present in the Agent
+ Advertisement to enable the MN to decide whether or not it has moved
+ to a new domain since its last registration. The decision is based
+ on whether the realm part of the advertised FA-NAI matches the realm
+ of the FA-NAI advertised by the MN's previous FA.
+
+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 allows MNs that don't support regional
+ registrations to register via 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 a HA that
+ doesn't, will still be able to make use of regional registrations
+ through that GFA care-of address.
+
+
+
+
+Fogelstroem, et al. Experimental [Page 10]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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 description of home registration, i.e.,
+ registration with the HA (on the home network). Home registration is
+ performed when a MN first arrives at a visited domain, when it
+ requests a new HA, or when it changes GFA. Home registration is also
+ performed to renew bindings which would otherwise expire.
+
+5.1. Mobile Node Considerations
+
+ Upon receipt of an Agent Advertisement message with the 'I' flag set
+ and an FA-NAI extension, the MN compares the domain part of the FA
+ NAI with the one received in the previous Agent Advertisement, to
+ determine whether it has moved to a new domain since its last
+ registration. If the NAIs do not match, the MN MUST assume it has
+ moved to a new domain.
+
+ If the MN determines that it has moved to a new domain, it SHOULD
+ insert the advertised GFA address in the care-of address field in 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 then finds out 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 established 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 receives an Agent Advertisement with the 'R' bit set, even
+ if it has a co-located care-of address, it still formulates the same
+ Registration Request message with extensions, but it sends the
+ message to the advertising FA instead of to the GFA.
+
+
+
+Fogelstroem, et al. Experimental [Page 11]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ If the home registration is about to expire, the MN performs 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 not yet
+ sent a Regional Registration Request when the home registration is
+ due to expire, the MN sends only a Registration Request, as this will
+ update 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 be used for replay protection in the next Regional Registration
+ Request (see Section 6.1).
+
+5.2. Foreign Agent Considerations
+
+ When the FA receives a Registration Request message from a MN, it
+ extracts the care-of address field to find the GFA to which the
+ message shall be relayed. 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 receives 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 requesting
+ 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
+ maintains 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 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).
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 12]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+5.3. GFA Considerations
+
+ For each pending or current home registration, the GFA maintains a
+ visitor list entry as described in [RFC3344]. This visitor list
+ entry is also updated for the regional registrations performed by the
+ MN. In addition to the fields required in [RFC3344], the list entry
+ MUST contain:
+
+ o the current care-of address of the MN (i.e., the FA or co-located
+ address) received in the HFA extension
+ o the remaining Lifetime of the regional registration
+ o the style of replay protection in use for the regional
+ registration
+ o 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 sent by the MN in the Registration
+ Request is not 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, with the GFA's time of day in the Identification
+ field to synchronize the MN with the GFA for the regional
+ registrations.
+
+ If nonce-based replay protection is used, the GFA adds a Replay
+ Protection Style extension to the Registration Reply, where the high-
+ order 32 bits in the Identification fields is the nonce that should
+ be used by the MN in the following regional registration.
+
+ If the Registration Request contains a Replay Protection Style
+ extension (see Section 9.3) requesting a style of replay protection
+ not supported by the GFA, the GFA MUST reject the Registration
+ Request and send a Registration Reply with the value in the Code
+ field set to REPLAY_PROT_UNAVAIL (see Section 9.5).
+
+ If the Hierarchical Foreign Agent (HFA) extension comes after the
+ MN-FA Authentication extension, the GFA MUST remove it from the
+ Registration Request. The GFA then sends the Registration Request to
+ the HA. Upon receipt of the Registration Reply, the GFA consults its
+ pending registration record to find the care-of address within its
+ domain that is currently used by the MN, and sends the Registration
+ Reply to that care-of address.
+
+ If the Replay Protection Style extension (see Section 9.3) is present
+ in a Registration Request, and follows the MN-HA Authentication
+ extension, the GFA SHOULD remove the Replay Protection Style
+ extension after performing any necessary processing and before
+ sending the Registration Request to the HA.
+
+
+
+Fogelstroem, et al. Experimental [Page 13]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ If the GFA receives a Registration Request from a MN that it already
+ has a mobility binding for, this is an update of a binding that is
+ about to expire. If the address in the Hierarchical Foreign Agent
+ (HFA) extension is the same as the current care-of address in the
+ visitor list for the MN, the entries in the visitor list concerning
+ regional registrations are not changed, except to update the
+ lifetime. If the address in the HFA extension is a new address, the
+ values for the regional registration are updated.
+
+ If the Registration Request has the 'T' bit set, the GFA has to
+ decapsulate the packets from the FA and re-encapsulate them for
+ further delivery back to the HA. These actions are required because
+ the HA has to receive such packets from the expected care-of address
+ (i.e., that of the GFA) instead of the local care-of address (i.e.,
+ that of the FA).
+
+ When receiving a Registration Reply from the HA, the GFA MAY add a
+ Regional Registration Lifetime extension to the message before
+ relaying it to the FA. The extension defines the lifetime that the
+ GFA allows the MN before it 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 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 Registration Request is processed by the HA as described in
+ [RFC3344].
+
+6. Regional Registration
+
+ This section describes regional registrations. Once the HA has
+ registered the GFA address as the care-of address of the MN, the MN
+ may perform regional registrations. When performing regional
+ registrations, the MN may either register an FA care-of address or a
+ co-located address with the GFA. In the following, we assume that a
+ home registration has already occurred, as described in Section 5,
+ and that the GFA has a mobility security association with the MN.
+
+ Suppose the MN moves from one FA to another FA within the same
+ visited domain. It will then receive an Agent Advertisement from the
+ new FA. Suppose further that the Agent Advertisement indicates that
+ the visited domain supports regional registrations, and either that
+ the advertised GFA address is the same as the one the MN has
+ registered as its care-of address during its last home registration,
+ or that the realm part of the newly advertised FA-NAI matches the FA-
+
+
+
+Fogelstroem, et al. Experimental [Page 14]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ NAI advertised by the MN's previous FA. Then, the MN can perform a
+ regional registration with this FA and GFA. The MN issues a Regional
+ Registration Request to the GFA via the new FA. The request is
+ authenticated using 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 contains 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 the
+ information in the HFA extension, the GFA updates the MN's current
+ point of attachment in its visitor list. The GFA then issues a
+ Regional Registration Reply to the MN via the FA.
+
+ If the advertised GFA is not the same as the one the MN has
+ registered as its care-of address, and if the MN is still within the
+ same domain as it was when it registered that care-of address, the MN
+ MAY try to perform a regional registration with its registered GFA.
+ If the FA cannot support regional registration to a GFA, other than
+ advertised, the FA denies the Regional Registration Request with code
+ UNKNOWN_GFA (see Section 10.3). In this case, the MN has to do a new
+ home registration via the new GFA.
+
+ New message types are introduced for the Regional Registration
+ Request and Reply. The motivation for introducing new message types,
+ rather than using the Registration Request and Reply defined in
+ [RFC3344] is: (1) the MN must be able to distinguish regional
+ registrations from home registrations, since in the former case the
+ timestamps/nonces are synchronized with its GFA and in the latter
+ with its HA; and (2) a home registration MUST be directed to the home
+ network before the lifetime of the GFA care-of address expires.
+
+6.1. Mobile Node Considerations
+
+ For each pending or current home registration, the MN maintains the
+ information described in [RFC3344]. The information is also updated
+ for the regional registrations performed by the MN. In addition to
+ the information described in [RFC3344], the MN MUST maintain the
+ following information, if present:
+
+ o the GFA address
+ o the remaining Lifetime of the regional registration
+ o the style of replay protection in use for the regional
+ registration
+ o the Identification value for the regional registration.
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 15]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ The replay protection for home registrations and regional
+ registrations is performed as described in [RFC3344]. Since the MN
+ performs regional registrations at the GFA in parallel with home
+ registrations at the HA, 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.
+
+ For regional registrations, replay protection may also be provided at
+ the FA by the challenge-response mechanism, as described in
+ [RFC4721].
+
+6.2. Foreign Agent Considerations
+
+ When the FA receives a Regional Registration Request from a MN,
+ addressed to a GFA, it generally processes the message according to
+ the rules of processing a Registration Request addressed to a HA (see
+ Section 5.2). The only difference is that the GFA IP address field
+ replaces the HA address field. If that address belongs to a known
+ GFA, the FA forwards the request to the indicated GFA. Otherwise,
+ the FA MUST generate a Regional Registration Reply with error code
+ UNKNOWN_GFA.
+
+ For each pending or current registration, the FA maintains 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]. This is required so
+ that the FA can tunnel datagrams, sent by the MN, to the GFA. The
+ GFA then decapsulates the datagrams, re-encapsulates them, and sends
+ them 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 put this
+ lifetime into the corresponding Regional Registration Reply. The GFA
+ MUST NOT accept a request for a regional registration if the lifetime
+ of the MN's registration with its HA has expired. In that case, the
+ GFA sends a Regional Registration Reply with the value in the Code
+ field set to NO_HOME_REG.
+
+ If the GFA receives a tunneled packet from an FA in its domain, then
+ after decapsulation the GFA looks to see whether it has an entry in
+ its visitor list for the source IP address of the inner IP header
+ after decapsulation. If so, it checks the visitor list to see
+ whether reverse tunneling has been requested; if it was requested,
+ the GFA re-encapsulates the packet with its own address as the source
+ IP address, and the address of the HA as the destination IP address.
+
+
+
+Fogelstroem, et al. Experimental [Page 16]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+7. Dynamic GFA Assignment
+
+ Regional registrations may also allow dynamic assignment of a GFA to
+ a MN. The visited network (i.e., the FA) indicates support for
+ 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 request a dynamically assigned
+ GFA. Upon receiving this Registration Request, the FA relays it to
+ the appropriate GFA, and the GFA assigns its address to the MN by
+ means of a GFA IP Address extension added to the Registration
+ Request.
+
+ In order for dynamic GFA assignment to work, the MN, GFA, and HA,
+ respectively, MUST support the GFA IP Address extension. Also, the
+ FA MUST be able to advertise an all-ones care-of address and handle a
+ Registration Request with an all-zeros care-of address.
+
+ Note also that protection of the GFA IP Address extension, added to
+ the Registration Request, requires either the use of an FA-HA
+ Authentication extension or other means to secure the Registration
+ Request when forwarded from the GFA to the HA.
+
+7.1. Mobile Node Considerations for Dynamic GFA Assignment
+
+ If the 'I' flag in the Agent Advertisement sent out by the FA is set,
+ and the care-of address indicating the GFA is set to all-ones, this
+ indicates support for dynamic GFA assignment.
+
+ If the MN supports dynamic GFA assignment, and if the advertised GFA
+ address is all-ones, the MN SHOULD set the care-of address field in
+ the Registration Request to all-zeros to request to be assigned a
+ GFA.
+
+ When requesting dynamic GFA assignment, the MN MUST check to make
+ sure that it receives a GFA IP Address extension in the Registration
+ Reply.
+
+7.2. Foreign Agent Considerations for Dynamic GFA Assignment
+
+ If an FA supports dynamic GFA assignment, and receives a Registration
+ Request with the care-of address field set to all-zeros, the FA
+ assigns a GFA to the MN. A FA can either have a default GFA that it
+ assigns to all MNs or it can assign a GFA by some means not described
+ in this specification.
+
+ If an FA that does not support dynamic GFA assignment receives a
+ Registration Request with the care-of address field set to all-zeros,
+ the FA will deny the request as described in [RFC3344], i.e., by
+
+
+
+Fogelstroem, et al. Experimental [Page 17]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ sending a Registration Reply with the Code field set to "invalid
+ care-of address".
+
+7.3. GFA Considerations for Dynamic GFA Assignment
+
+ If a GFA supports dynamic GFA assignment, and receives a Registration
+ Request with the care-of address field set to all-zeros, the GFA
+ assigns its own IP address as care-of address for this MN, and adds a
+ GFA IP Address extension with this address to the Registration
+ Request. The GFA MUST NOT insert the GFA IP address directly in the
+ care-of address field in the Registration Request, since that would
+ cause the MN-HA authentication to fail.
+
+ The GFA IP Address extension has to be protected so that it cannot be
+ changed by a malicious node when the Registration Request is
+ 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. Otherwise, the Registration Request
+ MUST be sent to the HA in a secure way, for example via a secure AAA
+ protocol (e.g., [RFC4004], [RFC3957]).
+
+ If the GFA does not support dynamic GFA assignment, it will 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 receives a Registration Request with a GFA IP Address
+ extension, and the HA does not allow the use of this 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 receives a Registration Request message 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 does not support dynamic GFA assignment receives a
+ Registration Request with a GFA IP Address extension, the request
+ will be denied by the HA, as described in [RFC3344].
+
+ If a HA that supports dynamic GFA assignment receives 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. If the
+ Registration Request is accepted, the HA MUST include the GFA IP
+ Address extension in the Registration Reply, before the MN-HA
+ Authentication extension.
+
+
+
+Fogelstroem, et al. Experimental [Page 18]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+7.5. Regional Registration
+
+ If the MN receives an Agent Advertisement with the care-of address
+ field indicating the GFA set to all-ones, and if the MN determines
+ that it is within 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 specifies a new flag within the Mobile IP Agent
+ Advertisement, and an optional extension to the ICMP Router Discovery
+ Protocol [RFC1256].
+
+8.1. Regional Registration Flag
+
+ The only change to the Mobility Agent Advertisement Extension defined
+ in [RFC3344] is a flag indicating that the domain, to which the FA
+ generating the Agent Advertisement belongs, supports regional
+ registrations. The flag is inserted after the flags 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 is defined as follows:
+
+ 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 defined as subtype 3 of the NAI Carrying
+ Extension [RFC3846].
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 19]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ The FA SHOULD include its NAI in the Agent Advertisement message. If
+ present, the Foreign Agent NAI (FA-NAI) extension MUST appear in the
+ Agent Advertisement message after any of the advertisement extensions
+ defined in [RFC3344].
+
+ By comparing the domain part of the FA-NAI with the domain part of
+ the FA-NAI it received in the previous Agent Advertisement, the MN
+ can determine whether it has moved to a new domain since it last
+ registered.
+
+9. Regional Extensions to Mobile IPv4 Registration Messages
+
+ In this section, we specify new Mobile IP registration extensions for
+ the purpose of managing regional registrations.
+
+9.1. GFA IP Address Extension
+
+ The GFA IP Address extension is defined for the purpose of supporting
+ dynamic GFA assignment. If the MN requests a dynamically assigned
+ GFA, the GFA adds a GFA IP Address extension to the Registration
+ Request before relaying it to the HA. The MN indicates that it wants
+ a GFA to be 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 present.
+
+ If a HA receives a Registration Request message 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 generating a Registration Reply message, the HA MUST include the
+ GFA IP Address extension from the Registration Request in the
+ Registration Reply message. The GFA IP Address extension MUST appear
+ in the Registration Reply message before the MN-HA Authentication
+ extension.
+
+ The GFA IP Address Extension is defined as follows:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+ 46 (GFA IP Address) (non-skippable)
+
+
+
+
+Fogelstroem, et al. Experimental [Page 20]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ Length
+ 6
+
+ GFA IP Address
+ The GFA IP Address field contains 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 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. Furthermore, in this case, the extension MUST be appended at the
+ end of all previous extensions that had been included in the
+ registration message as received by the FA. The HFA extension MUST
+ be protected by an FA-FA Authentication extension. When the
+ receiving mobility agent (GFA) receives the registration message, it
+ MUST remove the HFA extension added by the sending FA.
+
+ 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
+ established 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 HFA extension is placed after
+ all other extensions, the receiving mobility agent (GFA) MUST remove
+ the HFA extension added by the MN. Otherwise, when the HA receives
+ the registration message, it ignores the HFA extension.
+
+ The Hierarchical Foreign Agent (HFA) Extension is defined as follows:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+ 140 (Hierarchical Foreign Agent) (skippable)
+
+
+
+Fogelstroem, et al. Experimental [Page 21]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ Length
+ 6
+
+ FA IP Address
+ The IP Address of the FA relaying the Registration Request.
+
+9.3. Replay Protection Style
+
+ When a MN uses Mobile IPv4 to register a care-of address with its HA,
+ the style of replay protection used for the registration messages is
+ assumed to be known by way of a mobility security association that is
+ required to exist between the MN and the HA receiving the request.
+ No such pre-existing security association between the MN and the GFA
+ is likely to be available. By default, the MN SHOULD treat replay
+ protection for Regional Registration messages exactly as specified in
+ Mobile IPv4 [RFC3344] for timestamp-based replay protection.
+
+ If the MN requires nonce-based replay protection, also as specified
+ in Mobile IPv4, it MAY append a Replay Protection Style extension to
+ a Registration Request. Since Registration Requests are forwarded to
+ the HA by way of the GFA, the GFA will be able to establish the
+ selected replay protection (see Section 5.3).
+
+ The GFA also uses this extension by adding 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.
+
+
+
+Fogelstroem, et al. Experimental [Page 22]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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 allows the GFA to set a
+ lifetime for the regional registration with an MN during its home
+ registration. When receiving a Registration Reply from the HA, the
+ GFA 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.
+
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 23]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ The Regional Registration Lifetime Extension is defined as follows:
+
+ 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]. In addition, 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 |
+ +---------------------+-------+---------------------+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 24]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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
+
+ This section specifies two new registration message types: Regional
+ Registration Request and Regional Registration Reply. These messages
+ are used by the MN instead of the existing Mobile IPv4 Registration
+ Request and Registration Reply, as described in Section 6.
+
+ Regional registration messages are protected by required
+ authentication extensions, in the same way as the existing Mobile
+ IPv4 registration messages are protected. The following rules apply
+ to authentication extensions:
+
+ o The MN-GFA Authentication extension [RFC3344] MUST be included in
+ all regional registration messages.
+ o The MN-FA Authentication extension [RFC3344] MAY be included in
+ regional registration messages.
+ o The FA-HA Authentication extension [RFC3344] MUST NOT be included
+ in any regional registration message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 25]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+10.1. Regional Registration Request
+
+ The Regional Registration Request is used by a MN to register 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.
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 26]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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
+
+ The Regional Registration Reply delivers the indication of regional
+ registration acceptance or denial to a MN.
+
+ In the Regional Registration Reply, the UDP header is followed by the
+ Mobile IP fields shown below:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Home Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | GFA IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Identification +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extensions ...
+ +-+-+-+-+-+-+-+-
+
+ This message is defined as the Registration Reply message in
+ [RFC3344], but with the following changes:
+
+ 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.
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 27]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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 0xffff indicates 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.
+
+ 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, the following additional Code
+ values are defined in addition to those specified in 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 |
+ +-------------+-------+---------------------+
+
+
+
+Fogelstroem, et al. Experimental [Page 28]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ The four first Code values are returned to the MN in response to ICMP
+ errors that may be received by the FA.
+
+11. Authentication Extensions
+
+ In this section, two new subtypes for the Generalized Authentication
+ Extension [RFC4721] are specified. First, the FA-FA Authentication
+ extension is used by FAs to secure the HFA extension to the
+ Registration Request and Regional Registration Request messages. A
+ new authentication extension is necessary because the HFA extension
+ is typically added after the MN-HA Authentication extension or, e.g.,
+ the MN-AAA Authentication extension [RFC4721].
+
+ The MN-GFA Authentication extension is used whenever the MN has a co-
+ located address. The MN-GFA Authentication extension is also used to
+ provide authentication for a Regional Registration Request.
+
+ The subtype values for these new subtypes are as follows:
+
+ +-----------------------+-------+
+ | Subtype Name | Value |
+ +-----------------------+-------+
+ | FA-FA authentication | 2 |
+ | MN-GFA authentication | 3 |
+ +-----------------------+-------+
+
+ The default algorithm for computation of the authenticator is the
+ same as for the MN-AAA Authentication subtype defined in [RFC4721].
+
+12. Security Considerations
+
+ 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. In case of the
+ GFA IP Address extension being added to a Registration Request, it
+ should be protected by an FA-HA Authentication extension. If no
+
+
+
+Fogelstroem, et al. Experimental [Page 29]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+ 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:
+
+ o 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.
+
+ o 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.
+
+ o New Code values for Registration Reply messages (see Section 9.5).
+
+ o Two new subtypes for the Generalized Authentication Extension
+ [RFC4721]; see Section 11.
+
+ o Two new message types for Mobile IP: Regional Registration Request
+ and Regional Registration Reply (see Sections 10.1 and 10.2).
+
+ o Code values for Regional Registration Reply messages (see Section
+ 10.3).
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 30]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 31]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+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.
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 32]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+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:
+
+ o The GFA MAY include the Mobile IP Registration Request data inside
+ an authorization request, directed to a local AAA server.
+
+ o 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 is 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 33]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+Authors' Addresses
+
+ Eva Fogelstroem
+ Ericsson
+ Torshamnsgatan 23
+ SE-164 80 Stockholm
+ Sweden
+
+ EMail: eva.fogelstrom@ericsson.com
+
+
+ Annika Jonsson
+ Ericsson
+ Tellusborgsvagen 83-87
+ S-126 37 Hagersten
+ Sweden
+
+ EMail: annika.jonsson@ericsson.com
+
+
+ Charles E. Perkins
+ Nokia Siemens Networks
+ 313 Fairchild Drive
+ Mountain View, California 94043
+ USA
+
+ EMail: charles.perkins@nsn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 34]
+
+RFC 4857 Mobile IPv4 Regional Registration June 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Fogelstroem, et al. Experimental [Page 35]
+