idnits 2.17.1 draft-ietf-mobileip-reg-tunnel-09.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.5 on line 1897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1881. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 30) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2486 (ref. '2') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3012 (ref. '4') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 3344 (ref. '7') (Obsoleted by RFC 5944) -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-05) exists of draft-ietf-mobileip-gnaie-00 -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Eva Gustafsson 2 INTERNET DRAFT Ericsson 3 25 June 2004 Annika Jonsson 4 Ericsson 5 Charles E. Perkins 6 Nokia Research Center 8 Mobile IPv4 Regional Registration 9 draft-ietf-mobileip-reg-tunnel-09.txt 11 Status of This Memo 13 This document is a submission by the mip4 Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the mip4@ietf.org mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 31 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 Abstract 37 Using Mobile IP, a mobile node registers with its home agent each 38 time it changes care-of address. If the distance between the 39 visited network and the home network of the mobile node is large, the 40 signaling delay for these registrations may be long. This document 41 describes a new kind of `regional' registrations, i.e. registrations 42 local to the visited domain. The regional signaling is performed via 43 a new network entity called a Gateway Foreign Agent and introduces 44 a layer of hierarchy in the visited domain. Regional registrations 45 reduce the number of signaling messages to the home network, and 46 reduce the signaling delay when a mobile node moves from one foreign 47 agent to another within the same visited domain. This document is an 48 optional extension to the Mobile IPv4 protocol. 50 Contents 52 Status of This Memo i 54 Abstract i 56 1. Introduction 2 58 2. Terminology 3 60 3. Description of the Protocol 4 61 3.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4 62 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Advertising Foreign Agent and GFA . . . . . . . . . . . . 7 64 3.4. Backwards compatibility with RFC3344 . . . . . . . . . . 8 66 4. Home Registration 8 67 4.1. Mobile Node Considerations . . . . . . . . . . . . . . . 8 68 4.2. Foreign Agent Considerations . . . . . . . . . . . . . . 10 69 4.3. GFA Considerations . . . . . . . . . . . . . . . . . . . 10 70 4.4. Home Agent Considerations . . . . . . . . . . . . . . . . 12 72 5. Regional Registration 13 73 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . 14 74 5.2. Foreign Agent Considerations . . . . . . . . . . . . . . 15 75 5.3. GFA Considerations . . . . . . . . . . . . . . . . . . . 15 77 6. Generalized NAI Extension 15 79 7. Router Discovery Extensions 17 80 7.1. Regional Registration Flag . . . . . . . . . . . . . . . 17 81 7.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . . 17 83 8. Regional Extensions to Mobile IPv4 Registration Messages 18 84 8.1. GFA IP Address Extension . . . . . . . . . . . . . . . . 18 85 8.2. Hierarchical Foreign Agent Extension . . . . . . . . . . 19 86 8.3. Replay Protection Style . . . . . . . . . . . . . . . . . 19 87 8.4. New Code Values for Registration Reply . . . . . . . . . 21 89 9. Regional Registration Message Formats 22 90 9.1. Regional Registration Request . . . . . . . . . . . . . . 22 91 9.2. Regional Registration Reply . . . . . . . . . . . . . . . 24 92 9.3. New Regional Registration Reply Code Values . . . . . . . 24 94 10. Authentication Extensions 25 95 11. IANA considerations 26 97 12. Security Considerations 26 99 13. Acknowledgements 27 101 A. Changes from Previous Versions 30 102 A.1. Updates from version 06 . . . . . . . . . . . . . . . . . 30 103 A.2. Updates from version 05 . . . . . . . . . . . . . . . . . 31 104 A.3. List of updates made for previous revisions . . . . . . . 31 105 A.4. Updates from version 02 . . . . . . . . . . . . . . . . . 32 107 B. Hierarchical Foreign Agents 33 108 B.1. Registration with Home Agent . . . . . . . . . . . . . . 33 109 B.2. Handling Binding Updates . . . . . . . . . . . . . . . . 36 110 B.3. Regional Registration . . . . . . . . . . . . . . . . . . 37 111 B.4. Regional Registrations and Smooth Handover . . . . . . . 39 112 B.5. Co-located care of address . . . . . . . . . . . . . . . 39 113 B.6. Data Traffic . . . . . . . . . . . . . . . . . . . . . . 39 114 B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension 40 116 C. Authentication, Authorization and Accounting AAA Interactions 40 118 D. Anchoring at a GFA/RFA/FA 41 120 Intellectual Property 42 122 Full Copyright Statement 42 124 Addresses 43 125 1. Introduction 127 This document is an optional extension to the Mobile IPv4 protocol, 128 and proposes a means for mobile nodes to register locally within a 129 visited domain. By registering locally, the number of signaling 130 messages to the home network are kept to a minimum, and the signaling 131 delay is reduced. 133 In Mobile IP, as specified in RFC 3344 [7], a mobile node registers 134 with its home agent each time it changes care-of address. If the 135 distance between the visited network and the home network of the 136 mobile node is large, the signaling delay for these registrations 137 may be long. We propose a solution for performing registrations 138 locally in the visited domain: regional registrations. The 139 regional registration design introduces new Mobile IPv4 messages 140 - Regional Registrations, new Mobile IPv4 extensions to convey 141 information between the mobile node, foreign agent and home agent, 142 and a new network entity: the Gateway Foreign Agent (GFA). Regional 143 registrations reduce the number of signaling messages to the home 144 network, and reduce the signaling delay when a mobile node moves from 145 one foreign agent to another within the same visited domain. This 146 will both decrease the load on the home network, and speed up the 147 process of handover within the visited domain. 149 When a mobile node first arrives at a visited domain, it performs a 150 _home_registration -- that is, a registration with its home agent. 151 At this registration, we assume that the home network generates 152 a registration key (e.g. using [11]) for the mobile node. This 153 registration key is distributed to the mobile node and to the visited 154 domain, and can be used for authentication of regional registrations. 156 During a home registration, the home agent registers the care-of 157 address of the mobile node. When the visited domain supports 158 regional tunnel management, the care-of address that is registered 159 at the home agent is the publicly routable address of a Gateway 160 Foreign Agent (GFA). This care-of address will not change when the 161 mobile node changes foreign agent under the same GFA. When changing 162 GFA, a mobile node MUST perform a home registration; when changing 163 foreign agent under the same GFA, the mobile node MAY instead perform 164 a regional registration within the visited domain. The proposed 165 regional registration protocol supports one level of foreign agent 166 hierarchy beneath the GFA, but the protocol may be utilized to 167 support several levels of hierarchy, as discussed in Appendix B. 169 Foreign agents that support regional registrations are also required 170 to support registrations according to Mobile IPv4 [7]. If there is 171 a foreign agent address announced in the Agent Advertisement, the 172 mobile node may register that foreign agent care-of address with its 173 home agent [7]. Similarly, if the mobile node chooses not to employ 174 regional registrations, it may register a co-located care-of address 175 directly with its home agent, according to [7]. 177 2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [1]. 183 This document uses the following terms: 185 Critical type 186 A type value for an extension in the range 0-127, which 187 indicates that the extension MUST either be known to the 188 recipient, or that the message containing the extension 189 MUST be rejected. In other words, an extension with a 190 critical type value is non-skippable. 192 Domain A collection of networks sharing a common network 193 administration. 195 Foreign Agent (FA) 196 As defined in [7]. 198 Gateway Foreign Agent (GFA) 199 A Foreign Agent which has a publicly routable IP address. 200 A GFA may, for instance, be placed in or near a firewall. 202 Home Agent (HA) 203 As defined in [7]. 205 Home domain 206 The domain where the home network and home agent are 207 located. 209 Home network 210 As defined in [7]. 212 Home Registration 213 A registration, processed by the home agent and the GFA, 214 using the specification in [7] possibly with additional 215 extensions defined in this document. 217 Local Care-of Address 218 A Care-of Address which is either assigned to a mobile 219 node, or to a foreign agent offering local connectivity 220 to a mobile node. A registration message from the mobile 221 node is subsequently sent to a GFA (or another RFA, see 222 Appendix B) via the local care-of address. 224 Mobile Node (MN) 225 As defined in [7]. 227 Mobility Agent (MA) 228 As defined in [7]. 230 Network Access Identifier(NAI) 231 Some features of this protocol specification rely on use 232 of the Network Access Identifier (NAI) [3]. 234 Regional Foreign Agent (RFA) 235 A Foreign Agent which may be the target of a request for 236 regional registration. 238 Regional Registration 239 A mobile node performs registration locally at the 240 visited domain, by sending a Regional Registration 241 Request to a GFA, and receiving a Regional Registration 242 Reply in return. 244 Registration Key 245 A key used by mobile nodes and mobility agents to secure 246 certain signals and control messages specified by Mobile 247 IP. 249 Visited domain 250 The domain where the visited network, the current foreign 251 agent and the GFA are located. 253 Visited network 254 As defined in [7]. 256 3. Description of the Protocol 258 This section provides an overview of the regional registration 259 protocol. 261 3.1. General Assumptions 263 Our general model of operation is illustrated in figure 1, showing a 264 visited domain with foreign agent and GFA, and a home network with a 265 home agent. 267 +---------------------------+ +----------------+ 268 | Visited Domain | | Home | 269 | | +---------+ | Network | 270 | | | | | | 271 | +------+ +-------+ | | Public | | +------+ | 272 | | FA |------| GFA |-------------------------| HA | | 273 | +--+---+ +-------+ | | Network | | +------+ | 274 | | | | | | | 275 +-----|---------------------+ +---------+ +----------------+ 276 | 277 +--+---+ 278 | MN | 279 +------+ 281 Figure 1: Visited domain with a GFA, and a home network with HA. 283 For mobile nodes that cannot process a NAI, or with mobility agents 284 that are not configured to advertise their NAI, regional registration 285 is still useful, but the lack of certain features may result in less 286 than optimal results. 288 3.1.1. Visited Domain 290 We assume two hierarchy levels of foreign agents in the visited 291 domain. At the top level of the hierarchy, there is at least one 292 GFA, which is a foreign agent with additional features. A GFA 293 must have a publicly routable address. Beneath a GFA, there are 294 one or more regional foreign agents (RFAs). We assume that there 295 exist established security associations between a GFA and the 296 RFAs beneath it. Multiple hierarchy levels of foreign agents are 297 discussed in Appendix B. When designing a domain supporting regional 298 registrations, the RFAs and GFA must be compatible. That is, they 299 should support the same encapsulation types, compression mechanisms 300 etc. 302 When a mobile node changes care-of address under the same GFA, it MAY 303 perform a regional registration. If the mobile node changes GFA, 304 within a visited domain or between visited domains, it MUST perform a 305 home registration. 307 3.1.2. Authentication 309 With the regional registration protocol, a GFA address is registered 310 at the home agent as the care-of address of the mobile node. If a 311 Mobile-Foreign Authentication extension is present in a Registration 312 Request message directed to the home agent, the GFA will perform 313 the authentication. Similarly, if a Foreign-Home Authentication 314 extension is present in a Registration Request message, the 315 authentication is performed between the GFA and the home agent. 317 Regional Registration messages also have to be protected with 318 authentication extensions in the same way as registrations with the 319 home agent. This means that the mobile node and the GFA MUST have 320 received the keys needed to construct the authentication extensions 321 before any Regional Registration is performed. When the regional 322 registration protocol is employed, the GFA is the agent within 323 the visited domain which receives the registration keys. This is 324 because the GFA address is the registered care-of address of the 325 mobile node at its home network. The distributed registration 326 keys are subsequently used to enable proper authentication for 327 regional registrations (see sections 9.1 and 9.2). How the keys 328 are distributed is outside the scope of this draft. One example is 329 that the keys are distributed as part of the registration at the 330 home network, for example according to [8, 11]. Another example is 331 pre-configured keys. 333 3.2. Protocol Overview 335 When a mobile node first arrives at a visited domain, it performs a 336 registration with its home network. At this registration, the home 337 agent registers the care-of address of the mobile node. In case the 338 visited domain supports regional registrations, the care-of address 339 that is registered at the home agent is the address of a GFA. The GFA 340 keeps a visitor list of all the mobile nodes currently registered 341 with it. 343 Since the care-of address registered at the home agent is the GFA 344 address, it will not change when the mobile node changes foreign 345 agent under the same GFA. Thus, the home agent does not need to be 346 informed of any further mobile node movements within the visited 347 domain. 349 Figure 2 illustrates the signaling message flow for registration 350 with the home network. After the registration at the home agent, 351 the home agent records the GFA address as the care-of address of the 352 mobile node. If the GFA address was dynamically assigned to the 353 mobile node, the Registration Reply has an extension indicating the 354 IP address of the GFA to the mobile node. 356 Figure 3 illustrates the signaling message flow for regional 357 registration. Even though the mobile node's local care-of address 358 changes, the home agent continues to record the GFA address as the 359 MN FA1 GFA HA 360 | | | | 361 | Registration Request | | | 362 |---------------------->| Reg. Request w/ext. | | 363 | |---------------------->| Reg. Request | 364 | | |--------------->| 365 | | | Reg. Reply | 366 | | Reg. Reply w/ext. |<---------------| 367 | Registration Reply |<----------------------| | 368 |<----------------------| | | 369 | | | | 371 Figure 2: Registration at the GFA and the home agent. 373 MN FA2 GFA HA 374 | | | | 375 | Regional Reg. Req. | | | 376 |---------------------->| Regional Reg. Req. w/ext. | | 377 | |----------------------------->| | 378 | | Regional Reg. Reply w/ext. | | 379 | Regional Reg. Reply |<-----------------------------| | 380 |<----------------------| | | 381 | | | | 383 Figure 3: Regional registration at the GFA. 385 care-of address of the mobile node. We introduce two new message 386 types for regional registrations: Regional Registration Request and 387 Regional Registration Reply. 389 3.3. Advertising Foreign Agent and GFA 391 A foreign agent typically announces its presence via an Agent 392 Advertisement message [7]. If the domain to which a foreign agent 393 belongs supports regional registrations, the following changes are 394 applied to the Agent Advertisement message. 396 The `I' flag (see Section 7) MUST be set to indicate that the domain 397 supports regional tunnel management. If the `I' flag is set, there 398 MUST be at least one care-of address in the Agent Advertisement 399 message, but that address MAY be set to the ``all ones'' address. If 400 the `I' flag is set, and there is only one care-of address (which is 401 not all ones), it is the address of the FA. If the `I' flag is set, 402 and there are multiple care-of addresses, the first care-of address 403 is the local FA, and the last care-of address is the GFA. The FA-NAI 404 (see section 7.2) SHOULD also be present to enable the mobile node 405 to decide whether or not it is in its home domain. The decision is 406 based on whether the realm part of the advertised FA-NAI matches the 407 mobile node's realm. 409 3.4. Backwards compatibility with RFC3344 411 A domain that supports Regional Registrations SHOULD also be 412 backwards compatible. If the Foreign Agent does not advertise an 413 ``all ones'' care-of address, it MUST support registrations according 414 to Mobile IPv4 as defined in RFC3344 [7]. This allows mobile nodes 415 that doesn't support Regional Registrations to register via this 416 Foreign Agent using standard Mobile IPv4. If the Foreign agent 417 advertises both its own care-of address and a GFA care-of address, 418 a mobile node that supports Regional Registrations but has a Home 419 Agent that doesn't, will still be able to make use of Regional 420 Registrations through that GFA care-of address. A Foreign Agent that 421 advertises an ``all ones'' care-of address will not be backwards 422 compatible with RFC3344. In that case, and in other cases when the 423 mobile node requests that a GFA address is dynamically assigned to 424 it by setting the care-of address in a Registration Request to zero, 425 the mobile node and its Home Agent MUST support the GFA IP address 426 extension. 428 4. Home Registration 430 This section gives a detailed description of home registration, 431 i.e., registration with the home agent (on the home network). Home 432 registration is performed when a mobile node first arrives at a 433 visited domain, when it requests a new home agent, or when it changes 434 GFA. Home registration is also performed to renew bindings which 435 would otherwise expire. 437 4.1. Mobile Node Considerations 439 Upon receipt of an Agent Advertisement message with the `I' flag set 440 and a FA-NAI extension, the mobile node compares the domain part 441 of the foreign agent NAI with the domain part of its own NAI, to 442 determine whether it is in its home domain or in a visited domain. 443 If the NAIs do not match, the mobile node MUST assume it is in a 444 foreign domain. Otherwise, if the mobile node determines that it is 445 in its home domain, it acts as defined in [7]. 447 If the mobile node determines that it is in a visited domain, it 448 SHOULD either use the advertised GFA address in the care-of address 449 field in the Registration Request message, or set this field to 450 zero to request to be assigned a GFA. If the mobile node sets the 451 care-of address to zero, the mobile node and its home agent MUST 452 support the GFA IP address extension (see section 8.1). In that 453 case, the mobile node MUST check to make sure that it receives a GFA 454 IP address extension in the Registration Reply. If the Foreign Agent 455 only advertises an ``all ones'' care-of address, it only supports 456 dynamically assigned GFA care-of address, and the mobile node MUST 457 set the care-of address in the Registration Request to zero. 459 A mobile node with a co-located care-of address might also want 460 to use Regional Registrations. It then finds out the address of 461 a GFA, either from Agent Advertisements sent by a Foreign Agent, 462 or by some means not described in this draft. The mobile node MAY 463 then generate a Registration Request message, with the GFA address 464 in the care-of address field, and send it directly to the GFA (not 465 via a foreign agent). In this case, the mobile node MUST add a 466 Hierarchical Foreign Agent extension 8.2, including its co-located 467 care-of address, to the Registration Request before sending it. 468 The Hierarchical Foreign Agent extension MUST be protected by an 469 authentication extension. If the mobile node has established a 470 mobility security association with the GFA, the Hierarchical Foreign 471 Agent extension SHOULD be placed after the MN-HA authentication 472 extension and before the MN-FA authentication extension. Otherwise 473 the Hierarchical Foreign Agent extension MUST be placed before the 474 MN-HA authentication extension. 476 If the mobile node receives an Agent Advertisement with the `R' bit 477 set it, even if it has a co-located care-of address, still formulates 478 the same Registration Request message with extensions, but it sends 479 the message to the advertising foreign agent instead of to the GFA. 481 If the home registration is about to expire, the mobile node performs 482 a new home registration using the same GFA care-of address to refresh 483 the binding [7]. If the mobile node has just moved to a new Foreign 484 Agent and not yet sent a Regional Registration Request when the home 485 registration is due to expire, the mobile node sends only a home 486 Registration Request, as this will update both the GFA and the HA. 487 This Registration Request MUST be constructed as if it was the first 488 registration in this domain. For example, if the new Foreign Agent 489 only advertises an `all ones' care-of address, the mobile node MUST 490 set the care-of address in the Registration Request to zero, to avoid 491 problems if this new Foregin Agent doesn't support the same GFA as 492 the mobile node had before. 494 If the Registration Replay includes a Replay Protection Style 495 extension, the value in the Initial Identification field is the value 496 to be used for replay protection in the next Regional Registration 497 Request (see section 5.1). 499 4.2. Foreign Agent Considerations 501 When the foreign agent receives a Registration Request message 502 from a mobile node, it extracts the care-of address field in the 503 Registration Request message, to find the GFA to which the message 504 shall be relayed. All Foreign Agents that advertise the `I' flag 505 MUST also be able to handle Registration Requests with a zero care-of 506 address. If the care-of address field is set to zero, the foreign 507 agent assigns a GFA to the mobile node. A Foreign Agent can either 508 have a default GFA that it assigns to all mobile nodes or it can 509 assign a GFA by some means not described in this specification. 511 If the Foreign Agent receives a Registration request where the 512 care-of address is set to ``all ones''(which could happen if a mobile 513 node that doesn't support Regional Registrations copied an ``all 514 ones'' care-of address from an Agent Advertisement), it must reply 515 with the Code field set to ``poorly formed Request'' [7]. 517 If the Registration Request has the `T' bit set, the mobile node is 518 requesting Reverse Tunneling [6]. In this case, the foreign agent 519 has to tunnel packets from the mobile node to the GFA for further 520 handling. 522 If the care-of address in the Registration Request is the address of 523 the foreign agent, the foreign agent relays the message directly to 524 the home agent, as described in [7]. For each pending or current 525 home registration, the foreign agent maintains a visitor list entry 526 as described in [7]. If reverse tunneling is being used, the visitor 527 list MUST, in addition to the fields required in [7], contain the 528 address of the GFA. 530 Otherwise, if the care-of address in the Registration Request 531 is the address of a GFA (or zero), the foreign agent adds a 532 Hierarchical Foreign Agent extension, including its own address, 533 to the Registration Request message, and relays it to the GFA. The 534 Hierarchical Foreign Agent extension MUST be appended at the end 535 of all previous extensions that were included in the Registration 536 Request message when the foreign agent received it, and it SHOULD be 537 protected by an FA-FA Authentication extension (see section 10). 539 4.3. GFA Considerations 541 For each pending or current home registration, the GFA maintains a 542 visitor list entry as described in [7]. This visitor list entry is 543 also updated for the regional registrations performed by the mobile 544 node. In addition to the fields required in [7], the list entry MUST 545 contain: 547 - the current care-of address of the mobile node (i.e., the foreign 548 agent or co-located address) in the Hierarchical Foreign Agent 549 extension 550 - the remaining Lifetime of the regional registration 551 - the style of replay protection in use for the regional 552 registration 553 - the Identification value for the regional registration. 555 The default replay protection style for Regional Registrations is 556 timestamp-based replay protection, as defined in Mobile IPv4 [7]. 557 If the timestamp sent by the mobile node in the Registration 558 Request is not close enough to the GFA's time of day clock, the GFA 559 adds a Replay Protection Style extension (see section 8.3) to the 560 Registration Reply, with the GFAs time of day in the Identification 561 field to synchronize the mobile node with the GFA for the Regional 562 Registrations. If nonce based reply protection is used, the GFA adds 563 a Replay Protection Style extension to the Registration Reply, where 564 the high-order 32 bits in the Identification fields is the nonce 565 that should be used by the mobile node in the following Regional 566 Registration. 568 If the Registration Request message contains a Replay Protection 569 extension (see section 8.3) requesting a style of replay protection 570 not supported by the GFA, the GFA MUST reject the Registration 571 Request and send a Registration Reply with the value in the Code 572 field set to REPLAY_PROT_UNAVAIL (see section 8.4). 574 If the care-of address field of the Registration Request is set 575 to zero, the GFA assigns a GFA care-of address for this Mobile 576 Node, and adds a GFA IP Address extension with this address of 577 to the Registration Request message. The GFA MUST NOT insert 578 the GFA address directly in the care-of address field in the 579 Registration Request message, since that would cause the Mobile-Home 580 authentication to fail. 582 The GFA IP Address extension has to be protected so that it can't 583 be changed by a malicious node when the Registration Request is 584 forwarded to the HA. If the HA and the GFA have a mobility security 585 association, the GFA IP Address extension MUST be protected by the 586 HA-FA authentication extension. Otherwise the Registration Request 587 MUST be sent to the HA in a secure way, for example via a secure AAA 588 protocol (see e.g. [8, 11]). 590 If the Hierarchical Foreign Agent extension comes after the 591 MN-FA authentication extension, the GFA MUST remove it from the 592 Registration Request message. The GFA then sends the request to the 593 home agent. Upon receipt of the Registration Reply message, the GFA 594 consults its pending registration record to find the care-of address 595 within its domain that is currently used by the mobile node, and 596 sends the Registration Reply to that care-of address. 598 If the Replay extension (see section 8.3) is present in a home 599 registration, and follows the MN-HA authentication extension, the GFA 600 SHOULD remove the Replay extension after performing any necessary 601 processing, before sending the home registration to the home agent. 603 If the GFA receives a Registration Request from a mobile node that it 604 already has a mobility binding for, this is an update of a binding 605 that is about to expire. If the address in the Hierarchical Foreign 606 Agent extension is the same as the current care-of address in the 607 visitor list for the mobile node, the entries in the visitor list 608 concerning regional registrations are not changed, except to update 609 the lifetime. If the address in the Hierarchical Foreign Agent 610 extension is a new address, the values for the regional registration 611 are updated. 613 If the Registration request has the 'T' bit set, the GFA has to 614 decapsulate the packets from the foreign agent and re-encapsulate 615 them for further delivery back to the home agent. These actions are 616 required because the home agent has to receive such packets from the 617 expected care-of address (i.e., that of the GFA) instead of the local 618 care-of address (that of the FA). 620 4.4. Home Agent Considerations 622 A Registration Request that does not contain a GFA IP Address 623 extension is processed by the home agent as described in [7]. If 624 the home agent receives a Registration Request with this extension, 625 and the home agent does not support the extension, the home 626 agent must return a Registration Reply with the Code value set to 627 ZERO_COA_NOT_SUPP 8.4 . If a home agent receives a Registration 628 Request message with the care-of address set to zero, and a GFA 629 IP Address extension, it MUST register the IP address of the GFA 630 as the care-of address of the mobile node in its mobility binding 631 list. If the Registration Request is accepted, the home agent MUST 632 include the GFA IP Address extension in the Registration Reply, 633 before the Mobile-Home Authentication extension. If a home agent 634 receives a Registration Request message with the care-of address set 635 to zero, but no GFA IP Address extension, it MUST deny the request 636 by sending a Registration Reply message with the Code field set to 637 ZERO_CAREOF_ADDRESS (see section 8.4). Otherwise, the home agent 638 then generates a Registration Reply message, including the GFA IP 639 Address extension, and sends it back to the GFA. 641 5. Regional Registration 643 This section describes in detail regional registration. Once the 644 home agent has registered the GFA address as the care-of address of 645 the mobile node, the mobile node may perform regional registrations. 646 When performing regional registrations, the mobile node may either 647 register a foreign agent care-of address or a co-located address with 648 the GFA (or, another RFA -- see Appendix B). In the following, we 649 assume that a home registration has already occurred, as described in 650 section 4, and that the GFA has a mobility security association with 651 the mobile node. 653 Suppose the mobile node moves from one foreign agent to another 654 foreign agent within the same visited domain. It will then receive 655 an Agent Advertisement from the new foreign agent. Suppose further 656 that the Agent Advertisement indicates that the visited domain 657 supports regional registrations, and that either the advertised GFA 658 address is the same as the one the mobile node has registered as its 659 care-of address during its last home registration, or the realm part 660 of the newly advertised FA-NAI matches the FA-NAI advertised by the 661 mobile node's previous foreign agent. Then, the mobile node can 662 perform a regional registration with this foreign agent and GFA. The 663 mobile node issues a Regional Registration Request message to the GFA 664 via the new foreign agent. The request is authenticated using the 665 registration key that was distributed to the GFA and to the mobile 666 node from the home network and the message is authenticated by the 667 MN-GFA Authentication Extension. The care-of address should be set 668 to the address of the local foreign agent, or else zero if the local 669 foreign agent is not advertising its own care-of address. 671 If the Regional Registration Request does not contain its care-of 672 address, the foreign agent adds a Hierarchical Foreign Agent 673 extension to the message and relays it to the GFA. Based on the 674 information in the Hierarchical Foreign Agent extension, the GFA 675 updates the mobile node's current point of attachment in its visitor 676 list. The GFA then issues a Regional Registration Reply to the 677 mobile node via the foreign agent. 679 If the advertised GFA is not the same as the one the mobile node has 680 registered as its care-of address, and if the mobile node is still 681 within the same domain as it was when it registered that care-of 682 address, the mobile node MAY try to perform a regional registration 683 with its registered GFA. If the foreign agent cannot support 684 regional registration to a GFA, other than advertised, the foreign 685 agent denies the regional registration with code UNKNOWN_GFA (see 686 section 9.3). In this case the MN has to do a new home registration 687 via the new GFA. 689 It is essential for the mobile node to distinguish regional 690 registrations from home registrations, since in the former case the 691 nonces are not synchronized with its home agent. Furthermore, a 692 home registration MUST be directed to the home network before the 693 lifetime of the GFA's regional care-of address expires. Since the 694 mobile node can use a zero Care-of Address either to request a GFA 695 (in a home registration) or to signify the use of an unspecified 696 (perhaps privately addressed) RFA (in a regional registration), 697 it is necessary to distinguish regional registrations from home 698 registration. Thus, we introduce new message types for the Regional 699 Registration messages. 701 5.1. Mobile Node Considerations 703 For each pending or current home registration, the mobile node 704 maintains the information described in [7]. The information is also 705 updated for the regional registrations performed by the mobile node. 706 In addition to the information described in [7], the mobile node MUST 707 maintain the following information, if present: 709 - the GFA address 710 - the style of replay protection in use for the regional 711 registration 712 - the Identification value for the regional registration. 714 The replay protection for registrations and regional registrations 715 is performed as described in [7]. Since the mobile node performs 716 regional registrations at the GFA in parallel with registrations at 717 its home network, the mobile node MUST be able to keep one replay 718 protection mechanism and sequence for the GFA, and a separate 719 mechanism and sequence for the home agent. 721 For regional registrations, replay protection may also be provided at 722 the foreign agent by the challenge-response mechanism, as described 723 in [4]. In this case, the mobile node inserts the 64 bit response 724 value (timestamp or nonce, according to Mobile IPv4 [7]) in the 725 Identification field in the Regional Registration Request. Thus, 726 the GFA SHOULD expect such an Identification field. When a mobile 727 node, which has already registered a GFA care-of address with its 728 home agent, changes foreign agent within the same domain and receives 729 an Agent Advertisement which advertises another GFA address, it MAY 730 still generate a Regional Registration Request message destined to 731 its old GFA. 733 5.2. Foreign Agent Considerations 735 When the foreign agent receives a Regional Registration Request 736 message from a mobile node, addressed to a GFA, it processes the 737 message generally according to the rules of processing a Registration 738 Request message addressed to a home agent (see section 4.2). The 739 only difference is that the GFA IP address field replaces the home 740 agent address field. If that address belongs to a known GFA, the 741 foreign agent forwards the request to the indicated GFA. Otherwise, 742 the foreign agent MUST generate a Regional Registration Reply with 743 error code UNKNOWN_GFA. 745 For each pending or current registration, the foreign agent maintains 746 a visitor list entry as described in [7]. If reverse tunneling is 747 being used, the visitor list MUST contain the address of the GFA, in 748 addition to the fields required in [7]. This is required so that the 749 foreign agent can tunnel datagrams, sent by the mobile node, to the 750 GFA. The GFA then decapsulates the datagrams, re-encapsulates them 751 and sends them to the home agent. 753 5.3. GFA Considerations 755 If the GFA accepts a request for regional registration, it MUST set 756 the lifetime to be no greater than the remaining lifetime of the 757 mobile node's registration with its home agent, and put this lifetime 758 into the corresponding Regional Registration Reply. The GFA MUST NOT 759 accept a request for a regional registration if the lifetime of the 760 mobile node's registration with its home agent has expired. In that 761 case the GFA sends a Regional Registration Reply with the value in 762 the Code field set to NO_HOME_REG. 764 If the GFA receives a tunneled packet from a foreign agent in its 765 domain, then after decapsulation the GFA looks to see whether it has 766 an entry in its visitor list for the source IP address of the inner 767 IP header after decapsulation. If so, then it checks the visitor 768 list to see whether reverse tunneling has been requested; if it was 769 requested, the GFA re-encapsulates the packet with its own address 770 as the source IP address, and the address of the home agent as the 771 destination IP address. 773 6. Generalized NAI Extension 775 The revised specification for "IP Mobility Support for IPv4" [7] 776 defines a new extension header format, that is intended to extend 777 the Mobile IP extension address space. The use of a Network Access 778 Identifier (NAI) [2] for mobile nodes is specified for Mobile IPv4 779 in [3]. The Generalized NAI (GNAI) extension, defined in this 780 section, uses the new extension header format to extend this idea, 781 enabling NAIs to be used for identifying IPv4 mobility agents (i.e., 782 the Foreign Agent or the Home agent) or other possible network 783 elements that may be involved with the processing of Registration 784 Requests. For Regional Registration, only a single sub-type is 785 defined; it is used to carry a Foreign Agent's NAI (see section 7.2). 787 The GNAI extension, illustrated in figure 4, may be carried by 788 Registration Request and Reply messages. 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Type | Length | Sub-Type | NAI ... 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Figure 4: The Generalized NAI (GNAI) Extension 798 Type (Type to be assigned by IANA) (skippable) 800 Length 8-bit unsigned integer. Length of the extension, 801 in octets, excluding the extension Type and 802 the extension Length fields, but including the 803 Sub-Type field and the variable length NAI field. 805 Sub-Type 8-bit unsigned integer identifying the specific 806 sub-type of the GNAI extension, and thus be 807 implication the type of the entity which is to be 808 identified by using the NAI. 810 NAI A string containing the Network Access Identifier 811 NAI in the format prescribed in [2]. 813 When a mobile node or home agent adds a GNAI extension to a 814 registration message, the extension MUST appear prior to any 815 authentication extensions. 817 When the Foreign Agent adds an GNAI extension to a registration 818 message, the extension MUST appear prior to any authentication 819 extensions added by the FA. 821 7. Router Discovery Extensions 823 This section specifies a new flag within the Mobile IP Agent 824 Advertisement, and an optional extension to the ICMP Router Discovery 825 Protocol [5]. 827 7.1. Regional Registration Flag 829 The only change to the Mobility Agent Advertisement Extension 830 defined in [7] is a flag indicating that the domain, to which the 831 foreign agent generating the Agent Advertisement belongs, supports 832 regional registrations. The flag is inserted after the flags defined 833 in [7], [6] and [10]. 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type | Length | Sequence Number | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Lifetime |R|B|H|F|M|G|V|T|S|I| reserved | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | zero or more Care-of Addresses | 843 | ... | 845 The flag is defined as follows: 847 I Regional registration. This domain supports Regional 848 Registration as specified in this document. 850 7.2. Foreign Agent NAI Extension 852 The FA-NAI extension is defined as a subtype 4 of the Generalized NAI 853 Extension (GNAIE) (see section 6). 855 The foreign agent SHOULD include its NAI in the Agent Advertisement 856 message. If present, the Foreign Agent NAI (FA-NAI) extension 857 MUST appear in the Agent Advertisement message after any of the 858 advertisement extensions defined in [7]. 860 By comparing the domain part of the foreign agent NAI with the domain 861 part of its own NAI, the mobile node can determine whether it is in 862 its home domain or in a visited domain, and whether it has changed 863 domain since it last registered. 865 8. Regional Extensions to Mobile IPv4 Registration Messages 867 In this section we specify new Mobile IP registration extensions for 868 the purpose of managing regional registrations. 870 8.1. GFA IP Address Extension 872 If the mobile node requests a dynamically assigned GFA, the GFA 873 adds a GFA IP Address extension to the Registration Request before 874 relaying it to the HA. The mobile node indicates that it wants a GFA 875 to be assigned by sending a Registration Request message with the 876 care-of address field set to zero. The GFA IP Address extension MUST 877 appear in the Registration Request message before the Foreign-Home 878 Authentication extension, if present. 880 0 1 2 3 881 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 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Type | Length | GFA IP Address .... 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 GFA IP Address | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Figure 5: The GFA IP Address extension 890 If a home agent receives a Registration Request message with the 891 care-of address set to zero, and a GFA IP Address extension, it MUST 892 register the IP address of the GFA as the care-of address of the 893 mobile node. When generating a Registration Reply message, the home 894 agent MUST include the GFA IP Address extension from the Registration 895 Request in the Registration Reply message. The GFA IP Address 896 extension MUST appear in the Registration Reply message before the 897 Mobile-Home Authentication extension. 899 The GFA IP Address extension, illustrated in figure 5 is defined as 900 follows: 902 Type TBD (GFA IP Address) 904 Length 4 906 GFA IP Address The GFA IP Address field contains the Gateway 907 Foreign Agent's publicly routable address. 909 8.2. Hierarchical Foreign Agent Extension 911 The Hierarchical Foreign Agent extension may be present in a 912 Registration Request or Regional Registration Request message. When 913 this extension is added to a Registration Request by a foreign 914 agent, the receiving mobility agent sets up a pending registration 915 record for the mobile node, using the IP address in the Hierarchical 916 Foreign Agent extension as the care-of address for the mobile 917 node. Furthermore, in this case, the extension MUST be appended 918 at the end of all previous extensions that had been included in 919 the registration message as received by the foreign agent. The 920 Hierarchical Foreign Agent extension SHOULD be protected by an FA-FA 921 Authentication extension. When the receiving foreign agent receives 922 the registration message, it MUST remove the Hierarchical Foreign 923 Agent extension added by the sending foreign agent. 925 The Hierarchical Foreign Agent extension is defined as follows: 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Type | Length | FA IP Address .... 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 FA IP Address .... | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Figure 6: The Hierarchical Foreign Agent Extension 937 Type TBD (Hierarchical Foreign Agent) 939 Length 4 941 FA IP Address The IP Address of the foreign agent relaying 942 the Registration Request. 944 8.3. Replay Protection Style 946 When a mobile node uses Mobile IP to register a care-of address 947 with its home agent, the style of replay protection used for the 948 registration messages is assumed to be known by way of a Mobility 949 Security Association that is required to exist between the mobile 950 node and the home agent receiving the request. No such pre-existing 951 security association between the mobile node and the GFA is likely 952 to be available. By default, the mobile node SHOULD treat replay 953 protection for Regional Registration messages exactly as specified in 954 Mobile IPv4 [7] for timestamp-based replay protection. 956 If the mobile node requires nonce-based replay protection, also 957 as specified in Mobile IPv4, it MAY append a Replay Protection 958 extension to a home registration message. Since home registrations 959 are forwarded to the home agent by way of the GFA, the GFA will be 960 able to establish the selected replay protection (see section 4.3). 962 The GFA also uses this extension by adding a Replay Protection 963 Style extension to a Registration Reply to synchronize the replay 964 protection for Regional registrations (see section 4.3). 966 The format of this extension is shown in figure 7. 968 0 1 2 3 969 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 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Type | Length | Replay Protection Style | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | | 974 + Initial Identification + 975 | | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 Figure 7: The Replay Protection Extension 980 Type TBD (Replay Protection Style) 982 Length 2 984 Replay Protection Style 985 An integer specifying the style of replay protection 986 desired by the mobile node. 988 Initial Identification 989 The timestamp or nonce to be used for initial 990 synchronization for the replay mechanism. 992 Admissible values for the Replay Protection Style are as follows: 994 Value Replay Protection Style 995 ----- ----------------------- 996 0 timestamp [7] 997 1 nonce [7] 999 The Replay Protection Style extension MUST be protected by an 1000 authentication extension. If the mobile node has an established 1001 mobility security association with the GFA, the Replay Protection 1002 Style extension SHOULD be placed after the MN-HA authentication 1003 extension and before the MN-FA authentication extension. Otherwise 1004 the Replay Protection Style extension MUST be placed before the MN-HA 1005 authentication extension. 1007 Replay protection MAY also be provided through a challenge-response 1008 mechanism, at the foreign agent issuing the Agent Advertisement, as 1009 described in [4]. 1011 8.4. New Code Values for Registration Reply 1013 The values to use within the Code field of the Registration Reply are 1014 defined in [7]. In addition, the following values are defined: 1016 Registration denied by the FA: 1017 Error Name Value Section of Document 1018 ---------------------- ----- ------------------- 1019 SMOOTH_HO_REQUIRED TBD B.4 1021 Registration denied by the GFA: 1023 Error Name Value Section of Document 1024 ---------------------- ----- ------------------- 1025 REPLAY_PROT_UNAVAIL TBD 8.3 1026 GFA_ID_MISMATCH TBD 4.3 1028 Registration denied by the HA: 1030 Error Name Value Section of Document 1031 ---------------------- ----- ------------------- 1032 ZERO_CAREOF_ADDRESS TBD 4.4 1033 ZERO_COA_NOT_SUPP TBD 4.4 1035 9. Regional Registration Message Formats 1037 This section specifies two new registration message types: Regional 1038 Registration Request and Regional Registration Reply. These messages 1039 are used by the mobile node instead of the existing Registration 1040 Request and Registration Reply, in order to make registration work 1041 faster, and also to reduce network load for Mobile IP registration, 1042 as described in section 5. 1044 Regional registration messages are protected by requiring 1045 authentication extensions, in the same way as the existing Mobile IP 1046 registration messages are protected. The following rules apply to 1047 authentication extensions: 1049 - The Mobile-GFA Authentication extension [7] MUST be included in 1050 all regional registration messages. 1051 - The Mobile-Foreign Authentication extension [7] MAY be included 1052 in regional registration messages. 1053 - The Foreign-Home Authentication extension [7] MUST NOT be 1054 included in any regional registration message. 1056 9.1. Regional Registration Request 1058 The Regional Registration Request, illustrated below, is used by a 1059 mobile node to register with its current GFA. 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Type |S|B|D|M|G|r|T|x| Lifetime | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Home Address | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | GFA IP Address | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Care-of Address | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | | 1073 + Identification + 1074 | | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Extensions ... 1077 +-+-+-+-+-+-+-+- 1079 The Regional Registration Request message is defined as the 1080 Registration Request message in [7], but with the following changes: 1082 Type TBD (Regional Registration Request) 1084 GFA IP Address 1085 The IP address of the Gateway Foreign Agent. (Replaces 1086 Home Agent field in Registration Request message 1087 in [7].) 1089 Care-of Address 1090 Care-of address of local foreign agent; MAY be set to 1091 all ones. 1093 Extensions 1095 For the Regional Registration Request, the Hierarchical Foreign Agent 1096 Extension is also an allowable extension in addition to those which 1097 are allowable for the Registration Request message. 1099 9.2. Regional Registration Reply 1101 The Regional Registration Reply message, illustrated below, delivers 1102 the indication of regional registration acceptance or denial to a 1103 mobile node. The UDP header is followed by the Mobile IP fields 1104 shown below: 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type | Code | Lifetime | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Home Address | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Regional FA IP Address | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | | 1116 + Identification + 1117 | | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Extensions ... 1120 +-+-+-+-+-+-+-+- 1122 This message is defined as the Registration Reply message in [7], but 1123 with the following changes: 1125 Type TBD (Regional Registration Reply) 1127 Regional FA IP Address 1128 The IP address of the Gateway Foreign Agent. (Replaces 1129 Home Agent field specified in Mobile IPv4 [7]). 1131 Extensions 1133 The Regional FA IP Address is the address of the regional foreign 1134 agent generating the Regional Registration Reply message. For the 1135 two-level hierarchy specified here, it is the address of the GFA. For 1136 more levels of hierarchy, it may be the address of an intermediate 1137 RFA. 1139 9.3. New Regional Registration Reply Code Values 1141 For a Regional Registration Reply, the following additional Code 1142 values are defined in addition to those specified in Mobile IPv4 [7]. 1144 Registration denied by the FA: 1146 Error Name Value Section of Document 1147 ---------------------- ----- ------------------- 1148 UNKNOWN_GFA TBD 5.2 1149 GFA_UNREACHABLE TBD 1150 GFA_HOST_UNREACHABLE TBD 1151 GFA_PORT_UNREACHABLE TBD 1152 SMOOTH_HO_REQUIRED TBD B.4 1154 Registration denied by the GFA: 1156 Error Name Value Section of Document 1157 ---------------------- ----- ------------------- 1158 NO_HOME_REG TBD 5.3 1160 The four first Code values are returned to the mobile node in 1161 response to ICMP errors that may be received by the foreign agent. 1163 10. Authentication Extensions 1165 In this section, two new subtypes for the Generalized Authentication 1166 Extension [4] are specified. First, the FA-FA Authentication 1167 extension is used by regional foreign agents to secure the 1168 Hierarchical Foreign Agent (HFA) extension to the Registration 1169 Request and Regional Registration Request messages. A new 1170 authentication extension is necessary because the HFA extension 1171 is typically added after the Mobile-Home (or some other 1172 authorization-enabling [7] (e.g. MN-AAA [3], see section C) 1173 authentication extension. 1175 The MN-GFA authentication extension is used whenever the mobile node 1176 has a co-located address. Furthermore, the MN-GFA extension is used 1177 to provide authentication for a Regional Registration Request. 1179 The subtype values for these new subtypes are as follows: 1181 Subtype Name Value 1182 ---------------------- ------ 1183 FA-FA authentication TBD 1184 MN-GFA authentication TBD 1186 The default algorithm for computation of the authenticator is the 1187 same as for the MN-AAA Authentication subtype defined in [4]. 1189 11. IANA considerations 1191 This document defines: 1193 - The Generalized NAI extension, specified in section 6. The type 1194 number for this new extension is to be assigned from the number 1195 space for Mobile IPv4 skippable extensions (128-255). 1197 - A Sub-Type for the GNAI extension is specified in section 7.2, 1198 which needs to have a value assigned from the space of GNAI 1199 subtypes. 1201 - Three new extensions to Mobile IP Registration messages: GFA IP 1202 Address, Hierarchical Foreign Agent, and Replay Protection Style 1203 (see section 8.1, 8.2 and 8.3). The Type values for the GFA IP 1204 Address extension must be within the range 0 through 127, while 1205 the other two must be within the range 128 through 255. 1207 - New Code values for Registration Reply messages (see 1208 section 8.4). 1210 - Two new subtypes for the Generalized Authentication 1211 Extension [4]; see section 10 1213 - Two new message types for Mobile IP: Regional Registration 1214 Request and Regional Registration Reply (see section 9.1 1215 and 9.2). 1217 - Code values for Regional Registration Reply messages (see section 1218 9.3) 1220 12. Security Considerations 1222 This document proposes a method for a mobile node to register locally 1223 in a visited domain. The authentication extensions to be used are 1224 those defined either in [7], [10], or [8]. Key distribution is to be 1225 performed, for instance, according to [8], or [11]. 1227 If the Hierarchical Foreign Agent (HFA) extension is appended to a 1228 Registration Request message, that extension is to be followed by 1229 an FA-FA Authentication Extension (see section 10) to prevent any 1230 modification to the data. Likewise, if the GFA IP Address extension 1231 is added to such a message, it is to be followed by an authentication 1232 extension. 1234 13. Acknowledgements 1236 This document is a logical successor to documents written with Pat 1237 Calhoun and Gabriel Montenegro; thanks to them and their many efforts 1238 to help explore this problem space. Many thanks also to Jari Malinen 1239 at the Nokia Research Center for his commentary on a rough version of 1240 this document, and providing motivation for section B.4. 1242 The text in section 6 was taken directly from a previous Internet 1243 Draft [9] written by Mohamed M. Khalil, Emad Qaddoura, Haseeb Akhtar 1244 of Nortel Networks, along with Pat R. Calhoun of Airespace Networks. 1246 References 1248 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 1249 Levels. Request for Comments (Best Current Practice) 2119, 1250 Internet Engineering Task Force, March 1997. 1252 [2] B. Aboba and M. Beadles. The Network Access Identifier. 1253 Request for Comments (Proposed Standard) 2486, Internet 1254 Engineering Task Force, January 1999. 1256 [3] P. Calhoun and C. Perkins. Mobile IP network access identifier 1257 extension for IPv4. Request for Comments (Proposed Standard) 1258 2794, Internet Engineering Task Force, January 2000. 1260 [4] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 1261 Challenge/Response Extension. Request for Comments (Proposed 1262 Standard) 3012, Internet Engineering Task Force, December 2000. 1264 [5] S. Deering. ICMP Router Discovery Messages. Request for 1265 Comments (Proposed Standard) 1256, Internet Engineering Task 1266 Force, September 1991. 1268 [6] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 1269 Request for Comments (Proposed Standard) 3024, Internet 1270 Engineering Task Force, January 2001. 1272 [7] C. Perkins. IP Mobility Support. Request for Comments 1273 (Proposed Standard) 3344, Internet Engineering Task Force, 1274 August 2002. 1276 [8] P. Calhoun and C. Perkins. DIAMETER mobile IP extensions (work 1277 in progress). Internet Draft, Internet Engineering Task Force, 1278 February 2004. 1280 [9] Mohamed Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R. 1281 Calhoun. Generalized NAI Extension (GNAIE) (work in progress). 1282 draft-ietf-mobileip-gnaie-00.txt, September 2001. 1284 [10] C. Perkins and D. Johnson. Route optimization in mobile IP 1285 (work in progress). Internet Draft, Internet Engineering Task 1286 Force, September 2001. 1288 [11] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys 1289 for Mobile IP (work in progress). Internet Draft, Internet 1290 Engineering Task Force, October 2002. 1292 Normative references are [1] through [7]. Informational references 1293 are [9] through [11]. 1295 A. Changes from Previous Versions 1297 The following updates and changes were made in this version of the 1298 Mobile IP Regional Registration draft, compared to earlier versions. 1300 A.1. Updates from version 06 1302 Updated the Abstract and Introduction. 1304 Updated section 3.1.2 1306 Backwards compatibility. Changed the Agent 1307 Advertisement, so that if only one address is 1308 advertised, it is the FA address, and not the GFA 1309 address, and instead of advertising a zero care-of 1310 address for dynamic allocation of GFA address, it is 1311 an `all ones' address. Added section 3.4. 1313 Added the Code `ZERO_COA_NOT_SUPP' for Registration 1314 Replies. 1316 Let the GFA add the GFA IP Address extension to a 1317 Registration Request, instead of the FA, i.e. moved 1318 text from section 4.2 to section 4.3 and updated 1319 section 8.1. 1321 Clarified how home registrations that are about 1322 to expire should be handled in section 4.1 and 1323 section 4.3. 1325 Clarified how authentication extensions should be 1326 used in section 4.1 and section 8.3. 1328 Changed the Reply Code HOME_REG_EXPIRED to 1329 NO_HOME_REG, since when the registration has expired, 1330 the binding is removed, and the GFA doesn't know if a 1331 binding for this mobile node has ever existed. 1333 Clarified that the GFA IP address extension must be 1334 protected when the Registration Request is sent to 1335 the HA in section 4.3. 1337 Added a way for the GFA to synchronize the replay 1338 protection with the mobile node for Regional 1339 registrations in sections 4.3, 8.3, and 8.4. 1341 Clarified the use of Binding Updates for multiple 1342 hierarchies in section B.2 and B.3. 1344 Upgraded citations for RFC 2002 to instead refer to 1345 RFC 3344. 1347 A.2. Updates from version 05 1349 Specified the GNAI extension (see section 6, as was 1350 previously done in [9]. Changed IANA considerations 1351 and section 7.2 as needed. 1353 Upgraded citations for RFC 2002 to instead refer to 1354 RFC 3220. 1356 A.3. List of updates made for previous revisions 1358 Added `v4' to the title, changed all code values, 1359 message types and extensions to `TBD', and added an 1360 `IANA Considerations' section. 1362 Section 3.3 Clarified that the care-of address can be zero. 1364 Section 4.2 Added that any Foreign Agent that supports regional 1365 registrations must be able to assign a GFA to 1366 a mobile node if the care-of address in the 1367 Registration Request is zero. 1369 Section 5.2 Clarified that in regional registrations the GFA 1370 address field replaces the HA address field. 1372 Section 5.3 Added a new error code: HOME_REG_EXPIRED that the 1373 GFA use when denying a regional registration because 1374 the home registration lifetime has expired. 1376 Section 7.1 Clarified the placement of the 'I' flag. 1378 Section 10 Added reference to a default algorithm for the 1379 authentication extensions. 1381 Section B.5 Added a section to allow a mobile node with a 1382 co-located care of address to use multi-level 1383 hierarchies. 1385 Section B.4 Interactions with delivery of Binding Update messages 1386 to RFAs along the previous routing path have been 1387 suggested in order to prevent various race conditions 1388 that have been observed in practice. 1390 A.4. Updates from version 02 1392 The following updates and changes were made in this version of the 1393 Mobile IP Regional Registration draft, compared to the earlier 1394 version (version 02). 1396 Section 4.3 The contents of the visitor list entry at the 1397 GFA have been clarified. A GFA keeps a visitor 1398 list entry for each pending or current home 1399 registration. The entry is also updated for the 1400 regional registrations performed by the mobile 1401 node. 1403 Section 8.4 A new code value for the Registration Reply has 1404 been defined: MISSING_GFA_ADDRESS. This section 1405 has also been re-structured for clarification. 1407 Section 5.1 Specific message types for regional 1408 registrations messages (Regional Registration 1409 Request and Regional Registration Reply) were 1410 defined. The reason for defining specific 1411 message types for the regional registration 1412 messages, instead of using the Registration 1413 Request and Reply as defined in [7] are the 1414 following: 1416 - a mobile node must be able to distinguish 1417 between regional registrations and home 1418 registrations, because when it uses 1419 regional registration, the nonces are not 1420 synchronized with its home agent; 1422 - a mobile node can use a zero care-of 1423 address either to request a GFA (in a home 1424 registration) or to signify the use of an 1425 unspecified regional foreign agent (in a 1426 regional registration). 1428 For regional registrations, the 1429 challenge-response mechanism may be used 1430 to provide replay protection. In this case, the 1431 mobile node inserts the 64 bit response value 1432 in the Identification field in the Regional 1433 Registration Request. 1435 Section 7.2 The FA-NAI extension is defined as a subtype TBD 1436 of the Generalized NAI Extension (GNAIE). 1438 Section 9 This entire section is added to the draft, and 1439 it describes the Regional Registration Request 1440 and Regional Registration Reply messages. 1442 Appendix B The contents of the visitor list entry at the 1443 RFA and GFA have been clarified. An RFA/GFA 1444 keeps a visitor list entry for each pending or 1445 current home registration. The entry is also 1446 updated for the regional registrations performed 1447 by the mobile node. 1449 Appendix D This appendix has been added to the draft. It 1450 clarifies how a mobile node can register a 1451 care-of address with its home agent; a GFA, RFA 1452 or FA care-of address, and then maintain this 1453 care-of address when it moves in the visited 1454 domain. 1456 B. Hierarchical Foreign Agents 1458 The main body of this specification assumes two hierarchy levels of 1459 foreign agents in the visited domain. At the top level, there is one 1460 or several GFAs, and on the lower level, there is a number of foreign 1461 agents. The structure can be extended to include multiple hierarchy 1462 levels of foreign agents beneath the GFA level (Figure 8). Such 1463 multiple hierarchy levels are discussed in this appendix. 1465 We assume that security associations have been established among 1466 a GFA and all the foreign agents beneath it in the hierarchy. As 1467 before, we assume that when a mobile node performs registration at 1468 its home network, registration keys are generated and distributed to 1469 the mobile node and to the GFA. The GFA may then in turn distribute 1470 the registration keys to the foreign agents beneath it in the 1471 hierarchy, using methods not specified in this document. We also 1472 assume that all foreign agents and the mobile node support smooth 1473 handover as specified in [10], with some modifications as explained 1474 below. 1476 B.1. Registration with Home Agent 1478 As described in this specification, a foreign agent announces itself 1479 and a GFA in the Agent Advertisement in the first and last address 1480 in the care-of address field in the Mobility Agent Advertisement 1481 extension [7]. If there is a hierarchy of foreign agents between 1482 the GFA and the announcing foreign agent, the foreign agent MUST 1483 support smooth handover (specifically, the Previous Foreign Agent 1484 Notification extension) as described in [10]. The foreign agent MAY 1485 +--------+ 1486 | | 1487 | GFA | 1488 | | 1489 +--------+ 1490 / | \ 1491 ... ... ... 1492 | 1493 +--------+ 1494 | | 1495 | RFA3 | 1496 | | 1497 +--------+ 1498 / \ 1499 +--------+ +--------+ 1500 | | | | 1501 | FA2 | | FA1 | 1502 | | | | 1503 +--------+ +--------+ 1504 | | 1505 | +--------+ 1506 ... | | 1507 | MN | 1508 | | 1509 +--------+ 1511 Figure 8: Domain with a GFA and multiple hierarchies of FAs, enabled 1512 for regional registrations. 1514 also include the addresses of the foreign agents in the hierarchy in 1515 order between its own address (first) and the GFA address (last): 1517 - Address of announcing foreign agent 1518 - Address of the next higher-level Regional Foreign Agent (RFA) 1519 - ... 1520 - Address of GFA 1522 If a foreign agent advertises the entire hierarchy between itself and 1523 the GFA, the Registration Request messages MUST be delivered to each 1524 RFA address in turn within that hierarchy. 1526 When newly arriving at a visited domain, the mobile node sends 1527 a Registration Request, with the care-of address set to the GFA 1528 address announced in the Agent Advertisement. The mobile node may 1529 also request a GFA to be assigned, as described earlier in this 1530 specification. The registration Request MUST include the Previous 1531 Foreign Agent Notification Extension defined in [10]. The Binding 1532 Update that results is processed as described in Section B.2. 1534 When the foreign agent closest to the mobile node receives the 1535 Registration Request, processing is as described in Section 4.2. 1536 It adds a Hierarchical Foreign Agent extension to the Registration 1537 Request, including its own address, and relays the Registration 1538 Request to the next RFA in the hierarchy toward the GFA. It also 1539 constructs a Binding Update and sends it to the previous foreign 1540 agent, as defined in [10]. 1542 The next RFA receives the Registration Request. For each pending 1543 or current registration, an RFA maintains a visitor list entry. In 1544 addition to the list entry contents (described in [7]), the list 1545 entry for regional registrations MUST contain: 1547 - the address of the next lower-level RFA, or FA, in the hierarchy 1548 - the remaining Lifetime of the regional registration 1549 - the style of replay protection in use for the regional 1550 registration 1551 - the Identification value for the regional registration. 1553 The RFA removes the Hierarchical Foreign Agent extension that the 1554 last FA or RFA added, and adds a new Hierarchical Foreign Agent 1555 extension with its own address. This procedure is repeated at each 1556 RFA, or FA, in the hierarchy under the GFA. 1558 When the GFA receives the Registration Request, it removes the 1559 Hierarchical Foreign Agent extension and caches information about 1560 the next lower-level RFA in the hierarchy. It then relays the 1561 Registration Request to the home agent, possibly via AAA servers. 1563 For each pending or current home registration, the GFA maintains 1564 a visitor list entry as described in [7]. The list entry is also 1565 updated for regional registrations reaching the GFA. In addition to 1566 the list entry contents required in [7], the list entry MUST contain: 1568 - the address of the next lower-level RFA in the hierarchy 1569 - the remaining Lifetime of the regional registration 1570 - the style of replay protection in use for the regional 1571 registration 1572 - the Identification value for the regional registration. 1574 If there is only one level of hierarchy beneath the GFA, the address 1575 of the next lower-level RFA is the current care-of address of the 1576 mobile node, as stated in Section 4.3. 1578 The home agent, as described before, processes the Registration 1579 Request, stores the GFA address as the current care-of address of 1580 the mobile node, generates a Registration Reply, and sends it to the 1581 GFA. The home agent also distributes a registration key to the mobile 1582 node, perhaps with the assistance of the GFA, for instance by way of 1583 other AAA functions [11]. When the GFA receives the Registration 1584 Reply, it checks its pending Registration Request record to see which 1585 next lower-level RFA to send the Registration Reply message to. 1586 It SHOULD then add, for instance, a new FA-FA Key Reply extension 1587 to the Registration Reply message, before relaying it to the next 1588 foreign agent. The new FA-FA Agent Key Reply extension contains the 1589 registration key, encrypted with a secret shared between the GFA and 1590 the next lower-level RFA in the hierarchy. Similar procedures are to 1591 be used with [11]. 1593 The next lower-level RFA receives the Registration Reply and checks 1594 its pending Registration Request record to see which lower-level 1595 foreign agent should next receive the Registration Reply. It 1596 extracts, decrypts and caches the registration key, and relays the 1597 Registration Reply to the next foreign agent. This procedure is 1598 repeated in every foreign agent in the hierarchy, until the message 1599 reaches the foreign agent closest to the mobile node. 1601 When the lowest-level foreign agent receives the Registration Reply, 1602 it checks its cached information, as described in [7], and relays the 1603 Registration Reply to the mobile node. 1605 B.2. Handling Binding Updates 1607 Meanwhile, when the previous foreign agent receives the Binding 1608 Update, it will process it according to [10], except that instead 1609 of sending back a Binding Acknowledge message, it sends the Binding 1610 Update to the next RFA in the hierarchy towards the GFA. This is 1611 done to make sure that all RFAs in the path to the previous FA are 1612 notified that the mobile node has moved. The previous foreign agent 1613 must be sure that the next RFA received the Binding Update, therefore 1614 the RFA MUST send a Binding Acknowledge message back to the foreign 1615 agent that it got the Binding Update from. Note that this is the 1616 same Binding Acknowledge message than the one defined in [10], but 1617 this one is addressed to the IP address of the Foreign Agent that 1618 sent the Binding Update instead of to the mobile node. 1620 The RFA that received the Binding Update sends the Binding 1621 Acknowledge message back to the lower-layer Foreign Agent, and relays 1622 the Binding Update to the next RFA in the hierarchy towards the GFA. 1623 The RFA will also update the binding cache for the mobile node so 1624 that it will expire according to the lifetime in the Binding Update, 1625 but the binding cache entry will still point to the same lower-level 1626 foreign agent. 1628 The crossover FA is the foreign agent lowest in the hierarchy which 1629 is part of both the old and the new path to the mobile node. When 1630 the Binding Update reaches the crossover FA, which might be an RFA or 1631 the GFA, it will, in addition to sending a Binding Acknowledge back 1632 to the sending RFA, also send a Binding Acknowledge to the mobile 1633 node. This Binding Acknowledge message is the one defined in [10] 1634 and it is addressed to the mobile node and sent down the hierarchy 1635 via the old path and the previous Foreign Agent, who tunnels it to 1636 the new Foreign Agent. 1638 The crossover FA will receive both a Registration Request and a 1639 Binding Update for the mobile node. When the crossover FA receives 1640 the Registration Request, it continues to send traffic via the 1641 old path until it receives a valid Registration Reply with a Code 1642 indicating success. Then it starts sending traffic via the new 1643 route. 1645 In the unlikely event that the crossover FA receives the Binding 1646 Update before it receives the Registration Request, it doesn't know 1647 that it is the crossover FA yet, and therefore relays the Binding 1648 Update to the next Foreign Agent. When the crossover FA later 1649 receives the Registration Request, it will know that it is the 1650 crossover FA, and will send a Binding Acknowledge message to the 1651 mobile node (via the old route). It also forwards the Registration 1652 Request up to the next FA. The foreign agents above the crossover FA 1653 in the hierarchy that already got the Binding Update will see that 1654 the Registration Request does not supply any new care-of address 1655 information (the care-of address is the same as the address in 1656 the Binding Update) and will therefor ignore the previous Binding 1657 Update and update the mobility binding according to the Registration 1658 Request. 1660 B.3. Regional Registration 1662 A Regional Registration Request is forwarded to the GFA by way of 1663 one or more intermediate regional foreign agents. When the Regional 1664 Registration Request message arrives at the first foreign agent, the 1665 foreign agent checks its visitor list to see if this mobile node 1666 is already registered with it. If it is not, the foreign agent 1667 checks which next higher-level RFA to relay the Regional Registration 1668 Request to. It adds a Hierarchical Foreign Agent extension to the 1669 Regional Registration Request, including its address, and relays the 1670 message to the next RFA in the hierarchy toward the GFA. 1672 The next RFA checks its visitor list to see if the mobile node is 1673 already registered with it. If it is not, the RFA removes the 1674 Hierarchical Foreign Agent extension and adds a new one, with its own 1675 address, and relays the message to the next higher-level RFA in the 1676 hierarchy toward the GFA. 1678 This process is repeated in each RFA in the hierarchy, until an RFA 1679 recognizes the mobile node as already registered. This RFA may be 1680 the GFA, or any RFA beneath it in the hierarchy. If the mobile node 1681 is already registered with this RFA, the RFA generates a Regional 1682 Registration Reply and sends it to the next lower-level RFA in the 1683 hierarchy. The lifetime field in the Regional Registration Reply is 1684 set to the remaining lifetime that was earlier agreed upon between 1685 the mobile node and the GFA. If the lifetime of the GFA registration 1686 has expired, the Regional Registration Request is relayed all the way 1687 to the GFA. 1689 The Previous Foreign Agent Notification Extension, Binding Updates 1690 and Binding Acknowledge messages are used for Regional Registrations 1691 in the same way as for Home Registrations. That means that if the 1692 crossover FA receives the Binding Update before it receives the 1693 Registration Request, it forwards the Registration Request to the 1694 higher level FA, so that that FA updates its visitor list according 1695 to the Registration Request, and ignores the Binding Update. That FA 1696 also forwards the Registration Request to any FA or GFA that it has 1697 sent the corresponding Binding Update to. 1699 If the hierarchy between the advertising foreign agent and the GFA is 1700 announced in the Agent Advertisement, the mobile node may generate 1701 a Regional Registration Request not destined to the GFA, but to the 1702 closest RFA with which it can register. 1704 Replay protection can be provided at the announcing foreign agent, 1705 through the challenge-response mechanism described in [4]. If the 1706 GFA, and the RFAs in the hierarchy, trust the announcing foreign 1707 agent to perform the replay protection, timestamps or nonces between 1708 the mobile node and the GFA, or between the mobile node and each 1709 RFA, are not needed. If the challenge-response mechanism is used 1710 for replay protection, the mobile node inserts the 64 bit response 1711 value in the Identification field in the Regional Registration 1712 Request message. If a mobile node includes a Hierarchical Foreign 1713 Agent extension in its Registration Request message, it MAY insert 1714 the extension before the MN-HA or MN-FA authentication extension. 1715 In this case, the Hierarchical Foreign Agent extension MUST NOT be 1716 removed by the GFA or any other RFA prior to the generation of the 1717 Registration Reply message. 1719 If more than one Hierarchical Foreign Agent extension is inserted 1720 by the mobile node into the registration message, the order of the 1721 extensions MUST be maintained through the hierarchy. When sending a 1722 Regional Registration Reply, the GFA MUST ensure that the order of 1723 the Hierarchical Foreign Agent extensions is reversed from the order 1724 found in the Regional Registration Request. 1726 B.4. Regional Registrations and Smooth Handover 1728 Multiple hierarchy levels of foreign agents requires the use of 1729 smooth handover from [10], as discussed in Appendix B. This is 1730 not needed in a two level hierarchy. But a mobile node might not 1731 know how many levels of hierarchy a network has, so if the foreign 1732 agents in one network support both Regional Registrations and 1733 Smooth Handover a mobile node MAY try to use Regional Registrations 1734 without Smooth Handover. If the network requires the use of Smooth 1735 Handover (because it has more than two levels of hierarchy, or 1736 for other reasons) the Foreign Agent MUST deny the request by 1737 sending back a Registration Reply message with the Code field set to 1738 SMOOTH_HO_REQUIRED. 1740 The Foreign Agent NAI extension (see section 7.2) is also used during 1741 Smooth Handover. If Smooth Handovers are used, and the foreign 1742 agent does not advertise its own address in the Agent Advertisement 1743 message, the FA-NAI will be used to identify the Previous Foreign 1744 agent instead. This will be done by adding an FA-NAI extension 1745 (defined in section 6) to the Registration Request (together with the 1746 Previous Foreign Agent Notification extension) and in the Binding 1747 Update and setting the care-of address to zero. 1749 B.5. Co-located care of address 1751 If a mobile node uses a co-located care-of address, it MAY use 1752 Regional Registrations directly to the GFA (see section 4.1 and 1753 section 5). It MAY also use the same method to make use of multiple 1754 levels of Foreign Agents, if it can find out about the hierarchy, 1755 either from Mobility Agent Advertisements, or in some other way 1756 outside the scope of this specification. 1758 B.6. Data Traffic 1760 When a correspondent node sends traffic to the mobile node, the 1761 traffic arrives at the home agent, and the home agent tunnels the 1762 traffic to the GFA. The GFA or RFA at each level of the hierarchy has 1763 a visitor list for the mobile node, showing the address of the next 1764 lower-level RFA or FA in the hierarchy. Thus, a datagram arriving at 1765 the top level of the hierarchy, that is, the GFA, will be re-routed 1766 to the next lower-level RFA in the hierarchy. This re-routing occurs 1767 at each level of the hierarchy, until the datagram reaches the last 1768 point which is either the mobile node itself (in case of a co-located 1769 care-of address) or a foreign agent that can deliver the datagram to 1770 the mobile node with no further special Mobile IP handling. 1772 In case of decapsulation and re-encapsulation, it should be noted 1773 that the actual decapsulation need not occur at each step of the 1774 hierarchy. Instead, the foreign agent at that level can merely 1775 change the source and destination IP addresses of the encapsulating 1776 IP header. 1778 Traffic from the mobile node is sent as described in [7] or [6]. 1780 According to the Route Optimization specification [10], Binding 1781 Updates send to the correspondent node from the Home Agent 1782 will contain the address of the GFA, since this is the only 1783 care-of address known to the Home Agent. Therefore, Binding Updates 1784 from the mobile node sent to the correspondent node SHOULD also have 1785 the care-of address belonging to the GFA. This also has the advantage 1786 of reducing the number of Binding Update messages that have to be 1787 sent to the correspondent node, at a modest increase in routing path 1788 length. Furthermore, the local network domain may be configured to 1789 admit such traffic into the local domain only if packets are tunneled 1790 directly to the GFA. 1792 B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension 1794 If a GFA uses the Registration Reply to distribute an MN-FA key to 1795 the other RFAs in its domain, a new subtype for the Generalized MN-FA 1796 Key Reply Extension [11] is required. 1798 The subtype value is as follows: 1800 Subtype Name Value 1801 -------------- ------------ 1802 GFA-RFA Key Reply 5 1804 The subtype data for the GFA-RFA Key Reply subtype is a 4 byte SPI, 1805 followed by the registration key encoded according to the recipe 1806 indicated by the SPI. 1808 C. Authentication, Authorization and Accounting AAA Interactions 1810 When the mobile node has to obtain authorization by way of 1811 Authentication, Authorization and Accounting (AAA) infrastructure 1812 services, the control flow implicit in the main body of this 1813 specification is likely to be modified. Typically, the mobile node 1814 will supply credentials for authorization by AAA as part of its 1815 registration messages. The GFA will parse the credentials supplied 1816 by the mobile and forward the appropriate authorization request to a 1817 local AAA server (see [4, 8]). 1819 Concretely, this means that: 1821 - The GFA MAY include the Mobile IP Registration Request data 1822 inside an authorization request, directed to a local AAA server. 1824 - The GFA MAY receive the Mobile IP Registration Reply data 1825 from a message granting authorization, received from the AAA 1826 infrastructure. 1828 D. Anchoring at a GFA/RFA/FA 1830 As described earlier in this draft, once a mobile node has registered 1831 the address of a GFA as its care-of address with its home agent, it 1832 MAY perform regional registrations when changing foreign agent under 1833 the same GFA. When detecting that is has changed foreign agent, and 1834 if the new foreign agent advertises the `I' flag, the mobile node MAY 1835 address a Regional Registration Request message to its registered 1836 GFA, even if the address of that particular GFA is not advertised by 1837 the new foreign agent. The foreign agent MAY then relay the request 1838 to the GFA in question, or deny the request with error code 'unknown 1839 GFA'. 1841 Similarly, a mobile node MAY address a Regional Registration Request 1842 message to any Regional Foreign Agent or foreign agent that it has 1843 registered as the current care-of address with its home agent. 1844 Assume that a mobile node has registered the address of an RFA or 1845 foreign agent as its care-of address with its home agent. When 1846 detecting that it changes foreign agent, and if the new foreign agent 1847 advertises the `I' flag, the mobile node MAY address a Regional 1848 Registration Request to that RFA/FA. The new foreign agent MAY then 1849 relay the request to the RFA/FA in question, or deny the request 1850 with error code 'unknown GFA'. If the Regional Registration Request 1851 reaches the RFA/FA, and if the RFA/FA also has the capability to 1852 act as a GFA, it MAY accept the request and generate a Regional 1853 Registration Reply to the mobile node. This scenario assumes that 1854 keys have been distributed to the RFA/FA and to the mobile node prior 1855 to the regional registration, so that the Regional Registration 1856 Request message can be authenticated with the MN-GFA Authentication 1857 extension. 1859 Intellectual Property 1861 The IETF takes no position regarding the validity or scope of any 1862 Intellectual Property Rights or other rights that might be claimed to 1863 pertain to the implementation or use of the technology described in 1864 this document or the extent to which any license under such rights 1865 might or might not be available; nor does it represent that it has 1866 made any independent effort to identify any such rights. Information 1867 on the procedures with respect to rights in RFC documents can be 1868 found in BCP 78 and BCP 79. 1870 Copies of IPR disclosures made to the IETF Secretariat and any 1871 assurances of licenses to be made available, or the result of an 1872 attempt made to obtain a general license or permission for the 1873 use of such proprietary rights by implementers or users of this 1874 specification can be obtained from the IETF on-line IPR repository at 1875 http://www.ietf.org/ipr. 1877 The IETF invites any interested party to bring to its attention any 1878 copyrights, patents or patent applications, or other proprietary 1879 rights that may cover technology that may be required to implement 1880 this standard. Please address the information to the IETF at 1881 ietf-ipr@ietf.org. 1883 Full Copyright Statement 1885 Full Copyright Statement 1887 Copyright (C) The Internet Society (2004). This document is subject 1888 to the rights, licenses and restrictions contained in BCP 78 and 1889 except as set forth therein, the authors retain all their rights. 1891 This document and the information contained herein are provided 1892 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1893 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1894 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1895 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1896 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1897 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1899 Addresses 1901 Questions about this memo can be directed to: 1903 Eva Gustafsson Annika Jonsson 1904 Ericsson Research Ericsson Research 1905 Torshamnsgatan 23 Torshamnsgatan 23 1906 SE-164 80 Stockholm SE-164 80 Stockholm 1907 SWEDEN SWEDEN 1909 Phone: +46 8 7641270 Phone: +46 8 4047242 1910 EMail: eva.gustafsson@ericsson.com EMail: annika.jonsson@ericsson.com 1911 Fax: +46 8 4047020 Fax: +46 8 4047020 1913 Charles E. Perkins 1914 Nokia Research Center 1915 313 Fairchild Drive 1916 Mountain View, California 94043 1917 USA 1919 Phone: +1-650 625-2986 1920 EMail: charles.perkins@nokia.com 1921 Fax: +1 650 625-2502