idnits 2.17.1 draft-ietf-mip4-reg-tunnel-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1542. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6366 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 3012 (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group E. Fogelstroem 3 Internet-Draft A. Jonsson 4 Intended status: Informational Ericsson 5 Expires: April 26, 2007 C. Perkins 6 Nokia Research Center 7 October 23, 2006 9 Mobile IPv4 Regional Registration 10 draft-ietf-mip4-reg-tunnel-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 26, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Using Mobile IP, a mobile node registers with its home agent each 44 time it changes care-of address. This document describes a new kind 45 of "regional registrations", i.e. registrations local to the visited 46 domain. The regional registrations are performed via a new network 47 entity called a Gateway Foreign Agent (GFA) and introduce a layer of 48 hierarchy in the visited domain. Regional registrations reduce the 49 number of signaling messages to the home network, and reduce the 50 signaling delay when a mobile node moves from one foreign agent to 51 another within the same visited domain. This document is an optional 52 extension to the Mobile IPv4 protocol. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Overview of Regional Registrations . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Description of the Protocol . . . . . . . . . . . . . . . . . 8 60 4.1. General Assumptions . . . . . . . . . . . . . . . . . . . 8 61 4.1.1. Visited Domain . . . . . . . . . . . . . . . . . . . . 9 62 4.1.2. Authentication . . . . . . . . . . . . . . . . . . . . 9 63 4.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10 64 4.3. Advertising Foreign Agent and GFA . . . . . . . . . . . . 11 65 4.4. Backwards compatibility with RFC 3344 . . . . . . . . . . 11 66 5. Home Registration . . . . . . . . . . . . . . . . . . . . . . 12 67 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 12 68 5.2. Foreign Agent Considerations . . . . . . . . . . . . . . . 13 69 5.3. GFA Considerations . . . . . . . . . . . . . . . . . . . . 14 70 5.4. Home Agent Considerations . . . . . . . . . . . . . . . . 15 71 6. Regional Registration . . . . . . . . . . . . . . . . . . . . 15 72 6.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 16 73 6.2. Foreign Agent Considerations . . . . . . . . . . . . . . . 17 74 6.3. GFA Considerations . . . . . . . . . . . . . . . . . . . . 17 75 7. Dynamic GFA Assignment . . . . . . . . . . . . . . . . . . . . 18 76 7.1. Mobile Node Considerations for Dynamic GFA Assignment . . 18 77 7.2. Foreign Agent Considerations for Dynamic GFA Assignment . 19 78 7.3. GFA Considerations for Dynamic GFA Assignment . . . . . . 19 79 7.4. Home Agent Considerations for Dynamic GFA Assignment . . . 19 80 7.5. Regional Registration . . . . . . . . . . . . . . . . . . 20 81 8. Router Discovery Extensions . . . . . . . . . . . . . . . . . 20 82 8.1. Regional Registration Flag . . . . . . . . . . . . . . . . 20 83 8.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . . 21 84 9. Regional Extensions to Mobile IPv4 Registration Messages . . . 21 85 9.1. GFA IP Address Extension . . . . . . . . . . . . . . . . . 21 86 9.2. Hierarchical Foreign Agent Extension . . . . . . . . . . . 22 87 9.3. Replay Protection Style . . . . . . . . . . . . . . . . . 23 88 9.4. Regional Registration Lifetime Extension . . . . . . . . . 25 89 9.5. New Code Values for Registration Reply . . . . . . . . . . 26 90 10. Regional Registration Message Formats . . . . . . . . . . . . 26 91 10.1. Regional Registration Request . . . . . . . . . . . . . . 27 92 10.2. Regional Registration Reply . . . . . . . . . . . . . . . 28 93 10.3. New Regional Registration Reply Code Values . . . . . . . 29 94 11. Authentication Extensions . . . . . . . . . . . . . . . . . . 30 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 96 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 97 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 100 15.2. Informative References . . . . . . . . . . . . . . . . . . 33 101 Appendix A. Authentication, Authorization and Accounting 102 (AAA) Interactions . . . . . . . . . . . . . . . . . 33 103 Appendix B. Anchoring at a GFA . . . . . . . . . . . . . . . . . 33 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 105 Intellectual Property and Copyright Statements . . . . . . . . . . 35 107 1. Introduction 109 This document is an optional extension to the Mobile IPv4 protocol, 110 and proposes a means for mobile nodes to register locally within a 111 visited domain. By registering locally, the number of signaling 112 messages to the home network are kept to a minimum, and the signaling 113 delay is reduced. 115 In Mobile IP, as specified in [RFC3344], a mobile node registers with 116 its home agent each time it changes care-of address. If the distance 117 between the visited network and the home network of the mobile node 118 is large, the signaling delay for these registrations may be long. 119 We propose a solution for performing registrations locally in the 120 visited domain: regional registrations. Regional registrations 121 minimize the number of signaling messages to the home network, and 122 reduce the signaling delay when a mobile node moves from one foreign 123 agent to another within the same visited domain. This will both 124 decrease the load on the home network, and speed up the process of 125 handover within the visited domain. 127 Regional registrations introduce a new network node: the Gateway 128 Foreign Agent (GFA). The address of the GFA is advertised by the 129 foreign agents in a visited domain. When a mobile node first arrives 130 at this visited domain, it performs a home registration - that is, a 131 registration with its home agent. At this registration, the mobile 132 node registers the address of the GFA as its care-of address with its 133 home agent. When moving between different foreign agents within the 134 same visited domain, the mobile node only needs to make a regional 135 registration to the GFA. 137 In its simplest form, regional registrations are performed 138 transparently to the home agent. Additionally, regional 139 registrations may also allow dynamic assignment of GFA. The solution 140 for dynamic GFA assignment requires support in the mobile node, the 141 foreign agent, the GFA and the home agent. 143 The proposed regional registration protocol supports one level of 144 foreign agent hierarchy beneath the GFA, but the protocol may be 145 utilized to support several levels of hierarchy. Multiple levels of 146 hierarchy is not discussed in this document. 148 Although this document focuses on regional registrations in visited 149 domains, regional registrations are also possible in the home domain. 151 Foreign agents that support regional registrations are also required 152 to support registrations according to Mobile IPv4 [RFC3344]. 154 The following section gives an overview of regional registrations. 156 2. Overview of Regional Registrations 158 In standard Mobile IP, there are three entities of interest. The 159 Mobile Node (MN), the Foreign Agent (FA), and the Home Agent (HA). 160 The MN communicates with the HA, either through an FA, or directly 161 (if it has a co-located care-of address). With Regional 162 Registrations, a new entity is defined: the Gateway Foreign Agent 163 (GFA). The GFA sits between the MN/FA and HA, and to the HA, it 164 appears as if the MN's temporary care-of address is that of the GFA. 165 When a MN moves within a site, it only need interact with the GFA, so 166 that the GFA knows at what temporary address the MN is currently 167 reachable. 169 Two types of registration messages are used. Regular [RFC3344] 170 Registration Requests/Replies are still used for when the MN 171 exchanges Registration Requests/Replies with the HA, but these 172 messages get forwarded through a GFA, and include new extensions. 174 In addition, a new pair of registration messages, Regional 175 Registration Requests/Replies, are used between MNs/FAs/GFAs for 176 intra-site signaling. A MN uses these messages to communicate its 177 new addresses to the GFA as it moves around within a site. 179 There are two models of how the MN uses Regional Registrations. The 180 FA can advertise a GFA to the MN. Alternatively, the FA can indicate 181 that dynamic assignment of GFA is to be used. With dynamic GFA 182 assignment, the MN does not choose the GFA, rather the FA (or GFA) 183 does so after receiving a Registration Request from the MN. However, 184 in this mode the HA must understand (and support) Regional 185 Registrations in order for them to be used. This last form is not 186 transparent because the MN doesn't know in advance what GFA will be 187 used, and cannot include it in a signed message to the HA. 189 When a MN moves to a new domain (determined by comparing its Network 190 Access Identifier (NAI) [RFC4282] with the FA-NAI included in 191 received Agent Advertisements), it can opt to use Regional 192 Registrations. A site indicates support for Regional Registrations 193 by setting the I-bit of the Mobile IP Agent Advertisement extension. 194 In addition, such advertisements include a list of one or more 195 care-of addresses. If there is only one care-of address, this is the 196 address of the FA itself. In addition, the advertisement may include 197 the address of the GFA. A GFA care-of address of all-ones indicates 198 that dynamic assignment of GFA is supported. 200 A MN requests initial Regional Registration by sending a normal 201 Registration Request to the FA, but setting the care-of address to 202 that of the GFA (i.e., if it has selected it wishes to use this GFA) 203 or all-zeros (which signals a dynamic GFA assignment request). The 204 FA adds a Hierarchical FA (HFA) extension and relays the request to 205 the appropriate GFA. The HFA extension contains a single field: the 206 IP address of the FA. 208 Note: the algorithm for MNs with co-located care-of addresses is 209 similar, except that there is no FA, so the MN behaves as the FA in 210 terms of the messages it sends. 212 A GFA receives Registration Requests relayed from a FA. If the 213 care-of address in the received Registration Request is zero, the GFA 214 assigns one. A GFA IP Address extension is then added to the 215 Registration Request, and the message is forwarded to the HA. The 216 GFA IP Address extension contains a single field: the IP address of 217 the GFA. (A separate field is needed for this because the 218 Registration Request message between the MN/HA is signed and cannot 219 be modified.) 221 HAs process received Registration Requests in the same way as before, 222 except in the case of dynamic GFA assignment. In this case, the HA 223 uses the GFA address from the GFA IP Address extension as the MN's 224 current care-of address. In addition, the Registration Reply message 225 must include the GFA IP Address extension. 227 The regular Registration Requests/Replies are protected as described 228 in [RFC3344], by use of the mobility security association between the 229 MN and the HA. For regional registrations, it is assumed that a 230 mobility security association is established between the MN and GFA 231 during registration with the HA. Regional Registration Requests/ 232 Replies are protected by use of this security association between the 233 MN and the GFA, e.g., by use of a MN-GFA Authentication extension. 235 HFA extensions, added by a FA to a Registration Request or Regional 236 Registration Request, are protected by an FA-FA Authentication 237 extension. Security associations between FAs and GFAs within a 238 domain are assumed to exist prior to regional registrations. 240 Dynamic GFA assignment requires means for securely sending 241 Registration Requests from the GFA to the HA, in order to protect the 242 GFA IP Address extension. 244 3. Terminology 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 248 document are to be interpreted as described in RFC 2119 [RFC2119]. 250 This document uses the following terms: 252 Critical type 253 A type value for an extension in the range 0-127, which indicates 254 that the extension MUST either be known to the recipient, or that 255 the message containing the extension MUST be rejected. In other 256 words, an extension with a critical type value is non-skippable. 258 Domain 259 A collection of networks sharing a common network administration. 261 Foreign Agent (FA) 262 As defined in [RFC3344]. 264 Gateway Foreign Agent (GFA) 265 A Foreign Agent which has a publicly routable IP address. A GFA 266 may, for instance, be placed in or near a firewall. 268 Home Agent (HA) 269 As defined in [RFC3344]. 271 Home domain 272 The domain where the home network and home agent are located. 274 Home network 275 As defined in [RFC3344]. 277 Home Registration 278 A registration, processed by the home agent and the GFA, using the 279 specification in [RFC3344] possibly with additional extensions 280 defined in this document. 282 Local Care-of Address 283 A care-of address which is either assigned to a mobile node, or to 284 a foreign agent offering local connectivity to a mobile node. A 285 registration message from the mobile node is subsequently sent to 286 a GFA via the local care-of address. 288 Mobile Node (MN) 289 As defined in [RFC3344]. 291 Mobility Agent (MA) 292 As defined in [RFC3344]. 294 Network Access Identifier(NAI) 295 Some features of this protocol specification rely on use of the 296 Network Access Identifier (NAI) [RFC2794]. 298 Regional Registration 299 A mobile node performs registration locally at the visited domain, 300 by sending a Regional Registration Request to a GFA, and receiving 301 a Regional Registration Reply in return. 303 Registration Key 304 A key used by mobile nodes and mobility agents to secure certain 305 signals and control messages specified by Mobile IP. 307 Visited domain 308 The domain where the visited network, the current foreign agent 309 and the GFA are located. 311 Visited network 312 As defined in [RFC3344]. 314 4. Description of the Protocol 316 This section provides an overview of the regional registration 317 protocol. 319 4.1. General Assumptions 321 Our general model of operation is illustrated in Figure 1, showing a 322 visited domain with FA and GFA, and a home network with a HA: 324 +---------------------------+ +----------------+ 325 | Visited Domain | | Home | 326 | | +---------+ | Network | 327 | | | | | | 328 | +------+ +-------+ | | Public | | +------+ | 329 | | FA |------| GFA |-------------------------| HA | | 330 | +--+---+ +-------+ | | Network | | +------+ | 331 | | | | | | | 332 +-----|---------------------+ +---------+ +----------------+ 333 | 334 +--+---+ 335 | MN | 336 +------+ 338 Figure 1 340 For MNs that cannot process a NAI, or with mobility agents that are 341 not configured to advertise their NAI, regional registration is still 342 useful, but the lack of certain features may result in less than 343 optimal results. 345 4.1.1. Visited Domain 347 We assume two hierarchy levels of FAs in the visited domain. At the 348 top level of the hierarchy, there is at least one GFA, which is a FA 349 with additional features. A GFA must have a publicly routable 350 address. Beneath a GFA, there are one or more FAs. We assume that 351 there exist established security associations between a GFA and the 352 FAs beneath it. When designing a domain supporting regional 353 registrations, the FAs and GFAs in this domain must be compatible. 354 That is, they should support the same encapsulation types, 355 compression mechanisms etc. 357 When a MN changes care-of address under the same GFA, it MAY perform 358 a regional registration. If the MN changes GFA, within a visited 359 domain or between visited domains, it MUST perform a home 360 registration. 362 4.1.2. Authentication 364 With regional registrations, a GFA address is registered at the HA as 365 the care-of address of the MN. If a Mobile-Foreign (MN-FA) 366 Authentication extension is present in a Registration Request message 367 directed to the HA, the GFA will perform the authentication. 368 Similarly, if a Foreign-Home (FA-HA) Authentication extension is 369 present in a Registration Request message, the authentication is 370 performed between the GFA and the HA. To summarize, the GFA takes 371 the role of a FA with regard to security associations in the home 372 registrations. 374 Regional registration messages also need to be protected with 375 authentication extensions in the same way as registrations with the 376 HA. This means that the MN and the GFA MUST have received the keys 377 needed to construct the authentication extensions before any regional 378 registration is performed. As described above, since the GFA address 379 is the registered care-of address of the MN at its home network, the 380 GFA is the agent within the visited domain which has to have the 381 appropriate security associations with the HA and the MN. The GFA's 382 security association with the MN is then used to enable proper 383 authentication for regional registrations (see Section 6). How the 384 keys are distributed is outside the scope of this draft. One example 385 is to distribute the keys as part of the home registration, for 386 example according to [RFC4004], [RFC3957]. Another example is pre- 387 configured keys. 389 4.2. Protocol Overview 391 When a MN first arrives at a visited domain, it performs a 392 registration with its home network. At this registration, the HA 393 registers the care-of address of the MN. In case the visited domain 394 supports regional registrations, the care-of address that is 395 registered at the HA is the address of a GFA. The GFA keeps a 396 visitor list of all the MNs currently registered with it. 398 Since the care-of address registered at the HA is the GFA address, it 399 will not change when the MN changes FA under the same GFA. Thus, the 400 HA does not need to be informed of further MN movements within the 401 visited domain. 403 Figure 2 illustrates the signaling message flow for home 404 registration. At home registration, the HA records the GFA address 405 as the care-of address of the MN. 407 Registration at the GFA and the HA: 409 MN FA1 GFA HA 410 | | | | 411 | Registration Request | | | 412 |---------------------->| Reg. Request | | 413 | |---------------------->| Reg. Request | 414 | | |--------------->| 415 | | | Reg. Reply | 416 | | Reg. Reply |<---------------| 417 | Registration Reply |<----------------------| | 418 |<----------------------| | | 419 | | | | 421 Figure 2 423 Figure 3 illustrates the signaling message flow for regional 424 registration. Even though the MN's local care-of address changes, 425 the HA continues to record the GFA address as the care-of address of 426 the MN. We introduce two new message types for regional 427 registrations: Regional Registration Request and Regional 428 Registration Reply. 430 Regional Registration at the GFA: 432 MN FA2 GFA HA 433 | | | | 434 | Regional Reg. Req. | | | 435 |---------------------->| Regional Registration Req. | | 436 | |----------------------------->| | 437 | | Regional Registration Reply | | 438 | Regional Reg. Reply |<-----------------------------| | 439 |<----------------------| | | 440 | | | | 442 Figure 3 444 4.3. Advertising Foreign Agent and GFA 446 A FA typically announces its presence via an Agent Advertisement 447 message [RFC3344]. If the domain to which a FA belongs supports 448 regional registrations, the following changes apply to the Agent 449 Advertisement. 451 The 'I' flag (see Section 8.1) MUST be set to indicate that the 452 domain supports regional registrations. If the 'I' flag is set, 453 there MUST be at least one care-of address in the Agent 454 Advertisement. If the 'I' flag is set and there is only one care-of 455 address it is the address of the FA. If the 'I' flag is set, and 456 there is more than one care-of address, the first care-of address is 457 the local FA, and the last care-of address is the GFA. (Any care-of 458 addresses advertised in addition to these two are out of scope for 459 this document.) 461 The FA-NAI (see Section 8.2) SHOULD also be present in the Agent 462 Advertisement to enable the MN to decide whether or not it has moved 463 to a new domain since its last registration. The decision is based 464 on whether the realm part of the advertised FA-NAI matches the realm 465 of the FA-NAI advertised by the MN's previous FA. 467 4.4. Backwards compatibility with RFC 3344 469 A domain that supports regional registrations should also be 470 backwards compatible. 472 An FA MUST support registrations according to Mobile IPv4 as defined 473 in [RFC3344]. This allows MNs that don't support regional 474 registrations to register via this FA using standard Mobile IPv4. If 475 the FA advertises both its own care-of address and a GFA care-of 476 address, a MN that supports regional registrations but has a HA that 477 doesn't, will still be able to make use of regional registrations 478 through that GFA care-of address. 480 The advertised GFA care-of address MAY be set to all-ones, to 481 indicate dynamic GFA assignment. If the MN supports regional 482 registrations, and an all-ones GFA care-of address is advertised, the 483 MN SHOULD use dynamic GFA assignment. 485 5. Home Registration 487 This section gives a detailed description of home registration, i.e., 488 registration with the HA (on the home network). Home registration is 489 performed when a MN first arrives at a visited domain, when it 490 requests a new HA, or when it changes GFA. Home registration is also 491 performed to renew bindings which would otherwise expire. 493 5.1. Mobile Node Considerations 495 Upon receipt of an Agent Advertisement message with the 'I' flag set 496 and a FA-NAI extension, the MN compares the domain part of the FA NAI 497 with the one received in the previous Agent Advertisement, to 498 determine whether it has moved to a new domain since its last 499 registration. If the NAIs do not match, the MN MUST assume it has 500 moved to a new domain. 502 If the MN determines that it has moved to a new domain, it SHOULD 503 insert the advertised GFA address in the care-of address field in the 504 Registration Request message. 506 A MN with a co-located care-of address might also want to use 507 regional registrations. It then finds out the address of a GFA, 508 either from Agent Advertisements sent by a FA, or by some means not 509 described in this draft. The MN MAY then generate a Registration 510 Request message, with the GFA address in the care-of address field, 511 and send it directly to the GFA (not via a FA). In this case, the MN 512 MUST add a Hierarchical Foreign Agent (HFA) extension (see 513 Section 9.2), including its co-located care-of address, to the 514 Registration Request before sending it. The HFA extension MUST be 515 protected by an authentication extension. If the MN has established 516 a mobility security association with the GFA, the HFA extension MUST 517 be placed before the MN-FA Authentication extension, and it SHOULD be 518 placed after the Mobile-Home (MN-HA) Authentication extension. 519 Otherwise, if the MN has no established mobility security association 520 with the GFA, the HFA extension MUST be placed before the MN-HA 521 authentication extension. 523 If the MN receives an Agent Advertisement with the 'R' bit set, even 524 if it has a co-located care-of address, it still formulates the same 525 Registration Request message with extensions, but it sends the 526 message to the advertising FA instead of to the GFA. 528 If the home registration is about to expire, the MN performs a new 529 home registration using the same GFA care-of address to refresh the 530 binding [RFC3344]. If the MN has just moved to a new FA and not yet 531 sent a Regional Registration Request when the home registration is 532 due to expire, the MN sends only a Registration Request, as this will 533 update both the GFA and the HA. 535 If the Registration Reply includes a Replay Protection Style 536 extension, the value in the Initial Identification field is the value 537 to be used for replay protection in the next Regional Registration 538 Request (see Section 6.1). 540 5.2. Foreign Agent Considerations 542 When the FA receives a Registration Request message from a MN, it 543 extracts the care-of address field to find the GFA to which the 544 message shall be relayed. All FAs that advertise the 'I' flag MUST 545 also be able to handle Registration Requests with an all-zeros 546 care-of address (used for dynamic GFA assignment). 548 If the FA receives a Registration Request where the care-of address 549 is set to "all-ones" (which could happen if a MN that doesn't support 550 Regional Registrations copied an "all-ones" care-of address from an 551 Agent Advertisement), it MUST reply with the Code field set to 552 "poorly formed request" [RFC3344]. 554 If the Registration Request has the 'T' bit set, the MN is requesting 555 Reverse Tunneling [RFC3024]. In this case, the FA has to tunnel 556 packets from the MN to the GFA for further handling. 558 If the care-of address in the Registration Request is the address of 559 the FA, the FA relays the message directly to the HA, as described in 560 [RFC3344]. For each pending or current home registration, the FA 561 maintains a visitor list entry as described in [RFC3344]. If reverse 562 tunneling is being used, the visitor list MUST, in addition to the 563 fields required in [RFC3344], contain the address of the GFA. 565 Otherwise, if the care-of address in the Registration Request is the 566 address of a GFA (or all-zeros), the FA adds a Hierarchical Foreign 567 Agent (HFA) extension, including its own address, to the Registration 568 Request, and relays it to the GFA. The HFA extension MUST be 569 appended at the end of all previous extensions that were included in 570 the Registration Request when the FA received it, and it MUST be 571 protected by a Foreign-Foreign (FA-FA) Authentication extension (see 572 Section 11). 574 5.3. GFA Considerations 576 For each pending or current home registration, the GFA maintains a 577 visitor list entry as described in [RFC3344]. This visitor list 578 entry is also updated for the regional registrations performed by the 579 MN. In addition to the fields required in [RFC3344], the list entry 580 MUST contain: 582 o the current care-of address of the MN (i.e., the FA or co-located 583 address) received in the HFA extension 584 o the remaining Lifetime of the regional registration 585 o the style of replay protection in use for the regional 586 registration 587 o the Identification value for the regional registration. 589 The default replay protection style for regional registrations is 590 timestamp-based replay protection, as defined in Mobile IPv4 591 [RFC3344]. If the timestamp sent by the MN in the Registration 592 Request is not close enough to the GFA's time of day clock, the GFA 593 adds a Replay Protection Style extension (see Section 9.3) to the 594 Registration Reply, with the GFA's time of day in the Identification 595 field to synchronize the MN with the GFA for the regional 596 registrations. 598 If nonce-based replay protection is used, the GFA adds a Replay 599 Protection Style extension to the Registration Reply, where the high- 600 order 32 bits in the Identification fields is the nonce that should 601 be used by the MN in the following regional registration. 603 If the Registration Request contains a Replay Protection Style 604 extension (see Section 9.3) requesting a style of replay protection 605 not supported by the GFA, the GFA MUST reject the Registration 606 Request and send a Registration Reply with the value in the Code 607 field set to REPLAY_PROT_UNAVAIL (see Section 9.5). 609 If the Hierarchical Foreign Agent (HFA) extension comes after the 610 MN-FA Authentication extension, the GFA MUST remove it from the 611 Registration Request. The GFA then sends the Registration Request to 612 the HA. Upon receipt of the Registration Reply, the GFA consults its 613 pending registration record to find the care-of address within its 614 domain that is currently used by the MN, and sends the Registration 615 Reply to that care-of address. 617 If the Replay Protection Style extension (see Section 9.3) is present 618 in a Registration Request, and follows the MN-HA Authentication 619 extension, the GFA SHOULD remove the Replay Protection Style 620 extension after performing any necessary processing, before sending 621 the Registration Request to the HA. 623 If the GFA receives a Registration Request from a MN that it already 624 has a mobility binding for, this is an update of a binding that is 625 about to expire. If the address in the Hierarchical Foreign Agent 626 (HFA) extension is the same as the current care-of address in the 627 visitor list for the MN, the entries in the visitor list concerning 628 regional registrations are not changed, except to update the 629 lifetime. If the address in the HFA extension is a new address, the 630 values for the regional registration are updated. 632 If the Registration Request has the 'T' bit set, the GFA has to 633 decapsulate the packets from the FA and re-encapsulate them for 634 further delivery back to the HA. These actions are required because 635 the HA has to receive such packets from the expected care-of address 636 (i.e. that of the GFA) instead of the local care-of address (that of 637 the FA). 639 When receiving a Registration Reply from the HA, the GFA MAY add a 640 Regional Registration Lifetime extension to the message before 641 relaying it to the FA. The extension defines the lifetime that the 642 GFA allows the MN before it has to renew its regional registration. 643 The GFA MUST set the lifetime of the regional registration to be no 644 greater than the remaining lifetime of the MN's registration with its 645 HA. If used, the Regional Registration Lifetime extension MUST be 646 added after any other extensions, and MUST be protected. The 647 Regional Registration Lifetime extension MUST be protected by an 648 MN-FA Authentication extension. 650 5.4. Home Agent Considerations 652 The Registration Request is processed by the HA as described in 653 [RFC3344]. 655 6. Regional Registration 657 This section describes regional registrations. Once the HA has 658 registered the GFA address as the care-of address of the MN, the MN 659 may perform regional registrations. When performing regional 660 registrations, the MN may either register a FA care-of address or a 661 co-located address with the GFA. In the following, we assume that a 662 home registration has already occurred, as described in Section 5, 663 and that the GFA has a mobility security association with the MN. 665 Suppose the MN moves from one FA to another FA within the same 666 visited domain. It will then receive an Agent Advertisement from the 667 new FA. Suppose further that the Agent Advertisement indicates that 668 the visited domain supports regional registrations, and that either 669 the advertised GFA address is the same as the one the MN has 670 registered as its care-of address during its last home registration, 671 or that the realm part of the newly advertised FA-NAI matches the FA- 672 NAI advertised by the MN's previous FA. Then, the MN can perform a 673 regional registration with this FA and GFA. The MN issues a Regional 674 Registration Request to the GFA via the new FA. The request is 675 authenticated using the existing mobility security association 676 between the GFA and the MN and the message is authenticated by the 677 MN-GFA Authentication extension (see Section 11). The care-of 678 address should be set to the address of the local FA. 680 If the Regional Registration Request contains a care-of address field 681 of all-zeros, the FA adds a Hierarchical Foreign Agent (HFA) 682 extension to the message and relays it to the GFA. Based on the 683 information in the HFA extension, the GFA updates the MN's current 684 point of attachment in its visitor list. The GFA then issues a 685 Regional Registration Reply to the MN via the FA. 687 If the advertised GFA is not the same as the one the MN has 688 registered as its care-of address, and if the MN is still within the 689 same domain as it was when it registered that care-of address, the MN 690 MAY try to perform a regional registration with its registered GFA. 691 If the FA cannot support regional registration to a GFA, other than 692 advertised, the FA denies the Regional Registration Request with code 693 UNKNOWN_GFA (see Section 10.3). In this case the MN has to do a new 694 home registration via the new GFA. 696 New message types are introduced for the Regional Registration 697 Request and Reply. The motivation for introducing new message types, 698 rather than using the Registration Request and Reply defined in 699 [RFC3344] is: (1) the MN must be able to distinguish regional 700 registrations from home registrations, since in the former case the 701 timestamps/nonces are synchronized with its GFA and in the latter 702 with its HA; and (2) a home registration MUST be directed to the home 703 network before the lifetime of the GFA care-of address expires. 705 6.1. Mobile Node Considerations 707 For each pending or current home registration, the MN maintains the 708 information described in [RFC3344]. The information is also updated 709 for the regional registrations performed by the MN. In addition to 710 the information described in [RFC3344], the MN MUST maintain the 711 following information, if present: 713 o the GFA address 714 o the remaining Lifetime of the regional registration 715 o the style of replay protection in use for the regional 716 registration 717 o the Identification value for the regional registration. 719 The replay protection for home registrations and regional 720 registrations is performed as described in [RFC3344]. Since the MN 721 performs regional registrations at the GFA in parallel with home 722 registrations at the HA, the MN MUST be able to keep one replay 723 protection mechanism and sequence for the GFA, and a separate 724 mechanism and sequence for the HA. 726 For regional registrations, replay protection may also be provided at 727 the FA by the challenge-response mechanism, as described in 728 [RFC3012]. 730 6.2. Foreign Agent Considerations 732 When the FA receives a Regional Registration Request from a MN, 733 addressed to a GFA, it generally processes the message according to 734 the rules of processing a Registration Request addressed to a HA (see 735 Section 5.2). The only difference is that the GFA IP address field 736 replaces the HA address field. If that address belongs to a known 737 GFA, the FA forwards the request to the indicated GFA. Otherwise, 738 the FA MUST generate a Regional Registration Reply with error code 739 UNKNOWN_GFA. 741 For each pending or current registration, the FA maintains a visitor 742 list entry as described in [RFC3344]. If reverse tunneling is being 743 used, the visitor list MUST contain the address of the GFA, in 744 addition to the fields required in [RFC3344]. This is required so 745 that the FA can tunnel datagrams, sent by the MN, to the GFA. The 746 GFA then decapsulates the datagrams, re-encapsulates them and sends 747 them to the HA. 749 6.3. GFA Considerations 751 If the GFA accepts a Regional Registration Request, it MUST set the 752 lifetime of the regional registration to be no greater than the 753 remaining lifetime of the MN's registration with its HA, and put this 754 lifetime into the corresponding Regional Registration Reply. The GFA 755 MUST NOT accept a request for a regional registration if the lifetime 756 of the MN's registration with its HA has expired. In that case the 757 GFA sends a Regional Registration Reply with the value in the Code 758 field set to NO_HOME_REG. 760 If the GFA receives a tunneled packet from a FA in its domain, then 761 after decapsulation the GFA looks to see whether it has an entry in 762 its visitor list for the source IP address of the inner IP header 763 after decapsulation. If so, it checks the visitor list to see 764 whether reverse tunneling has been requested; if it was requested, 765 the GFA re-encapsulates the packet with its own address as the source 766 IP address, and the address of the HA as the destination IP address. 768 7. Dynamic GFA Assignment 770 Regional registrations may also allow dynamic assignment of a GFA to 771 a MN. The visited network (i.e. the FA) indicates support for 772 dynamic GFA assignment by advertising an all-ones care-of address in 773 the Agent Advertisement. The MN then sets the care-of address in the 774 Registration Request to all-zeros to request a dynamically assigned 775 GFA. Upon receiving this Registration Request, the FA relays it to 776 the appropriate GFA, and the GFA assigns its address to the MN by 777 means of a GFA IP Address extension added to the Registration 778 Request. 780 In order for dynamic GFA assignment to work, the MN, GFA and HA 781 respectively MUST support the GFA IP Address extension. Also, the FA 782 MUST be able to advertise an all-ones care-of address and handle a 783 Registration Request with an all-zeros care-of address. 785 Note also that protection of the GFA IP Address extension, added to 786 the Registration Request, requires either the use of a FA-HA 787 Authentication extension or other means to secure the Registration 788 Request when forwarded from the GFA to the HA. 790 7.1. Mobile Node Considerations for Dynamic GFA Assignment 792 If the 'I' flag in the Agent Advertisement sent out by the FA is set, 793 and the care-of address indicating the GFA is set to all-ones, this 794 indicates support for dynamic GFA assignment. 796 If the MN supports dynamic GFA assignment, and if the advertised GFA 797 addresses is all-ones, the MN SHOULD set the care-of address field in 798 the Registration Request to all-zeros to request to be assigned a 799 GFA. 801 When requesting dynamic GFA assignment, the MN MUST check to make 802 sure that it receives a GFA IP Address extension in the Registration 803 Reply. 805 7.2. Foreign Agent Considerations for Dynamic GFA Assignment 807 If an FA supports dynamic GFA assignment, and receives a Registration 808 Request with the care-of address field set to all-zeros, the FA 809 assigns a GFA to the MN. A FA can either have a default GFA that it 810 assigns to all MNs or it can assign a GFA by some means not described 811 in this specification. 813 If a FA that does not support dynamic GFA assignment receives a 814 Registration Request with the care-of address field set to all-zeros, 815 the FA will deny the request as described in [RFC3344], i.e. by 816 sending a Registration Reply with the Code field set to "invalid 817 care-of address". 819 7.3. GFA Considerations for Dynamic GFA Assignment 821 If a GFA supports dynamic GFA assignment, and receives a Registration 822 Request with the care-of address field set to all-zeros, the GFA 823 assigns its own IP address as care-of address for this MN, and adds a 824 a GFA IP Address extension with this address to the Registration 825 Request. The GFA MUST NOT insert the GFA IP address directly in the 826 care-of address field in the Registration Request, since that would 827 cause the MN-HA authentication to fail. 829 The GFA IP Address extension has to be protected so that it cannot be 830 changed by a malicious node when the Registration Request is 831 forwarded to the HA. If the HA and the GFA have a mobility security 832 association, the GFA IP Address extension MUST be protected by the 833 FA-HA authentication extension. Otherwise, the Registration Request 834 MUST be sent to the HA in a secure way, for example via a secure AAA 835 protocol (see e.g. [RFC4004], [RFC3957]). 837 If the GFA does not support dynamic GFA assignment, it will deny the 838 request by sending a Registration Reply with the Code field set to 839 ZERO_COA_NOT_SUPP (see Section 9.5). 841 7.4. Home Agent Considerations for Dynamic GFA Assignment 843 If a HA receives a Registration Request with a GFA IP Address 844 extension, and the HA does not allow the use of this extension, the 845 HA MUST return a Registration Reply with the Code value set to 846 DYN_GFA_NOT_SUPP (see Section 9.5). 848 If a HA receives a Registration Request message with the care-of 849 address set to all-zeros, but no GFA IP Address extension, it MUST 850 deny the request by sending a Registration Reply message with the 851 Code field set to ZERO_CAREOF_ADDRESS (see Section 9.5). 853 If a HA that does not support dynamic GFA assignment receives a 854 Registration Request with a GFA IP Address extension, the request 855 will be denied by the HA, as described in [RFC3344]. 857 If a HA that supports dynamic GFA assignment receives a Registration 858 Request with the care-of address set to all-zeros and a GFA IP 859 Address extension, it MUST register the IP address of the GFA as the 860 care-of address of the MN in its mobility binding list. If the 861 Registration Request is accepted, the HA MUST include the GFA IP 862 Address extension in the Registration Reply, before the MN-HA 863 Authentication extension. 865 7.5. Regional Registration 867 If the MN receives an Agent Advertisement with the care-of address 868 field indicating the GFA set to all-ones, and if the MN determines 869 that it is within the same visited domain as when it did its last 870 home registration, it MAY send a Regional Registration Request to its 871 current GFA. Otherwise, it MUST send a Registration Request to its 872 HA as described in Section 7.1. 874 8. Router Discovery Extensions 876 This section specifies a new flag within the Mobile IP Agent 877 Advertisement, and an optional extension to the ICMP Router Discovery 878 Protocol [RFC1256]. 880 8.1. Regional Registration Flag 882 The only change to the Mobility Agent Advertisement Extension defined 883 in [RFC3344] is a flag indicating that the domain, to which the FA 884 generating the Agent Advertisement belongs, supports regional 885 registrations. The flag is inserted after the flags defined in 886 [RFC3344], [RFC3024] and [RFC3519]. 888 Regional Registration flag: 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Type | Length | Sequence Number | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Lifetime |R|B|H|F|M|G|r|T|U|I| reserved | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | zero or more Care-of Addresses | 898 | ... | 900 The flag is defined as follows: 902 Type 16 (Mobility Agent Advertisement) 904 I Regional Registration. This domain supports regional 905 registration as specified in this document. 907 8.2. Foreign Agent NAI Extension 909 The FA-NAI extension is defined as a subtype TBD of the NAI Carrying 910 Extension [RFC3846]. 912 The FA SHOULD include its NAI in the Agent Advertisement message. If 913 present, the Foreign Agent NAI (FA-NAI) extension MUST appear in the 914 Agent Advertisement message after any of the advertisement extensions 915 defined in [RFC3344]. 917 By comparing the domain part of the FA-NAI with the domain part of 918 the FA-NAI it received in the previous Agent Advertisement, the MN 919 can determine whether it has moved to a new domain since it last 920 registered. 922 9. Regional Extensions to Mobile IPv4 Registration Messages 924 In this section we specify new Mobile IP registration extensions for 925 the purpose of managing regional registrations. 927 9.1. GFA IP Address Extension 929 The GFA IP Address extension is defined for the purpose of supporting 930 dynamic GFA assignment. If the MN requests a dynamically assigned 931 GFA, the GFA adds a GFA IP Address extension to the Registration 932 Request before relaying it to the HA. The MN indicates that it wants 933 a GFA to be assigned by sending a Registration Request with the 934 care-of address field set to all-zeros. The GFA IP Address extension 935 MUST appear in the Registration Request before the FA-HA 936 Authentication extension, if present. 938 If a HA receives a Registration Request message with the care-of 939 address set to all-zeros, and a GFA IP Address extension, it MUST 940 register the IP address of the GFA as the care-of address of the MN. 941 When generating a Registration Reply message, the HA MUST include the 942 GFA IP Address extension from the Registration Request in the 943 Registration Reply message. The GFA IP Address extension MUST appear 944 in the Registration Reply message before the MN-HA Authentication 945 extension. 947 The GFA IP Address Extension is defined as follows: 949 0 1 2 3 950 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 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Type | Length | reserved | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | GFA IP Address | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Type 958 TBD (GFA IP Address) (non-skippable) 960 Length 961 6 963 GFA IP Address 964 The GFA IP Address field contains the Gateway Foreign Agent's 965 (GFA) publicly routable address. 967 9.2. Hierarchical Foreign Agent Extension 969 The Hierarchical Foreign Agent (HFA) extension may be present in a 970 Registration Request or Regional Registration Request. When a FA 971 adds this extension to a Registration Request, the receiving mobility 972 agent (GFA) sets up a pending registration record for the MN, using 973 the IP address in the HFA extension as the care-of address for the 974 MN. Furthermore, in this case, the extension MUST be appended at the 975 end of all previous extensions that had been included in the 976 registration message as received by the FA. The HFA extension MUST 977 be protected by an FA-FA Authentication extension. When the 978 receiving mobility agent (GFA) receives the registration message, it 979 MUST remove the HFA extension added by the sending FA. 981 If a MN with a co-located care-of address adds the HFA extension to a 982 Registration Request the receiving mobility agent (GFA) sets up a 983 pending registration record for the MN, using the IP address in the 984 HFA extension as the care-of address for the MN. The extension MUST 985 be protected by an authentication extension. If the MN has 986 established a mobility security association with the GFA, the HFA 987 extension MUST be placed before the MN-FA Authentication extension, 988 and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication 989 extension. Otherwise, if the MN has no established mobility security 990 association with the GFA, the HFA extension MUST be placed before the 991 MN-HA authentication extension. If the HFA extension is placed after 992 all other extensions, the receiving mobility agent (GFA) MUST remove 993 the HFA extension added by the MN. Otherwise, when the HA receives 994 the registration message, it ignores the HFA extension. 996 The Hierarchical Foreign Agent (HFA) Extension is defined as follows: 998 0 1 2 3 999 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 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Type | Length | reserved | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | FA IP Address | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 Type 1007 TBD (Hierarchical Foreign Agent) (skippable) 1009 Length 1010 6 1012 FA IP Address 1013 The IP Address of the FA relaying the Registration Request. 1015 9.3. Replay Protection Style 1017 When a MN uses Mobile IPv4 to register a care-of address with its HA, 1018 the style of replay protection used for the registration messages is 1019 assumed to be known by way of a mobility security association that is 1020 required to exist between the MN and the HA receiving the request. 1021 No such pre-existing security association between the MN and the GFA 1022 is likely to be available. By default, the MN SHOULD treat replay 1023 protection for Regional Registration messages exactly as specified in 1024 Mobile IPv4 [RFC3344] for timestamp-based replay protection. 1026 If the MN requires nonce-based replay protection, also as specified 1027 in Mobile IPv4, it MAY append a Replay Protection Style extension to 1028 a Registration Request. Since Registration Requests are forwarded to 1029 the HA by way of the GFA, the GFA will be able to establish the 1030 selected replay protection (see Section 5.3). 1032 The GFA also uses this extension by adding a Replay Protection Style 1033 extension to a Registration Reply to synchronize the replay 1034 protection for Regional Registrations (see Section 5.3). 1036 The format of the Replay Protection Style extension is: 1038 0 1 2 3 1039 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 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Type | Length | Replay Protection Style | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | | 1044 + Initial Identification + 1045 | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 Type 1049 TBD (Replay Protection Style) (skippable) 1051 Length 1052 2 1054 Replay Protection Style 1055 An integer specifying the style of replay protection desired by 1056 the MN. 1058 Initial Identification 1059 The timestamp or nonce to be used for initial synchronization for 1060 the replay mechanism. 1062 Admissible values for the Replay Protection Style are as follows: 1064 +-------+-------------------------+ 1065 | Value | Replay Protection Style | 1066 +-------+-------------------------+ 1067 | 0 | timestamp [RFC3344] | 1068 | 1 | nonce [RFC3344] | 1069 +-------+-------------------------+ 1071 The Replay Protection Style extension MUST be protected by an 1072 authentication extension. If the MN has an established mobility 1073 security association with the GFA, the Replay Protection Style 1074 extension MUST be placed before the MN-FA Authentication extension in 1075 the Registration Request, and SHOULD be placed after the MN-HA 1076 Authentication extension. Otherwise, the Replay Protection Style 1077 extension MUST be placed before the MN-HA Authentication extension in 1078 the Registration Request. 1080 If the GFA adds a Replay Protection Style extension to a Registration 1081 Reply, it SHOULD be placed before the MN-FA Authentication extension. 1082 The MN-FA Authentication extension should be based on security 1083 associations between the MN and GFA established during home 1084 registration. 1086 Replay protection MAY also be provided through a challenge-response 1087 mechanism, at the FA issuing the Agent Advertisement, as described in 1088 [RFC3012]. 1090 9.4. Regional Registration Lifetime Extension 1092 The Regional Registration Lifetime extension allows the GFA to set a 1093 lifetime for the regional registration with an MN during its home 1094 registration. When receiving a Registration Reply from the HA, the 1095 GFA MAY add this extension to the Registration Reply before relaying 1096 it to the FA. The GFA MUST set the Regional Registration Lifetime to 1097 be no greater than the remaining lifetime of the MN's home 1098 registration. 1100 The Regional Registration Lifetime Extension is defined as follows: 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Type | Length | reserved | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Regional Registration Lifetime | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Type 1111 TBD (Regional Registration Lifetime) (skippable) 1113 Length 1114 6 1116 Regional Registration Lifetime 1117 If the Code field indicates that the registration was accepted, 1118 the Regional Registration Lifetime field is set to the number of 1119 seconds remaining before the regional registration is considered 1120 expired. A value of zero indicates that the MN has been 1121 deregistered with the GFA. A value of 0xffff indicates infinity. 1122 If the Code field indicates that the home registration was denied, 1123 the contents of the Regional Registration Lifetime field are 1124 unspecified and MUST be ignored on reception. 1126 If the GFA adds a Regional Registration Lifetime extension to a 1127 Registration Reply, it MUST be placed before the MN-FA Authentication 1128 extension. The MN-FA Authentication extension should be based on 1129 security associations between the MN and GFA established during home 1130 registration. 1132 9.5. New Code Values for Registration Reply 1134 The values to use within the Code field of the Registration Reply are 1135 defined in [RFC3344]. In addition, the following values are defined: 1137 Registration denied by the GFA: 1139 +---------------------+-------+---------------------+ 1140 | Error Name | Value | Section of Document | 1141 +---------------------+-------+---------------------+ 1142 | REPLAY_PROT_UNAVAIL | TBD | Section 5.3 | 1143 | ZERO_COA_NOT_SUPP | TBD | Section 7.3 | 1144 +---------------------+-------+---------------------+ 1146 Registration denied by the HA (for dynamic GFA assignment): 1148 +---------------------+-----------+---------------------+ 1149 | Error Name | Value | Section of Document | 1150 +---------------------+-----------+---------------------+ 1151 | ZERO_CAREOF_ADDRESS | TBD | Section 7.4 | 1152 | DYN_GFA_NOT_SUPP | see above | Section 7.4 | 1153 +---------------------+-----------+---------------------+ 1155 10. Regional Registration Message Formats 1157 This section specifies two new registration message types: Regional 1158 Registration Request and Regional Registration Reply. These messages 1159 are used by the MN instead of the existing Mobile IPv4 Registration 1160 Request and Registration Reply, as described in Section 6. 1162 Regional registration messages are protected by required 1163 authentication extensions, in the same way as the existing Mobile 1164 IPv4 registration messages are protected. The following rules apply 1165 to authentication extensions: 1167 o The MN-GFA Authentication extension [RFC3344] MUST be included in 1168 all regional registration messages. 1170 o The MN-FA Authentication extension [RFC3344] MAY be included in 1171 regional registration messages. 1172 o The FA-HA Authentication extension [RFC3344] MUST NOT be included 1173 in any regional registration message. 1175 10.1. Regional Registration Request 1177 The Regional Registration Request is used by a MN to register with 1178 its current GFA. 1180 Regional Registration Request: 1182 0 1 2 3 1183 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 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Type |S|B|D|M|G|r|T|x| Lifetime | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Home Address | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | GFA IP Address | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Care-of Address | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | | 1194 + Identification + 1195 | | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Extensions ... 1198 +-+-+-+-+-+-+-+- 1200 The Regional Registration Request is defined as the Registration 1201 Request in [RFC3344], but with the following changes: 1203 Type 1204 TBD (Regional Registration Request) 1206 Lifetime 1207 The number of seconds remaining before the Regional Registration 1208 is considered expired. A value of zero indicates a request for 1209 deregistration with the GFA. A value of 0xffff indicates 1210 infinity. 1212 GFA IP Address 1213 The IP address of the Gateway Foreign Agent (GFA). (Replaces Home 1214 Agent field in Registration Request message in [RFC3344].) 1216 Care-of Address 1217 Care-of address of local FA; MAY be set to all-ones. 1219 Identification 1220 A 64-bit number, constructed by the MN, used for matching Regional 1221 Registration Requests with Regional Registration Replies, and for 1222 protecting against replay attacks of regional registration 1223 messages. 1225 Extensions 1226 For the Regional Registration Request, the Hierarchical Foreign 1227 Agent (HFA) Extension is an allowable extension (in addition to 1228 those which are allowable for the Registration Request). 1230 10.2. Regional Registration Reply 1232 The Regional Registration Reply delivers the indication of regional 1233 registration acceptance or denial to a MN. 1235 In the Regional Registration Reply, the UDP header is followed by the 1236 Mobile IP fields shown below: 1238 0 1 2 3 1239 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 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | Type | Code | Lifetime | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | Home Address | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | GFA IP Address | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | | 1248 + Identification + 1249 | | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Extensions ... 1252 +-+-+-+-+-+-+-+- 1254 This message is defined as the Registration Reply message in 1255 [RFC3344], but with the following changes: 1257 Type 1258 TBD (Regional Registration Reply) 1260 Code 1261 A value indicating the result of the Regional Registration 1262 Request. See [RFC3344] for a list of currently defined Code 1263 values. 1265 Lifetime 1266 If the Code field indicates that the regional registration was 1267 accepted, the Lifetime field is set to the number of seconds 1268 remaining before the regional registration is considered expired. 1269 A value of zero indicates that the MN has been deregistered with 1270 the GFA. A value of 0xffff indicates infinity. If the Code field 1271 indicates that the regional registration was denied, the contents 1272 of the Lifetime field are unspecified and MUST be ignored on 1273 reception. 1275 GFA IP Address 1276 The IP address of the Gateway Foreign Agent (GFA) generating the 1277 Regional Registration Reply. (Replaces Home Agent field specified 1278 in Mobile IPv4 [RFC3344]). 1280 Identification 1281 A 64-bit number used for matching Regional Registration Requests 1282 with Regional Registration Replies, and for protecting against 1283 replay attacks of regional registration messages. The value is 1284 based on the Identification field from the Regional Registration 1285 Request message from the MN, and on the style of replay protection 1286 used in the security context between the MN and its GFA (defined 1287 by the mobility security association between them). 1289 10.3. New Regional Registration Reply Code Values 1291 For a Regional Registration Reply, the following additional Code 1292 values are defined in addition to those specified in Mobile IPv4 1293 [RFC3344]. 1295 Registration denied by the FA: 1297 +----------------------+-------+---------------------+ 1298 | Error Name | Value | Section of Document | 1299 +----------------------+-------+---------------------+ 1300 | UNKNOWN_GFA | TBD | Section 6.2 | 1301 | GFA_UNREACHABLE | TBD | | 1302 | GFA_HOST_UNREACHABLE | TBD | | 1303 | GFA_PORT_UNREACHABLE | TBD | | 1304 +----------------------+-------+---------------------+ 1306 Registration denied by the GFA: 1308 +-------------+-------+---------------------+ 1309 | Error Name | Value | Section of Document | 1310 +-------------+-------+---------------------+ 1311 | NO_HOME_REG | TBD | Section 6.3 | 1312 +-------------+-------+---------------------+ 1314 The four first Code values are returned to the MN in response to ICMP 1315 errors that may be received by the FA. 1317 11. Authentication Extensions 1319 In this section, two new subtypes for the Generalized Authentication 1320 Extension [RFC3012] are specified. First, the FA-FA Authentication 1321 extension is used by FAs to secure the HFA extension to the 1322 Registration Request and Regional Registration Request messages. A 1323 new authentication extension is necessary because the HFA extension 1324 is typically added after the MN-HA Authentication extension or, e.g., 1325 the MN-AAA Authentication extension [RFC3012]. 1327 The MN-GFA Authentication extension is used whenever the MN has a co- 1328 located address. The MN-GFA Authentication extension is also used to 1329 provide authentication for a Regional Registration Request. 1331 The subtype values for these new subtypes are as follows: 1333 +-----------------------+-------+ 1334 | Subtype Name | Value | 1335 +-----------------------+-------+ 1336 | FA-FA authentication | TBD | 1337 | MN-GFA authentication | TBD | 1338 +-----------------------+-------+ 1340 The default algorithm for computation of the authenticator is the 1341 same as for the MN-AAA Authentication subtype defined in [RFC3012]. 1343 12. Security Considerations 1345 This document proposes a method for a MN to register locally in a 1346 visited domain. The authentication extensions to be used are those 1347 defined in [RFC3344] [RFC3012]. Key distribution, assumed to take 1348 place during home registration, is to be performed, for instance, 1349 according to [RFC4004] or [RFC3957]. Alternatively, the keys can be 1350 pre-configured. 1352 If the Hierarchical Foreign Agent (HFA) extension is appended to a 1353 Registration Request, this extension is to be followed by an FA-FA 1354 Authentication extension (see Section 11) to prevent any modification 1355 to the data. Security associations between FAs and GFAs within a 1356 domain are assumed to exist prior to regional registrations. 1358 If the GFA IP Address extension is added to a registration message, 1359 it is to be followed by a authentication extension. In case of the 1360 GFA IP Address extension being added to a Registration Request, it 1361 should be protected by a FA-HA Authentication extension. If no 1362 security association exists between the GFA and the HA, the 1363 Registration Request needs to be protected by other means not defined 1364 in this document. When a GFA IP Address extension is added to a 1365 Registration Reply, it is protected by the Mobile-Home Authentication 1366 extension as defined in [RFC3344]. 1368 Replay protection for regional registrations is defined similarly to 1369 [RFC3344], with the addition of a Replay Protection Style extension. 1370 If this extension is added to a Registration Reply by a GFA, it needs 1371 to be protected by a MN-FA Authentication extension. 1373 13. IANA Considerations 1375 This document defines: 1377 o A subtype for the NAI Carrying Extension [RFC3846]is specified in 1378 Section 8.2, which needs to have a value assigned from the space 1379 of NAI Carrying Extension subtypes. 1380 o Four new extensions to Mobile IP Registration messages: GFA IP 1381 Address, Hierarchical Foreign Agent, Replay Protection Style, and 1382 Regional Registration Lifetime (see Section 9.1, Section 9.2, 1383 Section 9.3 and Section 9.4). The Type values for the GFA IP 1384 Address extension must be within the range 0 through 127, while 1385 the other three must be within the range 128 through 255. 1386 o New Code values for Registration Reply messages (see Section 9.5). 1387 o Two new subtypes for the Generalized Authentication Extension 1388 [RFC3012]; see Section 11. 1390 o Two new message types for Mobile IP: Regional Registration Request 1391 and Regional Registration Reply (see Section 10.1 and 1392 Section 10.2). 1393 o Code values for Regional Registration Reply messages (see 1394 Section 10.3). 1396 14. Acknowledgements 1398 This document is a logical successor to documents written with Pat 1399 Calhoun and Gabriel Montenegro; thanks to them and their many efforts 1400 to help explore this problem space. Many thanks also to Jari Malinen 1401 for his commentary on a rough version of this document. 1403 15. References 1405 15.1. Normative References 1407 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1408 September 1991. 1410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1411 Requirement Levels", BCP 14, RFC 2119, March 1997. 1413 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1414 Network Access Identifier", RFC 4282, December 2005. 1416 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 1417 Identifier Extension for IPv4", RFC 2794, March 2000. 1419 [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ 1420 Response Extensions", RFC 3012, November 2000. 1422 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 1423 revised", RFC 3024, January 2001. 1425 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1426 August 2002. 1428 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1429 Network Address Translation (NAT) Devices", RFC 3519, 1430 May 2003. 1432 [RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for 1433 Carrying Network Access Identifiers", RFC 3846, June 2004. 1435 15.2. Informative References 1437 [RFC3957] Perkins, C. and P. Calhoun, "Authentication, 1438 Authorization, and Accounting (AAA) Registration Keys for 1439 Mobile IPv4", RFC 3957, March 2005. 1441 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 1442 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1443 August 2005. 1445 Appendix A. Authentication, Authorization and Accounting (AAA) 1446 Interactions 1448 When the mobile node has to obtain authorization by way of 1449 Authentication, Authorization and Accounting (AAA) infrastructure 1450 services, the control flow implicit in the main body of this 1451 specification is likely to be modified. Typically, the mobile node 1452 will supply credentials for authorization by AAA as part of its 1453 registration messages. The GFA will parse the credentials supplied 1454 by the mobile and forward the appropriate authorization request to a 1455 local AAA server (see [RFC3012], [RFC4004]). 1457 Concretely, this means that: 1459 o The GFA MAY include the Mobile IP Registration Request data inside 1460 an authorization request, directed to a local AAA server. 1461 o The GFA MAY receive the Mobile IP Registration Reply data from a 1462 message granting authorization, received from the AAA 1463 infrastructure. 1465 Appendix B. Anchoring at a GFA 1467 As described earlier in this draft, once a mobile node has registered 1468 the address of a GFA as its care-of address with its home agent, it 1469 MAY perform regional registrations when changing foreign agent under 1470 the same GFA. When detecting that is has changed foreign agent, and 1471 if the new foreign agent advertises the 'I' flag, the mobile node MAY 1472 address a Regional Registration Request message to its registered 1473 GFA, even if the address of that particular GFA is not advertised by 1474 the new foreign agent. The foreign agent MAY then relay the request 1475 to the GFA in question, or deny the request with error code 'unknown 1476 GFA'. 1478 Authors' Addresses 1480 Eva Fogelstroem 1481 Ericsson 1482 Torshamnsgatan 23 1483 SE-164 80 Stockholm 1484 Sweden 1486 Email: eva.fogelstrom@ericsson.com 1488 Annika Jonsson 1489 Ericsson 1490 Goetalandsvaegen 230 1491 SE-125 82 Aelvsjoe 1492 Sweden 1494 Email: annika.jonsson@ericsson.com 1496 Charles E. Perkins 1497 Nokia Research Center 1498 313 Fairchild Drive 1499 Mountain View, California 94043 1500 USA 1502 Email: charles.perkins@nokia.com 1504 Full Copyright Statement 1506 Copyright (C) The Internet Society (2006). 1508 This document is subject to the rights, licenses and restrictions 1509 contained in BCP 78, and except as set forth therein, the authors 1510 retain all their rights. 1512 This document and the information contained herein are provided on an 1513 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1514 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1515 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1516 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1517 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1518 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1520 Intellectual Property 1522 The IETF takes no position regarding the validity or scope of any 1523 Intellectual Property Rights or other rights that might be claimed to 1524 pertain to the implementation or use of the technology described in 1525 this document or the extent to which any license under such rights 1526 might or might not be available; nor does it represent that it has 1527 made any independent effort to identify any such rights. Information 1528 on the procedures with respect to rights in RFC documents can be 1529 found in BCP 78 and BCP 79. 1531 Copies of IPR disclosures made to the IETF Secretariat and any 1532 assurances of licenses to be made available, or the result of an 1533 attempt made to obtain a general license or permission for the use of 1534 such proprietary rights by implementers or users of this 1535 specification can be obtained from the IETF on-line IPR repository at 1536 http://www.ietf.org/ipr. 1538 The IETF invites any interested party to bring to its attention any 1539 copyrights, patents or patent applications, or other proprietary 1540 rights that may cover technology that may be required to implement 1541 this standard. Please address the information to the IETF at 1542 ietf-ipr@ietf.org. 1544 Acknowledgment 1546 Funding for the RFC Editor function is provided by the IETF 1547 Administrative Support Activity (IASA).