idnits 2.17.1 draft-ietf-mobileip-reg-tunnel-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 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 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. '1') (Obsoleted by RFC 4282) == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-06 ** Obsolete normative reference: RFC 3012 (ref. '5') (Obsoleted by RFC 4721) == Outdated reference: A later version (-05) exists of draft-ietf-mobileip-gnaie-00 ** Obsolete normative reference: RFC 3344 (ref. '9') (Obsoleted by RFC 5944) -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-10 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 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 22 October 2002 Annika Jonsson 4 Ericsson 5 Charles E. Perkins 6 Nokia Research Center 8 Mobile IPv4 Regional Registration 9 draft-ietf-mobileip-reg-tunnel-07.txt 11 Status of This Memo 13 This document is a submission by the mobile-ip Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the mobile-ip@sunroof.eng.sun.com 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 29 102 A.1. Updates from version 06 . . . . . . . . . . . . . . . . . 29 103 A.2. Updates from version 05 . . . . . . . . . . . . . . . . . 30 104 A.3. List of updates made for previous revisions . . . . . . . 30 105 A.4. Updates from version 02 . . . . . . . . . . . . . . . . . 31 107 B. Hierarchical Foreign Agents 32 108 B.1. Registration with Home Agent . . . . . . . . . . . . . . 32 109 B.2. Handling Binding Updates . . . . . . . . . . . . . . . . 35 110 B.3. Regional Registration . . . . . . . . . . . . . . . . . . 36 111 B.4. Regional Registrations and Smooth Handover . . . . . . . 38 112 B.5. Co-located care of address . . . . . . . . . . . . . . . 38 113 B.6. Data Traffic . . . . . . . . . . . . . . . . . . . . . . 38 114 B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension 39 116 C. Authentication, Authorization and Accounting AAA Interactions 39 118 D. Anchoring at a GFA/RFA/FA 40 120 Addresses 41 121 1. Introduction 123 This document is an optional extension to the Mobile IPv4 protocol, 124 and proposes a means for mobile nodes to register locally within a 125 visited domain. By registering locally, the number of signaling 126 messages to the home network are kept to a minimum, and the signaling 127 delay is reduced. 129 In Mobile IP, as specified in RFC 3344 [9], a mobile node registers 130 with its home agent each time it changes care-of address. If the 131 distance between the visited network and the home network of the 132 mobile node is large, the signaling delay for these registrations 133 may be long. We propose a solution for performing registrations 134 locally in the visited domain: regional registrations. The 135 regional registration design introduces new Mobile IPv4 messages 136 - Regional Registrations, new Mobile IPv4 extensions to convey 137 information between the mobile node, foreign agent and home agent, 138 and a new network entity: the Gateway Foreign Agent (GFA). Regional 139 registrations reduce the number of signaling messages to the home 140 network, and reduce the signaling delay when a mobile node moves from 141 one foreign agent to another within the same visited domain. This 142 will both decrease the load on the home network, and speed up the 143 process of handover within the visited domain. 145 When a mobile node first arrives at a visited domain, it performs a 146 _home_registration -- that is, a registration with its home agent. 147 At this registration, we assume that the home network generates 148 a registration key (e.g. using [11]) for the mobile node. This 149 registration key is distributed to the mobile node and to the visited 150 domain, and can be used for authentication of regional registrations. 152 During a home registration, the home agent registers the care-of 153 address of the mobile node. When the visited domain supports 154 regional tunnel management, the care-of address that is registered 155 at the home agent is the publicly routable address of a Gateway 156 Foreign Agent (GFA). This care-of address will not change when the 157 mobile node changes foreign agent under the same GFA. When changing 158 GFA, a mobile node MUST perform a home registration; when changing 159 foreign agent under the same GFA, the mobile node MAY instead perform 160 a regional registration within the visited domain. The proposed 161 regional registration protocol supports one level of foreign agent 162 hierarchy beneath the GFA, but the protocol may be utilized to 163 support several levels of hierarchy, as discussed in Appendix B. 165 Foreign agents that support regional registrations are also required 166 to support registrations according to Mobile IPv4 [9]. If there is 167 a foreign agent address announced in the Agent Advertisement, the 168 mobile node may register that foreign agent care-of address with its 169 home agent [9]. Similarly, if the mobile node chooses not to employ 170 regional registrations, it may register a co-located care-of address 171 directly with its home agent, according to [9]. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [2]. 179 This document uses the following terms: 181 Critical type 182 A type value for an extension in the range 0-127, which 183 indicates that the extension MUST either be known to the 184 recipient, or that the message containing the extension 185 MUST be rejected. In other words, an extension with a 186 critical type value is non-skippable. 188 Domain A collection of networks sharing a common network 189 administration. 191 Foreign Agent (FA) 192 As defined in [9]. 194 Gateway Foreign Agent (GFA) 195 A Foreign Agent which has a publicly routable IP address. 196 A GFA may, for instance, be placed in or near a firewall. 198 Home Agent (HA) 199 As defined in [9]. 201 Home domain 202 The domain where the home network and home agent are 203 located. 205 Home network 206 As defined in [9]. 208 Home Registration 209 A registration, processed by the home agent and the GFA, 210 using the specification in [9] possibly with additional 211 extensions defined in this document. 213 Local Care-of Address 214 A Care-of Address which is either assigned to a mobile 215 node, or to a foreign agent offering local connectivity 216 to a mobile node. A registration message from the mobile 217 node is subsequently sent to a GFA (or another RFA, see 218 Appendix B) via the local care-of address. 220 Mobile Node (MN) 221 As defined in [9]. 223 Mobility Agent (MA) 224 As defined in [9]. 226 Network Access Identifier(NAI) 227 Some features of this protocol specification rely on use 228 of the Network Access Identifier (NAI) [3]. 230 Regional Foreign Agent (RFA) 231 A Foreign Agent which may be the target of a request for 232 regional registration. 234 Regional Registration 235 A mobile node performs registration locally at the 236 visited domain, by sending a Regional Registration 237 Request to a GFA, and receiving a Regional Registration 238 Reply in return. 240 Registration Key 241 A key used by mobile nodes and mobility agents to secure 242 certain signals and control messages specified by Mobile 243 IP. 245 Visited domain 246 The domain where the visited network, the current foreign 247 agent and the GFA are located. 249 Visited network 250 As defined in [9]. 252 3. Description of the Protocol 254 This section provides an overview of the regional registration 255 protocol. 257 3.1. General Assumptions 259 Our general model of operation is illustrated in figure 1, showing a 260 visited domain with foreign agent and GFA, and a home network with a 261 home agent. 263 +---------------------------+ +----------------+ 264 | Visited Domain | | Home | 265 | | +---------+ | Network | 266 | | | | | | 267 | +------+ +-------+ | | Public | | +------+ | 268 | | FA |------| GFA |-------------------------| HA | | 269 | +--+---+ +-------+ | | Network | | +------+ | 270 | | | | | | | 271 +-----|---------------------+ +---------+ +----------------+ 272 | 273 +--+---+ 274 | MN | 275 +------+ 277 Figure 1: Visited domain with a GFA, and a home network with HA. 279 For mobile nodes that cannot process a NAI, or with mobility agents 280 that are not configured to advertise their NAI, regional registration 281 is still useful, but the lack of certain features may result in less 282 than optimal results. 284 3.1.1. Visited Domain 286 We assume two hierarchy levels of foreign agents in the visited 287 domain. At the top level of the hierarchy, there is at least one 288 GFA, which is a foreign agent with additional features. A GFA 289 must have a publicly routable address. Beneath a GFA, there are 290 one or more regional foreign agents (RFAs). We assume that there 291 exist established security associations between a GFA and the 292 RFAs beneath it. Multiple hierarchy levels of foreign agents are 293 discussed in Appendix B. When designing a domain supporting regional 294 registrations, the RFAs and GFA must be compatible. That is, they 295 should support the same encapsulation types, compression mechanisms 296 etc. 298 When a mobile node changes care-of address under the same GFA, it MAY 299 perform a regional registration. If the mobile node changes GFA, 300 within a visited domain or between visited domains, it MUST perform a 301 home registration. 303 3.1.2. Authentication 305 With the regional registration protocol, a GFA address is registered 306 at the home agent as the care-of address of the mobile node. If a 307 Mobile-Foreign Authentication extension is present in a Registration 308 Request message directed to the home agent, the GFA will perform 309 the authentication. Similarly, if a Foreign-Home Authentication 310 extension is present in a Registration Request message, the 311 authentication is performed between the GFA and the home agent. 313 Regional Registration messages also have to be protected with 314 authentication extensions in the same way as registrations with the 315 home agent. This means that the mobile node and the GFA MUST have 316 received the keys needed to construct the authentication extensions 317 before any Regional Registration is performed. When the regional 318 registration protocol is employed, the GFA is the agent within 319 the visited domain which receives the registration keys. This is 320 because the GFA address is the registered care-of address of the 321 mobile node at its home network. The distributed registration 322 keys are subsequently used to enable proper authentication for 323 regional registrations (see sections 9.1 and 9.2). How the keys 324 are distributed is outside the scope of this draft. One example is 325 that the keys are distributed as part of the registration at the 326 home network, for example according to [4, 11]. Another example is 327 pre-configured keys. 329 3.2. Protocol Overview 331 When a mobile node first arrives at a visited domain, it performs a 332 registration with its home network. At this registration, the home 333 agent registers the care-of address of the mobile node. In case the 334 visited domain supports regional registrations, the care-of address 335 that is registered at the home agent is the address of a GFA. The GFA 336 keeps a visitor list of all the mobile nodes currently registered 337 with it. 339 Since the care-of address registered at the home agent is the GFA 340 address, it will not change when the mobile node changes foreign 341 agent under the same GFA. Thus, the home agent does not need to be 342 informed of any further mobile node movements within the visited 343 domain. 345 Figure 2 illustrates the signaling message flow for registration 346 with the home network. After the registration at the home agent, 347 the home agent records the GFA address as the care-of address of the 348 mobile node. If the GFA address was dynamically assigned to the 349 mobile node, the Registration Reply has an extension indicating the 350 IP address of the GFA to the mobile node. 352 Figure 3 illustrates the signaling message flow for regional 353 registration. Even though the mobile node's local care-of address 354 changes, the home agent continues to record the GFA address as the 355 MN FA1 GFA HA 356 | | | | 357 | Registration Request | | | 358 |---------------------->| Reg. Request w/ext. | | 359 | |---------------------->| Reg. Request | 360 | | |--------------->| 361 | | | Reg. Reply | 362 | | Reg. Reply w/ext. |<---------------| 363 | Registration Reply |<----------------------| | 364 |<----------------------| | | 365 | | | | 367 Figure 2: Registration at the GFA and the home agent. 369 MN FA2 GFA HA 370 | | | | 371 | Regional Reg. Req. | | | 372 |---------------------->| Regional Reg. Req. w/ext. | | 373 | |----------------------------->| | 374 | | Regional Reg. Reply w/ext. | | 375 | Regional Reg. Reply |<-----------------------------| | 376 |<----------------------| | | 377 | | | | 379 Figure 3: Regional registration at the GFA. 381 care-of address of the mobile node. We introduce two new message 382 types for regional registrations: Regional Registration Request and 383 Regional Registration Reply. 385 3.3. Advertising Foreign Agent and GFA 387 A foreign agent typically announces its presence via an Agent 388 Advertisement message [9]. If the domain to which a foreign agent 389 belongs supports regional registrations, the following changes are 390 applied to the Agent Advertisement message. 392 The `I' flag (see Section 7) MUST be set to indicate that the domain 393 supports regional tunnel management. If the `I' flag is set, there 394 MUST be at least one care-of address in the Agent Advertisement 395 message, but that address MAY be set to the ``all ones'' address. If 396 the `I' flag is set, and there is only one care-of address (which is 397 not all ones), it is the address of the FA. If the `I' flag is set, 398 and there are multiple care-of addresses, the first care-of address 399 is the local FA, and the last care-of address is the GFA. The FA-NAI 400 (see section 7.2) SHOULD also be present to enable the mobile node 401 to decide whether or not it is in its home domain. The decision is 402 based on whether the realm part of the advertised FA-NAI matches the 403 mobile node's realm. 405 3.4. Backwards compatibility with RFC3344 407 A domain that supports Regional Registrations SHOULD also be 408 backwards compatible. If the Foreign Agent does not advertise an 409 ``all ones'' care-of address, it MUST support registrations according 410 to Mobile IPv4 as defined in RFC3344 [9]. This allows mobile nodes 411 that doesn't support Regional Registrations to register via this 412 Foreign Agent using standard Mobile IPv4. If the Foreign agent 413 advertises both its own care-of address and a GFA care-of address, 414 a mobile node that supports Regional Registrations but has a Home 415 Agent that doesn't, will still be able to make use of Regional 416 Registrations through that GFA care-of address. A Foreign Agent that 417 advertises an ``all ones'' care-of address will not be backwards 418 compatible with RFC3344. In that case, and in other cases when the 419 mobile node requests that a GFA address is dynamically assigned to 420 it by setting the care-of address in a Registration Request to zero, 421 the mobile node and its Home Agent MUST support the GFA IP address 422 extension. 424 4. Home Registration 426 This section gives a detailed description of home registration, 427 i.e., registration with the home agent (on the home network). Home 428 registration is performed when a mobile node first arrives at a 429 visited domain, when it requests a new home agent, or when it changes 430 GFA. Home registration is also performed to renew bindings which 431 would otherwise expire. 433 4.1. Mobile Node Considerations 435 Upon receipt of an Agent Advertisement message with the `I' flag set 436 and a FA-NAI extension, the mobile node compares the domain part 437 of the foreign agent NAI with the domain part of its own NAI, to 438 determine whether it is in its home domain or in a visited domain. 439 If the NAIs do not match, the mobile node MUST assume it is in a 440 foreign domain. Otherwise, if the mobile node determines that it is 441 in its home domain, it acts as defined in [9]. 443 If the mobile node determines that it is in a visited domain, it 444 SHOULD either use the advertised GFA address in the care-of address 445 field in the Registration Request message, or set this field to 446 zero to request to be assigned a GFA. If the mobile node sets the 447 care-of address to zero, the mobile node and its home agent MUST 448 support the GFA IP address extension (see section 8.1). In that 449 case, the mobile node MUST check to make sure that it receives a GFA 450 IP address extension in the Registration Reply. If the Foreign Agent 451 only advertises an ``all ones'' care-of address, it only supports 452 dynamically assigned GFA care-of address, and the mobile node MUST 453 set the care-of address in the Registration Request to zero. 455 A mobile node with a co-located care-of address might also want 456 to use Regional Registrations. It then finds out the address of 457 a GFA, either from Agent Advertisements sent by a Foreign Agent, 458 or by some means not described in this draft. The mobile node MAY 459 then generate a Registration Request message, with the GFA address 460 in the care-of address field, and send it directly to the GFA (not 461 via a foreign agent). In this case, the mobile node MUST add a 462 Hierarchical Foreign Agent extension 8.2, including its co-located 463 care-of address, to the Registration Request before sending it. 464 The Hierarchical Foreign Agent extension MUST be protected by an 465 authentication extension. If the mobile node has established a 466 mobility security association with the GFA, the Hierarchical Foreign 467 Agent extension SHOULD be placed after the MN-HA authentication 468 extension and before the MN-FA authentication extension. Otherwise 469 the Hierarchical Foreign Agent extension MUST be placed before the 470 MN-HA authentication extension. 472 If the mobile node receives an Agent Advertisement with the `R' bit 473 set it, even if it has a co-located care-of address, still formulates 474 the same Registration Request message with extensions, but it sends 475 the message to the advertising foreign agent instead of to the GFA. 477 If the home registration is about to expire, the mobile node performs 478 a new home registration using the same GFA care-of address to refresh 479 the binding [9]. If the mobile node has just moved to a new Foreign 480 Agent and not yet sent a Regional Registration Request when the home 481 registration is due to expire, the mobile node sends only a home 482 Registration Request, as this will update both the GFA and the HA. 483 This Registration Request MUST be constructed as if it was the first 484 registration in this domain. For example, if the new Foreign Agent 485 only advertises an `all ones' care-of address, the mobile node MUST 486 set the care-of address in the Registration Request to zero, to avoid 487 problems if this new Foregin Agent doesn't support the same GFA as 488 the mobile node had before. 490 If the Registration Replay includes a Replay Protection Style 491 extension, the value in the Initial Identification field is the value 492 to be used for replay protection in the next Regional Registration 493 Request (see section 5.1). 495 4.2. Foreign Agent Considerations 497 When the foreign agent receives a Registration Request message 498 from a mobile node, it extracts the care-of address field in the 499 Registration Request message, to find the GFA to which the message 500 shall be relayed. All Foreign Agents that advertise the `I' flag 501 MUST also be able to handle Registration Requests with a zero care-of 502 address. If the care-of address field is set to zero, the foreign 503 agent assigns a GFA to the mobile node. A Foreign Agent can either 504 have a default GFA that it assigns to all mobile nodes or it can 505 assign a GFA by some means not described in this specification. 507 If the Foreign Agent receives a Registration request where the 508 care-of address is set to ``all ones''(which could happen if a mobile 509 node that doesn't support Regional Registrations copied an ``all 510 ones'' care-of address from an Agent Advertisement), it must reply 511 with the Code field set to ``poorly formed Request'' [9]. 513 If the Registration Request has the `T' bit set, the mobile node is 514 requesting Reverse Tunneling [8]. In this case, the foreign agent 515 has to tunnel packets from the mobile node to the GFA for further 516 handling. 518 If the care-of address in the Registration Request is the address of 519 the foreign agent, the foreign agent relays the message directly to 520 the home agent, as described in [9]. For each pending or current 521 home registration, the foreign agent maintains a visitor list entry 522 as described in [9]. If reverse tunneling is being used, the visitor 523 list MUST, in addition to the fields required in [9], contain the 524 address of the GFA. 526 Otherwise, if the care-of address in the Registration Request 527 is the address of a GFA (or zero), the foreign agent adds a 528 Hierarchical Foreign Agent extension, including its own address, 529 to the Registration Request message, and relays it to the GFA. The 530 Hierarchical Foreign Agent extension MUST be appended at the end 531 of all previous extensions that were included in the Registration 532 Request message when the foreign agent received it, and it SHOULD be 533 protected by an FA-FA Authentication extension (see section 10). 535 4.3. GFA Considerations 537 For each pending or current home registration, the GFA maintains a 538 visitor list entry as described in [9]. This visitor list entry is 539 also updated for the regional registrations performed by the mobile 540 node. In addition to the fields required in [9], the list entry MUST 541 contain: 543 - the current care-of address of the mobile node (i.e., the foreign 544 agent or co-located address) in the Hierarchical Foreign Agent 545 extension 546 - the remaining Lifetime of the regional registration 547 - the style of replay protection in use for the regional 548 registration 549 - the Identification value for the regional registration. 551 The default replay protection style for Regional Registrations is 552 timestamp-based replay protection, as defined in Mobile IPv4 [9]. 553 If the timestamp sent by the mobile node in the Registration 554 Request is not close enough to the GFA's time of day clock, the GFA 555 adds a Replay Protection Style extension (see section 8.3) to the 556 Registration Reply, with the GFAs time of day in the Identification 557 field to synchronize the mobile node with the GFA for the Regional 558 Registrations. If nonce based reply protection is used, the GFA adds 559 a Replay Protection Style extension to the Registration Reply, where 560 the high-order 32 bits in the Identification fields is the nonce 561 that should be used by the mobile node in the following Regional 562 Registration. 564 If the Registration Request message contains a Replay Protection 565 extension (see section 8.3) requesting a style of replay protection 566 not supported by the GFA, the GFA MUST reject the Registration 567 Request and send a Registration Reply with the value in the Code 568 field set to REPLAY_PROT_UNAVAIL (see section 8.4). 570 If the care-of address field of the Registration Request is set 571 to zero, the GFA assigns a GFA care-of address for this Mobile 572 Node, and adds a GFA IP Address extension with this address of 573 to the Registration Request message. The GFA MUST NOT insert 574 the GFA address directly in the care-of address field in the 575 Registration Request message, since that would cause the Mobile-Home 576 authentication to fail. 578 The GFA IP Address extension has to be protected so that it can't 579 be changed by a malicious node when the Registration Request is 580 forwarded to the HA. If the HA and the GFA have a mobility security 581 association, the GFA IP Address extension MUST be protected by the 582 HA-FA authentication extension. Otherwise the Registration Request 583 MUST be sent to the HA in a secure way, for example via a secure AAA 584 protocol (see e.g. [4, 11]). 586 If the Hierarchical Foreign Agent extension comes after the 587 MN-FA authentication extension, the GFA MUST remove it from the 588 Registration Request message. The GFA then sends the request to the 589 home agent. Upon receipt of the Registration Reply message, the GFA 590 consults its pending registration record to find the care-of address 591 within its domain that is currently used by the mobile node, and 592 sends the Registration Reply to that care-of address. 594 If the Replay extension (see section 8.3) is present in a home 595 registration, and follows the MN-HA authentication extension, the GFA 596 SHOULD remove the Replay extension after performing any necessary 597 processing, before sending the home registration to the home agent. 599 If the GFA receives a Registration Request from a mobile node that it 600 already has a mobility binding for, this is an update of a binding 601 that is about to expire. If the address in the Hierarchical Foreign 602 Agent extension is the same as the current care-of address in the 603 visitor list for the mobile node, the entries in the visitor list 604 concerning regional registrations are not changed, except to update 605 the lifetime. If the address in the Hierarchical Foreign Agent 606 extension is a new address, the values for the regional registration 607 are updated. 609 If the Registration request has the 'T' bit set, the GFA has to 610 decapsulate the packets from the foreign agent and re-encapsulate 611 them for further delivery back to the home agent. These actions are 612 required because the home agent has to receive such packets from the 613 expected care-of address (i.e., that of the GFA) instead of the local 614 care-of address (that of the FA). 616 4.4. Home Agent Considerations 618 A Registration Request that does not contain a GFA IP Address 619 extension is processed by the home agent as described in [9]. If 620 the home agent receives a Registration Request with this extension, 621 and the home agent does not support the extension, the home 622 agent must return a Registration Reply with the Code value set to 623 ZERO_COA_NOT_SUPP 8.4 . If a home agent receives a Registration 624 Request message with the care-of address set to zero, and a GFA 625 IP Address extension, it MUST register the IP address of the GFA 626 as the care-of address of the mobile node in its mobility binding 627 list. If the Registration Request is accepted, the home agent MUST 628 include the GFA IP Address extension in the Registration Reply, 629 before the Mobile-Home Authentication extension. If a home agent 630 receives a Registration Request message with the care-of address set 631 to zero, but no GFA IP Address extension, it MUST deny the request 632 by sending a Registration Reply message with the Code field set to 633 ZERO_CAREOF_ADDRESS (see section 8.4). Otherwise, the home agent 634 then generates a Registration Reply message, including the GFA IP 635 Address extension, and sends it back to the GFA. 637 5. Regional Registration 639 This section describes in detail regional registration. Once the 640 home agent has registered the GFA address as the care-of address of 641 the mobile node, the mobile node may perform regional registrations. 642 When performing regional registrations, the mobile node may either 643 register a foreign agent care-of address or a co-located address with 644 the GFA (or, another RFA -- see Appendix B). In the following, we 645 assume that a home registration has already occurred, as described in 646 section 4, and that the GFA has a mobility security association with 647 the mobile node. 649 Suppose the mobile node moves from one foreign agent to another 650 foreign agent within the same visited domain. It will then receive 651 an Agent Advertisement from the new foreign agent. Suppose further 652 that the Agent Advertisement indicates that the visited domain 653 supports regional registrations, and that either the advertised GFA 654 address is the same as the one the mobile node has registered as its 655 care-of address during its last home registration, or the realm part 656 of the newly advertised FA-NAI matches the FA-NAI advertised by the 657 mobile node's previous foreign agent. Then, the mobile node can 658 perform a regional registration with this foreign agent and GFA. The 659 mobile node issues a Regional Registration Request message to the GFA 660 via the new foreign agent. The request is authenticated using the 661 registration key that was distributed to the GFA and to the mobile 662 node from the home network and the message is authenticated by the 663 MN-GFA Authentication Extension. The care-of address should be set 664 to the address of the local foreign agent, or else zero if the local 665 foreign agent is not advertising its own care-of address. 667 If the Regional Registration Request does not contain its care-of 668 address, the foreign agent adds a Hierarchical Foreign Agent 669 extension to the message and relays it to the GFA. Based on the 670 information in the Hierarchical Foreign Agent extension, the GFA 671 updates the mobile node's current point of attachment in its visitor 672 list. The GFA then issues a Regional Registration Reply to the 673 mobile node via the foreign agent. 675 If the advertised GFA is not the same as the one the mobile node has 676 registered as its care-of address, and if the mobile node is still 677 within the same domain as it was when it registered that care-of 678 address, the mobile node MAY try to perform a regional registration 679 with its registered GFA. If the foreign agent cannot support 680 regional registration to a GFA, other than advertised, the foreign 681 agent denies the regional registration with code UNKNOWN_GFA (see 682 section 9.3). In this case the MN has to do a new home registration 683 via the new GFA. 685 It is essential for the mobile node to distinguish regional 686 registrations from home registrations, since in the former case the 687 nonces are not synchronized with its home agent. Furthermore, a 688 home registration MUST be directed to the home network before the 689 lifetime of the GFA's regional care-of address expires. Since the 690 mobile node can use a zero Care-of Address either to request a GFA 691 (in a home registration) or to signify the use of an unspecified 692 (perhaps privately addressed) RFA (in a regional registration), 693 it is necessary to distinguish regional registrations from home 694 registration. Thus, we introduce new message types for the Regional 695 Registration messages. 697 5.1. Mobile Node Considerations 699 For each pending or current home registration, the mobile node 700 maintains the information described in [9]. The information is also 701 updated for the regional registrations performed by the mobile node. 702 In addition to the information described in [9], the mobile node MUST 703 maintain the following information, if present: 705 - the GFA address 706 - the style of replay protection in use for the regional 707 registration 708 - the Identification value for the regional registration. 710 The replay protection for registrations and regional registrations 711 is performed as described in [9]. Since the mobile node performs 712 regional registrations at the GFA in parallel with registrations at 713 its home network, the mobile node MUST be able to keep one replay 714 protection mechanism and sequence for the GFA, and a separate 715 mechanism and sequence for the home agent. 717 For regional registrations, replay protection may also be provided at 718 the foreign agent by the challenge-response mechanism, as described 719 in [5]. In this case, the mobile node inserts the 64 bit response 720 value (timestamp or nonce, according to Mobile IPv4 [9]) in the 721 Identification field in the Regional Registration Request. Thus, 722 the GFA SHOULD expect such an Identification field. When a mobile 723 node, which has already registered a GFA care-of address with its 724 home agent, changes foreign agent within the same domain and receives 725 an Agent Advertisement which advertises another GFA address, it MAY 726 still generate a Regional Registration Request message destined to 727 its old GFA. 729 5.2. Foreign Agent Considerations 731 When the foreign agent receives a Regional Registration Request 732 message from a mobile node, addressed to a GFA, it processes the 733 message generally according to the rules of processing a Registration 734 Request message addressed to a home agent (see section 4.2). The 735 only difference is that the GFA IP address field replaces the home 736 agent address field. If that address belongs to a known GFA, the 737 foreign agent forwards the request to the indicated GFA. Otherwise, 738 the foreign agent MUST generate a Regional Registration Reply with 739 error code UNKNOWN_GFA. 741 For each pending or current registration, the foreign agent maintains 742 a visitor list entry as described in [9]. If reverse tunneling is 743 being used, the visitor list MUST contain the address of the GFA, in 744 addition to the fields required in [9]. This is required so that the 745 foreign agent can tunnel datagrams, sent by the mobile node, to the 746 GFA. The GFA then decapsulates the datagrams, re-encapsulates them 747 and sends them to the home agent. 749 5.3. GFA Considerations 751 If the GFA accepts a request for regional registration, it MUST set 752 the lifetime to be no greater than the remaining lifetime of the 753 mobile node's registration with its home agent, and put this lifetime 754 into the corresponding Regional Registration Reply. The GFA MUST NOT 755 accept a request for a regional registration if the lifetime of the 756 mobile node's registration with its home agent has expired. In that 757 case the GFA sends a Regional Registration Reply with the value in 758 the Code field set to NO_HOME_REG. 760 If the GFA receives a tunneled packet from a foreign agent in its 761 domain, then after decapsulation the GFA looks to see whether it has 762 an entry in its visitor list for the source IP address of the inner 763 IP header after decapsulation. If so, then it checks the visitor 764 list to see whether reverse tunneling has been requested; if it was 765 requested, the GFA re-encapsulates the packet with its own address 766 as the source IP address, and the address of the home agent as the 767 destination IP address. 769 6. Generalized NAI Extension 771 The revised specification for "IP Mobility Support for IPv4" [9] 772 defines a new extension header format, that is intended to extend 773 the Mobile IP extension address space. The use of a Network Access 774 Identifier (NAI) [1] for mobile nodes is specified for Mobile IPv4 775 in [3]. The Generalized NAI (GNAI) extension, defined in this 776 section, uses the new extension header format to extend this idea, 777 enabling NAIs to be used for identifying IPv4 mobility agents (i.e., 778 the Foreign Agent or the Home agent) or other possible network 779 elements that may be involved with the processing of Registration 780 Requests. For Regional Registration, only a single sub-type is 781 defined; it is used to carry a Foreign Agent's NAI (see section 7.2). 783 The GNAI extension, illustrated in figure 4, may be carried by 784 Registration Request and Reply messages. 786 0 1 2 3 787 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 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Type | Length | Sub-Type | NAI ... 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Figure 4: The Generalized NAI (GNAI) Extension 794 Type (Type to be assigned by IANA) (skippable) 796 Length 8-bit unsigned integer. Length of the extension, 797 in octets, excluding the extension Type and 798 the extension Length fields, but including the 799 Sub-Type field and the variable length NAI field. 801 Sub-Type 8-bit unsigned integer identifying the specific 802 sub-type of the GNAI extension, and thus be 803 implication the type of the entity which is to be 804 identified by using the NAI. 806 NAI A string containing the Network Access Identifier 807 NAI in the format prescribed in [1]. 809 When a mobile node or home agent adds a GNAI extension to a 810 registration message, the extension MUST appear prior to any 811 authentication extensions. 813 When the Foreign Agent adds an GNAI extension to a registration 814 message, the extension MUST appear prior to any authentication 815 extensions added by the FA. 817 7. Router Discovery Extensions 819 This section specifies a new flag within the Mobile IP Agent 820 Advertisement, and an optional extension to the ICMP Router Discovery 821 Protocol [6]. 823 7.1. Regional Registration Flag 825 The only change to the Mobility Agent Advertisement Extension 826 defined in [9] is a flag indicating that the domain, to which the 827 foreign agent generating the Agent Advertisement belongs, supports 828 regional registrations. The flag is inserted after the flags defined 829 in [9], [8] and [10]. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Type | Length | Sequence Number | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Lifetime |R|B|H|F|M|G|V|T|S|I| reserved | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | zero or more Care-of Addresses | 839 | ... | 841 The flag is defined as follows: 843 I Regional registration. This domain supports Regional 844 Registration as specified in this document. 846 7.2. Foreign Agent NAI Extension 848 The FA-NAI extension is defined as a subtype 4 of the Generalized NAI 849 Extension (GNAIE) (see section 6). 851 The foreign agent SHOULD include its NAI in the Agent Advertisement 852 message. If present, the Foreign Agent NAI (FA-NAI) extension 853 MUST appear in the Agent Advertisement message after any of the 854 advertisement extensions defined in [9]. 856 By comparing the domain part of the foreign agent NAI with the domain 857 part of its own NAI, the mobile node can determine whether it is in 858 its home domain or in a visited domain, and whether it has changed 859 domain since it last registered. 861 8. Regional Extensions to Mobile IPv4 Registration Messages 863 In this section we specify new Mobile IP registration extensions for 864 the purpose of managing regional registrations. 866 8.1. GFA IP Address Extension 868 If the mobile node requests a dynamically assigned GFA, the GFA 869 adds a GFA IP Address extension to the Registration Request before 870 relaying it to the HA. The mobile node indicates that it wants a GFA 871 to be assigned by sending a Registration Request message with the 872 care-of address field set to zero. The GFA IP Address extension MUST 873 appear in the Registration Request message before the Foreign-Home 874 Authentication extension, if present. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Type | Length | GFA IP Address .... 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 GFA IP Address | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Figure 5: The GFA IP Address extension 886 If a home agent receives a Registration Request message with the 887 care-of address set to zero, and a GFA IP Address extension, it MUST 888 register the IP address of the GFA as the care-of address of the 889 mobile node. When generating a Registration Reply message, the home 890 agent MUST include the GFA IP Address extension from the Registration 891 Request in the Registration Reply message. The GFA IP Address 892 extension MUST appear in the Registration Reply message before the 893 Mobile-Home Authentication extension. 895 The GFA IP Address extension, illustrated in figure 5 is defined as 896 follows: 898 Type TBD (GFA IP Address) 900 Length 4 902 GFA IP Address The GFA IP Address field contains the Gateway 903 Foreign Agent's publicly routable address. 905 8.2. Hierarchical Foreign Agent Extension 907 The Hierarchical Foreign Agent extension may be present in a 908 Registration Request or Regional Registration Request message. When 909 this extension is added to a Registration Request by a foreign 910 agent, the receiving mobility agent sets up a pending registration 911 record for the mobile node, using the IP address in the Hierarchical 912 Foreign Agent extension as the care-of address for the mobile 913 node. Furthermore, in this case, the extension MUST be appended 914 at the end of all previous extensions that had been included in 915 the registration message as received by the foreign agent. The 916 Hierarchical Foreign Agent extension SHOULD be protected by an FA-FA 917 Authentication extension. When the receiving foreign agent receives 918 the registration message, it MUST remove the Hierarchical Foreign 919 Agent extension added by the sending foreign agent. 921 The Hierarchical Foreign Agent extension is defined as follows: 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type | Length | FA IP Address .... 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 FA IP Address .... | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Figure 6: The Hierarchical Foreign Agent Extension 933 Type TBD (Hierarchical Foreign Agent) 935 Length 4 937 FA IP Address The IP Address of the foreign agent relaying 938 the Registration Request. 940 8.3. Replay Protection Style 942 When a mobile node uses Mobile IP to register a care-of address 943 with its home agent, the style of replay protection used for the 944 registration messages is assumed to be known by way of a Mobility 945 Security Association that is required to exist between the mobile 946 node and the home agent receiving the request. No such pre-existing 947 security association between the mobile node and the GFA is likely 948 to be available. By default, the mobile node SHOULD treat replay 949 protection for Regional Registration messages exactly as specified in 950 Mobile IPv4 [9] for timestamp-based replay protection. 952 If the mobile node requires nonce-based replay protection, also 953 as specified in Mobile IPv4, it MAY append a Replay Protection 954 extension to a home registration message. Since home registrations 955 are forwarded to the home agent by way of the GFA, the GFA will be 956 able to establish the selected replay protection (see section 4.3). 958 The GFA also uses this extension by adding a Replay Protection 959 Style extension to a Registration Reply to synchronize the replay 960 protection for Regional registrations (see section 4.3). 962 The format of this extension is shown in figure 7. 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Type | Length | Replay Protection Style | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | | 970 + Initial Identification + 971 | | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 Figure 7: The Replay Protection Extension 976 Type TBD (Replay Protection Style) 978 Length 2 980 Replay Protection Style 981 An integer specifying the style of replay protection 982 desired by the mobile node. 984 Initial Identification 985 The timestamp or nonce to be used for initial 986 synchronization for the replay mechanism. 988 Admissible values for the Replay Protection Style are as follows: 990 Value Replay Protection Style 991 ----- ----------------------- 992 0 timestamp [9] 993 1 nonce [9] 995 The Replay Protection Style extension MUST be protected by an 996 authentication extension. If the mobile node has an established 997 mobility security association with the GFA, the Replay Protection 998 Style extension SHOULD be placed after the MN-HA authentication 999 extension and before the MN-FA authentication extension. Otherwise 1000 the Replay Protection Style extension MUST be placed before the MN-HA 1001 authentication extension. 1003 Replay protection MAY also be provided through a challenge-response 1004 mechanism, at the foreign agent issuing the Agent Advertisement, as 1005 described in [5]. 1007 8.4. New Code Values for Registration Reply 1009 The values to use within the Code field of the Registration Reply are 1010 defined in [9]. In addition, the following values are defined: 1012 Registration denied by the FA: 1013 Error Name Value Section of Document 1014 ---------------------- ----- ------------------- 1015 SMOOTH_HO_REQUIRED TBD B.4 1017 Registration denied by the GFA: 1019 Error Name Value Section of Document 1020 ---------------------- ----- ------------------- 1021 REPLAY_PROT_UNAVAIL TBD 8.3 1022 GFA_ID_MISMATCH TBD 4.3 1024 Registration denied by the HA: 1026 Error Name Value Section of Document 1027 ---------------------- ----- ------------------- 1028 ZERO_CAREOF_ADDRESS TBD 4.4 1029 ZERO_COA_NOT_SUPP TBD 4.4 1031 9. Regional Registration Message Formats 1033 This section specifies two new registration message types: Regional 1034 Registration Request and Regional Registration Reply. These messages 1035 are used by the mobile node instead of the existing Registration 1036 Request and Registration Reply, in order to make registration work 1037 faster, and also to reduce network load for Mobile IP registration, 1038 as described in section 5. 1040 Regional registration messages are protected by requiring 1041 authentication extensions, in the same way as the existing Mobile IP 1042 registration messages are protected. The following rules apply to 1043 authentication extensions: 1045 - The Mobile-GFA Authentication extension [9] MUST be included in 1046 all regional registration messages. 1047 - The Mobile-Foreign Authentication extension [9] MAY be included 1048 in regional registration messages. 1049 - The Foreign-Home Authentication extension [9] MUST NOT be 1050 included in any regional registration message. 1052 9.1. Regional Registration Request 1054 The Regional Registration Request, illustrated below, is used by a 1055 mobile node to register with its current GFA. 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Type |S|B|D|M|G|r|T|x| Lifetime | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Home Address | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | GFA IP Address | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Care-of Address | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | | 1069 + Identification + 1070 | | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Extensions ... 1073 +-+-+-+-+-+-+-+- 1075 The Regional Registration Request message is defined as the 1076 Registration Request message in [9], but with the following changes: 1078 Type TBD (Regional Registration Request) 1080 GFA IP Address 1081 The IP address of the Gateway Foreign Agent. (Replaces 1082 Home Agent field in Registration Request message 1083 in [9].) 1085 Care-of Address 1086 Care-of address of local foreign agent; MAY be set to 1087 all ones. 1089 Extensions 1091 For the Regional Registration Request, the Hierarchical Foreign Agent 1092 Extension is also an allowable extension in addition to those which 1093 are allowable for the Registration Request message. 1095 9.2. Regional Registration Reply 1097 The Regional Registration Reply message, illustrated below, delivers 1098 the indication of regional registration acceptance or denial to a 1099 mobile node. The UDP header is followed by the Mobile IP fields 1100 shown below: 1102 0 1 2 3 1103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Type | Code | Lifetime | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Home Address | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Regional FA IP Address | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | | 1112 + Identification + 1113 | | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Extensions ... 1116 +-+-+-+-+-+-+-+- 1118 This message is defined as the Registration Reply message in [9], but 1119 with the following changes: 1121 Type TBD (Regional Registration Reply) 1123 Regional FA IP Address 1124 The IP address of the Gateway Foreign Agent. (Replaces 1125 Home Agent field specified in Mobile IPv4 [9]). 1127 Extensions 1129 The Regional FA IP Address is the address of the regional foreign 1130 agent generating the Regional Registration Reply message. For the 1131 two-level hierarchy specified here, it is the address of the GFA. For 1132 more levels of hierarchy, it may be the address of an intermediate 1133 RFA. 1135 9.3. New Regional Registration Reply Code Values 1137 For a Regional Registration Reply, the following additional Code 1138 values are defined in addition to those specified in Mobile IPv4 [9]. 1140 Registration denied by the FA: 1142 Error Name Value Section of Document 1143 ---------------------- ----- ------------------- 1144 UNKNOWN_GFA TBD 5.2 1145 GFA_UNREACHABLE TBD 1146 GFA_HOST_UNREACHABLE TBD 1147 GFA_PORT_UNREACHABLE TBD 1148 SMOOTH_HO_REQUIRED TBD B.4 1150 Registration denied by the GFA: 1152 Error Name Value Section of Document 1153 ---------------------- ----- ------------------- 1154 NO_HOME_REG TBD 5.3 1156 The four first Code values are returned to the mobile node in 1157 response to ICMP errors that may be received by the foreign agent. 1159 10. Authentication Extensions 1161 In this section, two new subtypes for the Generalized Authentication 1162 Extension [5] are specified. First, the FA-FA Authentication 1163 extension is used by regional foreign agents to secure the 1164 Hierarchical Foreign Agent (HFA) extension to the Registration 1165 Request and Regional Registration Request messages. A new 1166 authentication extension is necessary because the HFA extension 1167 is typically added after the Mobile-Home (or some other 1168 authorization-enabling [9] (e.g. MN-AAA [3], see section C) 1169 authentication extension. 1171 The MN-GFA authentication extension is used whenever the mobile node 1172 has a co-located address. Furthermore, the MN-GFA extension is used 1173 to provide authentication for a Regional Registration Request. 1175 The subtype values for these new subtypes are as follows: 1177 Subtype Name Value 1178 ---------------------- ------ 1179 FA-FA authentication TBD 1180 MN-GFA authentication TBD 1182 The default algorithm for computation of the authenticator is the 1183 same as for the MN-AAA Authentication subtype defined in [5]. 1185 11. IANA considerations 1187 This document defines: 1189 - The Generalized NAI extension, specified in section 6. The type 1190 number for this new extension is to be assigned from the number 1191 space for Mobile IPv4 skippable extensions (128-255). 1193 - A Sub-Type for the GNAI extension is specified in section 7.2, 1194 which needs to have a value assigned from the space of GNAI 1195 subtypes. 1197 - Three new extensions to Mobile IP Registration messages: GFA IP 1198 Address, Hierarchical Foreign Agent, and Replay Protection Style 1199 (see section 8.1, 8.2 and 8.3). The Type values for the GFA IP 1200 Address extension must be within the range 0 through 127, while 1201 the other two must be within the range 128 through 255. 1203 - New Code values for Registration Reply messages (see 1204 section 8.4). 1206 - Two new subtypes for the Generalized Authentication 1207 Extension [5]; see section 10 1209 - Two new message types for Mobile IP: Regional Registration 1210 Request and Regional Registration Reply (see section 9.1 1211 and 9.2). 1213 - Code values for Regional Registration Reply messages (see section 1214 9.3) 1216 12. Security Considerations 1218 This document proposes a method for a mobile node to register locally 1219 in a visited domain. The authentication extensions to be used are 1220 those defined either in [9], [10], or [4]. Key distribution is to be 1221 performed, for instance, according to [4], or [11]. 1223 If the Hierarchical Foreign Agent (HFA) extension is appended to a 1224 Registration Request message, that extension is to be followed by 1225 an FA-FA Authentication Extension (see section 10) to prevent any 1226 modification to the data. Likewise, if the GFA IP Address extension 1227 is added to such a message, it is to be followed by an authentication 1228 extension. 1230 13. Acknowledgements 1232 This document is a logical successor to documents written with Pat 1233 Calhoun and Gabriel Montenegro; thanks to them and their many efforts 1234 to help explore this problem space. Many thanks also to Jari Malinen 1235 at the Nokia Research Center for his commentary on a rough version of 1236 this document, and providing motivation for section B.4. 1238 The text in section 6 was taken directly from a previous Internet 1239 Draft [7] written by Mohamed M. Khalil, Emad Qaddoura, Haseeb 1240 Akhtar of Nortel Networks, along with Pat R. Calhoun of Black Storm 1241 Networks. 1243 References 1245 [1] B. Aboba and M. Beadles. The Network Access Identifier. 1246 Request for Comments (Proposed Standard) 2486, Internet 1247 Engineering Task Force, January 1999. 1249 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 1250 Levels. Request for Comments (Best Current Practice) 2119, 1251 Internet Engineering Task Force, March 1997. 1253 [3] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 1254 Extension for IPv4. Request for Comments (Proposed Standard) 1255 2794, Internet Engineering Task Force, January 2000. 1257 [4] P. Calhoun and C. Perkins. DIAMETER Mobile IP Extensions (work 1258 in progress). Internet Draft, Internet Engineering Task Force. 1259 draft-ietf-aaa-diameter-mobileip-06.txt, June 2001. 1261 [5] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 1262 Challenge/Response Extension. Request for Comments (Proposed 1263 Standard) 3012, Internet Engineering Task Force, December 2000. 1265 [6] S. Deering. ICMP Router Discovery Messages. Request for 1266 Comments (Proposed Standard) 1256, Internet Engineering Task 1267 Force, September 1991. 1269 [7] Mohamed Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R. 1270 Calhoun. Generalized NAI Extension (GNAIE) (work in progress). 1271 draft-ietf-mobileip-gnaie-00.txt, September 2001. 1273 [8] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 1274 Request for Comments (Proposed Standard) 3024, Internet 1275 Engineering Task Force, January 2001. 1277 [9] C. Perkins. IP Mobility Support. Request for Comments 1278 (Proposed Standard) 3344, Internet Engineering Task Force, 1279 August 2002. 1281 [10] C. Perkins and D. Johnson. Route Optimization in Mobile IP 1282 (work in progress). Internet Draft, Internet Engineering Task 1283 Force. draft-ietf-mobileip-optim-11.txt, September 2001. 1285 [11] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys 1286 for Mobile IP (work in progress). Internet Draft, Internet 1287 Engineering Task Force. 1288 draft-ietf-mobileip-aaa-key-10.txt, October 2002. 1290 A. Changes from Previous Versions 1292 The following updates and changes were made in this version of the 1293 Mobile IP Regional Registration draft, compared to earlier versions. 1295 A.1. Updates from version 06 1297 Updated the Abstract and Introduction. 1299 Updated section 3.1.2 1301 Backwards compatibility. Changed the Agent 1302 Advertisement, so that if only one address is 1303 advertised, it is the FA address, and not the GFA 1304 address, and instead of advertising a zero care-of 1305 address for dynamic allocation of GFA address, it is 1306 an `all ones' address. Added section 3.4. 1308 Added the Code `ZERO_COA_NOT_SUPP' for Registration 1309 Replies. 1311 Let the GFA add the GFA IP Address extension to a 1312 Registration Request, instead of the FA, i.e. moved 1313 text from section 4.2 to section 4.3 and updated 1314 section 8.1. 1316 Clarified how home registrations that are about 1317 to expire should be handled in section 4.1 and 1318 section 4.3. 1320 Clarified how authentication extensions should be 1321 used in section 4.1 and section 8.3. 1323 Changed the Reply Code HOME_REG_EXPIRED to 1324 NO_HOME_REG, since when the registration has expired, 1325 the binding is removed, and the GFA doesn't know if a 1326 binding for this mobile node has ever existed. 1328 Clarified that the GFA IP address extension must be 1329 protected when the Registration Request is sent to 1330 the HA in section 4.3. 1332 Added a way for the GFA to synchronize the replay 1333 protection with the mobile node for Regional 1334 registrations in sections 4.3, 8.3, and 8.4. 1336 Clarified the use of Binding Updates for multiple 1337 hierarchies in section B.2 and B.3. 1339 Upgraded citations for RFC 2002 to instead refer to 1340 RFC 3344. 1342 A.2. Updates from version 05 1344 Specified the GNAI extension (see section 6, as was 1345 previously done in [7]. Changed IANA considerations 1346 and section 7.2 as needed. 1348 Upgraded citations for RFC 2002 to instead refer to 1349 RFC 3220. 1351 A.3. List of updates made for previous revisions 1353 Added `v4' to the title, changed all code values, 1354 message types and extensions to `TBD', and added an 1355 `IANA Considerations' section. 1357 Section 3.3 Clarified that the care-of address can be zero. 1359 Section 4.2 Added that any Foreign Agent that supports regional 1360 registrations must be able to assign a GFA to 1361 a mobile node if the care-of address in the 1362 Registration Request is zero. 1364 Section 5.2 Clarified that in regional registrations the GFA 1365 address field replaces the HA address field. 1367 Section 5.3 Added a new error code: HOME_REG_EXPIRED that the 1368 GFA use when denying a regional registration because 1369 the home registration lifetime has expired. 1371 Section 7.1 Clarified the placement of the 'I' flag. 1373 Section 10 Added reference to a default algorithm for the 1374 authentication extensions. 1376 Section B.5 Added a section to allow a mobile node with a 1377 co-located care of address to use multi-level 1378 hierarchies. 1380 Section B.4 Interactions with delivery of Binding Update messages 1381 to RFAs along the previous routing path have been 1382 suggested in order to prevent various race conditions 1383 that have been observed in practice. 1385 A.4. Updates from version 02 1387 The following updates and changes were made in this version of the 1388 Mobile IP Regional Registration draft, compared to the earlier 1389 version (version 02). 1391 Section 4.3 The contents of the visitor list entry at the 1392 GFA have been clarified. A GFA keeps a visitor 1393 list entry for each pending or current home 1394 registration. The entry is also updated for the 1395 regional registrations performed by the mobile 1396 node. 1398 Section 8.4 A new code value for the Registration Reply has 1399 been defined: MISSING_GFA_ADDRESS. This section 1400 has also been re-structured for clarification. 1402 Section 5.1 Specific message types for regional 1403 registrations messages (Regional Registration 1404 Request and Regional Registration Reply) were 1405 defined. The reason for defining specific 1406 message types for the regional registration 1407 messages, instead of using the Registration 1408 Request and Reply as defined in [9] are the 1409 following: 1411 - a mobile node must be able to distinguish 1412 between regional registrations and home 1413 registrations, because when it uses 1414 regional registration, the nonces are not 1415 synchronized with its home agent; 1417 - a mobile node can use a zero care-of 1418 address either to request a GFA (in a home 1419 registration) or to signify the use of an 1420 unspecified regional foreign agent (in a 1421 regional registration). 1423 For regional registrations, the 1424 challenge-response mechanism may be used 1425 to provide replay protection. In this case, the 1426 mobile node inserts the 64 bit response value 1427 in the Identification field in the Regional 1428 Registration Request. 1430 Section 7.2 The FA-NAI extension is defined as a subtype TBD 1431 of the Generalized NAI Extension (GNAIE). 1433 Section 9 This entire section is added to the draft, and 1434 it describes the Regional Registration Request 1435 and Regional Registration Reply messages. 1437 Appendix B The contents of the visitor list entry at the 1438 RFA and GFA have been clarified. An RFA/GFA 1439 keeps a visitor list entry for each pending or 1440 current home registration. The entry is also 1441 updated for the regional registrations performed 1442 by the mobile node. 1444 Appendix D This appendix has been added to the draft. It 1445 clarifies how a mobile node can register a 1446 care-of address with its home agent; a GFA, RFA 1447 or FA care-of address, and then maintain this 1448 care-of address when it moves in the visited 1449 domain. 1451 B. Hierarchical Foreign Agents 1453 The main body of this specification assumes two hierarchy levels of 1454 foreign agents in the visited domain. At the top level, there is one 1455 or several GFAs, and on the lower level, there is a number of foreign 1456 agents. The structure can be extended to include multiple hierarchy 1457 levels of foreign agents beneath the GFA level (Figure 8). Such 1458 multiple hierarchy levels are discussed in this appendix. 1460 We assume that security associations have been established among 1461 a GFA and all the foreign agents beneath it in the hierarchy. As 1462 before, we assume that when a mobile node performs registration at 1463 its home network, registration keys are generated and distributed to 1464 the mobile node and to the GFA. The GFA may then in turn distribute 1465 the registration keys to the foreign agents beneath it in the 1466 hierarchy, using methods not specified in this document. We also 1467 assume that all foreign agents and the mobile node support smooth 1468 handover as specified in [10], with some modifications as explained 1469 below. 1471 B.1. Registration with Home Agent 1473 As described in this specification, a foreign agent announces itself 1474 and a GFA in the Agent Advertisement in the first and last address 1475 in the care-of address field in the Mobility Agent Advertisement 1476 extension [9]. If there is a hierarchy of foreign agents between 1477 the GFA and the announcing foreign agent, the foreign agent MUST 1478 support smooth handover (specifically, the Previous Foreign Agent 1479 Notification extension) as described in [10]. The foreign agent MAY 1480 +--------+ 1481 | | 1482 | GFA | 1483 | | 1484 +--------+ 1485 / | \ 1486 ... ... ... 1487 | 1488 +--------+ 1489 | | 1490 | RFA3 | 1491 | | 1492 +--------+ 1493 / \ 1494 +--------+ +--------+ 1495 | | | | 1496 | FA2 | | FA1 | 1497 | | | | 1498 +--------+ +--------+ 1499 | | 1500 | +--------+ 1501 ... | | 1502 | MN | 1503 | | 1504 +--------+ 1506 Figure 8: Domain with a GFA and multiple hierarchies of FAs, enabled 1507 for regional registrations. 1509 also include the addresses of the foreign agents in the hierarchy in 1510 order between its own address (first) and the GFA address (last): 1512 - Address of announcing foreign agent 1513 - Address of the next higher-level Regional Foreign Agent (RFA) 1514 - ... 1515 - Address of GFA 1517 If a foreign agent advertises the entire hierarchy between itself and 1518 the GFA, the Registration Request messages MUST be delivered to each 1519 RFA address in turn within that hierarchy. 1521 When newly arriving at a visited domain, the mobile node sends 1522 a Registration Request, with the care-of address set to the GFA 1523 address announced in the Agent Advertisement. The mobile node may 1524 also request a GFA to be assigned, as described earlier in this 1525 specification. The registration Request MUST include the Previous 1526 Foreign Agent Notification Extension defined in [10]. The Binding 1527 Update that results is processed as described in Section B.2. 1529 When the foreign agent closest to the mobile node receives the 1530 Registration Request, processing is as described in Section 4.2. 1531 It adds a Hierarchical Foreign Agent extension to the Registration 1532 Request, including its own address, and relays the Registration 1533 Request to the next RFA in the hierarchy toward the GFA. It also 1534 constructs a Binding Update and sends it to the previous foreign 1535 agent, as defined in [10]. 1537 The next RFA receives the Registration Request. For each pending 1538 or current registration, an RFA maintains a visitor list entry. In 1539 addition to the list entry contents (described in [9]), the list 1540 entry for regional registrations MUST contain: 1542 - the address of the next lower-level RFA, or FA, in the hierarchy 1543 - the remaining Lifetime of the regional registration 1544 - the style of replay protection in use for the regional 1545 registration 1546 - the Identification value for the regional registration. 1548 The RFA removes the Hierarchical Foreign Agent extension that the 1549 last FA or RFA added, and adds a new Hierarchical Foreign Agent 1550 extension with its own address. This procedure is repeated at each 1551 RFA, or FA, in the hierarchy under the GFA. 1553 When the GFA receives the Registration Request, it removes the 1554 Hierarchical Foreign Agent extension and caches information about 1555 the next lower-level RFA in the hierarchy. It then relays the 1556 Registration Request to the home agent, possibly via AAA servers. 1558 For each pending or current home registration, the GFA maintains 1559 a visitor list entry as described in [9]. The list entry is also 1560 updated for regional registrations reaching the GFA. In addition to 1561 the list entry contents required in [9], the list entry MUST contain: 1563 - the address of the next lower-level RFA in the hierarchy 1564 - the remaining Lifetime of the regional registration 1565 - the style of replay protection in use for the regional 1566 registration 1567 - the Identification value for the regional registration. 1569 If there is only one level of hierarchy beneath the GFA, the address 1570 of the next lower-level RFA is the current care-of address of the 1571 mobile node, as stated in Section 4.3. 1573 The home agent, as described before, processes the Registration 1574 Request, stores the GFA address as the current care-of address of 1575 the mobile node, generates a Registration Reply, and sends it to the 1576 GFA. The home agent also distributes a registration key to the mobile 1577 node, perhaps with the assistance of the GFA, for instance by way of 1578 other AAA functions [11]. When the GFA receives the Registration 1579 Reply, it checks its pending Registration Request record to see which 1580 next lower-level RFA to send the Registration Reply message to. 1581 It SHOULD then add, for instance, a new FA-FA Key Reply extension 1582 to the Registration Reply message, before relaying it to the next 1583 foreign agent. The new FA-FA Agent Key Reply extension contains the 1584 registration key, encrypted with a secret shared between the GFA and 1585 the next lower-level RFA in the hierarchy. Similar procedures are to 1586 be used with [11]. 1588 The next lower-level RFA receives the Registration Reply and checks 1589 its pending Registration Request record to see which lower-level 1590 foreign agent should next receive the Registration Reply. It 1591 extracts, decrypts and caches the registration key, and relays the 1592 Registration Reply to the next foreign agent. This procedure is 1593 repeated in every foreign agent in the hierarchy, until the message 1594 reaches the foreign agent closest to the mobile node. 1596 When the lowest-level foreign agent receives the Registration Reply, 1597 it checks its cached information, as described in [9], and relays the 1598 Registration Reply to the mobile node. 1600 B.2. Handling Binding Updates 1602 Meanwhile, when the previous foreign agent receives the Binding 1603 Update, it will process it according to [10], except that instead 1604 of sending back a Binding Acknowledge message, it sends the Binding 1605 Update to the next RFA in the hierarchy towards the GFA. This is 1606 done to make sure that all RFAs in the path to the previous FA are 1607 notified that the mobile node has moved. The previous foreign agent 1608 must be sure that the next RFA received the Binding Update, therefore 1609 the RFA MUST send a Binding Acknowledge message back to the foreign 1610 agent that it got the Binding Update from. Note that this is the 1611 same Binding Acknowledge message than the one defined in [10], but 1612 this one is addressed to the IP address of the Foreign Agent that 1613 sent the Binding Update instead of to the mobile node. 1615 The RFA that received the Binding Update sends the Binding 1616 Acknowledge message back to the lower-layer Foreign Agent, and relays 1617 the Binding Update to the next RFA in the hierarchy towards the GFA. 1618 The RFA will also update the binding cache for the mobile node so 1619 that it will expire according to the lifetime in the Binding Update, 1620 but the binding cache entry will still point to the same lower-level 1621 foreign agent. 1623 The crossover FA is the foreign agent lowest in the hierarchy which 1624 is part of both the old and the new path to the mobile node. When 1625 the Binding Update reaches the crossover FA, which might be an RFA or 1626 the GFA, it will, in addition to sending a Binding Acknowledge back 1627 to the sending RFA, also send a Binding Acknowledge to the mobile 1628 node. This Binding Acknowledge message is the one defined in [10] 1629 and it is addressed to the mobile node and sent down the hierarchy 1630 via the old path and the previous Foreign Agent, who tunnels it to 1631 the new Foreign Agent. 1633 The crossover FA will receive both a Registration Request and a 1634 Binding Update for the mobile node. When the crossover FA receives 1635 the Registration Request, it continues to send traffic via the 1636 old path until it receives a valid Registration Reply with a Code 1637 indicating success. Then it starts sending traffic via the new 1638 route. 1640 In the unlikely event that the crossover FA receives the Binding 1641 Update before it receives the Registration Request, it doesn't know 1642 that it is the crossover FA yet, and therefore relays the Binding 1643 Update to the next Foreign Agent. When the crossover FA later 1644 receives the Registration Request, it will know that it is the 1645 crossover FA, and will send a Binding Acknowledge message to the 1646 mobile node (via the old route). It also forwards the Registration 1647 Request up to the next FA. The foreign agents above the crossover FA 1648 in the hierarchy that already got the Binding Update will see that 1649 the Registration Request does not supply any new care-of address 1650 information (the care-of address is the same as the address in 1651 the Binding Update) and will therefor ignore the previous Binding 1652 Update and update the mobility binding according to the Registration 1653 Request. 1655 B.3. Regional Registration 1657 A Regional Registration Request is forwarded to the GFA by way of 1658 one or more intermediate regional foreign agents. When the Regional 1659 Registration Request message arrives at the first foreign agent, the 1660 foreign agent checks its visitor list to see if this mobile node 1661 is already registered with it. If it is not, the foreign agent 1662 checks which next higher-level RFA to relay the Regional Registration 1663 Request to. It adds a Hierarchical Foreign Agent extension to the 1664 Regional Registration Request, including its address, and relays the 1665 message to the next RFA in the hierarchy toward the GFA. 1667 The next RFA checks its visitor list to see if the mobile node is 1668 already registered with it. If it is not, the RFA removes the 1669 Hierarchical Foreign Agent extension and adds a new one, with its own 1670 address, and relays the message to the next higher-level RFA in the 1671 hierarchy toward the GFA. 1673 This process is repeated in each RFA in the hierarchy, until an RFA 1674 recognizes the mobile node as already registered. This RFA may be 1675 the GFA, or any RFA beneath it in the hierarchy. If the mobile node 1676 is already registered with this RFA, the RFA generates a Regional 1677 Registration Reply and sends it to the next lower-level RFA in the 1678 hierarchy. The lifetime field in the Regional Registration Reply is 1679 set to the remaining lifetime that was earlier agreed upon between 1680 the mobile node and the GFA. If the lifetime of the GFA registration 1681 has expired, the Regional Registration Request is relayed all the way 1682 to the GFA. 1684 The Previous Foreign Agent Notification Extension, Binding Updates 1685 and Binding Acknowledge messages are used for Regional Registrations 1686 in the same way as for Home Registrations. That means that if the 1687 crossover FA receives the Binding Update before it receives the 1688 Registration Request, it forwards the Registration Request to the 1689 higher level FA, so that that FA updates its visitor list according 1690 to the Registration Request, and ignores the Binding Update. That FA 1691 also forwards the Registration Request to any FA or GFA that it has 1692 sent the corresponding Binding Update to. 1694 If the hierarchy between the advertising foreign agent and the GFA is 1695 announced in the Agent Advertisement, the mobile node may generate 1696 a Regional Registration Request not destined to the GFA, but to the 1697 closest RFA with which it can register. 1699 Replay protection can be provided at the announcing foreign agent, 1700 through the challenge-response mechanism described in [5]. If the 1701 GFA, and the RFAs in the hierarchy, trust the announcing foreign 1702 agent to perform the replay protection, timestamps or nonces between 1703 the mobile node and the GFA, or between the mobile node and each 1704 RFA, are not needed. If the challenge-response mechanism is used 1705 for replay protection, the mobile node inserts the 64 bit response 1706 value in the Identification field in the Regional Registration 1707 Request message. If a mobile node includes a Hierarchical Foreign 1708 Agent extension in its Registration Request message, it MAY insert 1709 the extension before the MN-HA or MN-FA authentication extension. 1710 In this case, the Hierarchical Foreign Agent extension MUST NOT be 1711 removed by the GFA or any other RFA prior to the generation of the 1712 Registration Reply message. 1714 If more than one Hierarchical Foreign Agent extension is inserted 1715 by the mobile node into the registration message, the order of the 1716 extensions MUST be maintained through the hierarchy. When sending a 1717 Regional Registration Reply, the GFA MUST ensure that the order of 1718 the Hierarchical Foreign Agent extensions is reversed from the order 1719 found in the Regional Registration Request. 1721 B.4. Regional Registrations and Smooth Handover 1723 Multiple hierarchy levels of foreign agents requires the use of 1724 smooth handover from [10], as discussed in Appendix B. This is 1725 not needed in a two level hierarchy. But a mobile node might not 1726 know how many levels of hierarchy a network has, so if the foreign 1727 agents in one network support both Regional Registrations and 1728 Smooth Handover a mobile node MAY try to use Regional Registrations 1729 without Smooth Handover. If the network requires the use of Smooth 1730 Handover (because it has more than two levels of hierarchy, or 1731 for other reasons) the Foreign Agent MUST deny the request by 1732 sending back a Registration Reply message with the Code field set to 1733 SMOOTH_HO_REQUIRED. 1735 The Foreign Agent NAI extension (see section 7.2) is also used during 1736 Smooth Handover. If Smooth Handovers are used, and the foreign 1737 agent does not advertise its own address in the Agent Advertisement 1738 message, the FA-NAI will be used to identify the Previous Foreign 1739 agent instead. This will be done by adding an FA-NAI extension 1740 (defined in section 6) to the Registration Request (together with the 1741 Previous Foreign Agent Notification extension) and in the Binding 1742 Update and setting the care-of address to zero. 1744 B.5. Co-located care of address 1746 If a mobile node uses a co-located care-of address, it MAY use 1747 Regional Registrations directly to the GFA (see section 4.1 and 1748 section 5). It MAY also use the same method to make use of multiple 1749 levels of Foreign Agents, if it can find out about the hierarchy, 1750 either from Mobility Agent Advertisements, or in some other way 1751 outside the scope of this specification. 1753 B.6. Data Traffic 1755 When a correspondent node sends traffic to the mobile node, the 1756 traffic arrives at the home agent, and the home agent tunnels the 1757 traffic to the GFA. The GFA or RFA at each level of the hierarchy has 1758 a visitor list for the mobile node, showing the address of the next 1759 lower-level RFA or FA in the hierarchy. Thus, a datagram arriving at 1760 the top level of the hierarchy, that is, the GFA, will be re-routed 1761 to the next lower-level RFA in the hierarchy. This re-routing occurs 1762 at each level of the hierarchy, until the datagram reaches the last 1763 point which is either the mobile node itself (in case of a co-located 1764 care-of address) or a foreign agent that can deliver the datagram to 1765 the mobile node with no further special Mobile IP handling. 1767 In case of decapsulation and re-encapsulation, it should be noted 1768 that the actual decapsulation need not occur at each step of the 1769 hierarchy. Instead, the foreign agent at that level can merely 1770 change the source and destination IP addresses of the encapsulating 1771 IP header. 1773 Traffic from the mobile node is sent as described in [9] or [8]. 1775 According to the Route Optimization specification [10], Binding 1776 Updates send to the correspondent node from the Home Agent 1777 will contain the address of the GFA, since this is the only 1778 care-of address known to the Home Agent. Therefore, Binding Updates 1779 from the mobile node sent to the correspondent node SHOULD also have 1780 the care-of address belonging to the GFA. This also has the advantage 1781 of reducing the number of Binding Update messages that have to be 1782 sent to the correspondent node, at a modest increase in routing path 1783 length. Furthermore, the local network domain may be configured to 1784 admit such traffic into the local domain only if packets are tunneled 1785 directly to the GFA. 1787 B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension 1789 If a GFA uses the Registration Reply to distribute an MN-FA key to 1790 the other RFAs in its domain, a new subtype for the Generalized MN-FA 1791 Key Reply Extension [11] is required. 1793 The subtype value is as follows: 1795 Subtype Name Value 1796 -------------- ------------ 1797 GFA-RFA Key Reply 5 1799 The subtype data for the GFA-RFA Key Reply subtype is a 4 byte SPI, 1800 followed by the registration key encoded according to the recipe 1801 indicated by the SPI. 1803 C. Authentication, Authorization and Accounting AAA Interactions 1805 When the mobile node has to obtain authorization by way of 1806 Authentication, Authorization and Accounting (AAA) infrastructure 1807 services, the control flow implicit in the main body of this 1808 specification is likely to be modified. Typically, the mobile node 1809 will supply credentials for authorization by AAA as part of its 1810 registration messages. The GFA will parse the credentials supplied 1811 by the mobile and forward the appropriate authorization request to a 1812 local AAA server (see [5, 4]). 1814 Concretely, this means that: 1816 - The GFA MAY include the Mobile IP Registration Request data 1817 inside an authorization request, directed to a local AAA server. 1819 - The GFA MAY receive the Mobile IP Registration Reply data 1820 from a message granting authorization, received from the AAA 1821 infrastructure. 1823 D. Anchoring at a GFA/RFA/FA 1825 As described earlier in this draft, once a mobile node has registered 1826 the address of a GFA as its care-of address with its home agent, it 1827 MAY perform regional registrations when changing foreign agent under 1828 the same GFA. When detecting that is has changed foreign agent, and 1829 if the new foreign agent advertises the `I' flag, the mobile node MAY 1830 address a Regional Registration Request message to its registered 1831 GFA, even if the address of that particular GFA is not advertised by 1832 the new foreign agent. The foreign agent MAY then relay the request 1833 to the GFA in question, or deny the request with error code 'unknown 1834 GFA'. 1836 Similarly, a mobile node MAY address a Regional Registration Request 1837 message to any Regional Foreign Agent or foreign agent that it has 1838 registered as the current care-of address with its home agent. 1839 Assume that a mobile node has registered the address of an RFA or 1840 foreign agent as its care-of address with its home agent. When 1841 detecting that it changes foreign agent, and if the new foreign agent 1842 advertises the `I' flag, the mobile node MAY address a Regional 1843 Registration Request to that RFA/FA. The new foreign agent MAY then 1844 relay the request to the RFA/FA in question, or deny the request 1845 with error code 'unknown GFA'. If the Regional Registration Request 1846 reaches the RFA/FA, and if the RFA/FA also has the capability to 1847 act as a GFA, it MAY accept the request and generate a Regional 1848 Registration Reply to the mobile node. This scenario assumes that 1849 keys have been distributed to the RFA/FA and to the mobile node prior 1850 to the regional registration, so that the Regional Registration 1851 Request message can be authenticated with the MN-GFA Authentication 1852 extension. 1854 Addresses 1856 The working group can be contacted via the current chairs: 1858 Basavaraj Patil Phil Roberts 1859 Nokia Megisto Corp. 1860 6000 Connection Dr. Suite 120 1861 20251 Century Blvd 1862 Irving, TX. 75039 Germantown MD 20874 1863 USA USA 1864 Phone: +1 972-894-6709 Phone: +1 847-202-9314 1865 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 1867 Questions about this memo can be directed to: 1869 Eva Gustafsson Annika Jonsson 1870 Ericsson Research Ericsson Research 1871 Torshamnsgatan 23 Torshamnsgatan 23 1872 SE-164 80 Stockholm SE-164 80 Stockholm 1873 SWEDEN SWEDEN 1875 Phone: +46 8 7641270 Phone: +46 8 4047242 1876 EMail: eva.gustafsson@ericsson.com EMail: annika.jonsson@ericsson.com 1877 Fax: +46 8 4047020 Fax: +46 8 4047020 1879 Charles E. Perkins 1880 Nokia Research Center 1881 313 Fairchild Drive 1882 Mountain View, California 94043 1883 USA 1885 Phone: +1-650 625-2986 1886 EMail: charles.perkins@nokia.com 1887 Fax: +1 650 625-2502