idnits 2.17.1 draft-calhoun-mobileip-proactive-fa-03.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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Unused Reference: '2' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1119, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- No information found for draft-hiller-cdma2000-AAA - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-02 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-02) exists of draft-dommety-mobileip-anchor-handoff-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-04) exists of draft-calhoun-mobileip-fa-tokens-00 -- Possible downref: Normative reference to a draft: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-05) exists of draft-ietf-mobileip-gnaie-00 ** Obsolete normative reference: RFC 2344 (ref. '12') (Obsoleted by RFC 3024) == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-00 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '16') ** Obsolete normative reference: RFC 3012 (ref. '18') (Obsoleted by RFC 4721) -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 11 errors (**), 0 flaws (~~), 16 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-mobileip-proactive-fa-03.txt Tom Hiller 5 Date: November 2000 Lucent Technologies 6 James Kempf 7 Sun Microsystems, Inc. 8 Peter J. McCann 9 Lucent Technologies 10 Chandana Pairla 11 University of Illinois 12 Ajoy Singh 13 Sebastian Thalanany 14 Motorola 16 Foreign Agent Assisted Hand-off 18 Status of this Memo 20 This document is an individual contribution for consideration by the 21 Mobile IP Working Group of the Internet Engineering Task Force. 22 Comments should be submitted to the mobile- 23 ip@standards.nortelnetworks.com mailing list. 25 Distribution of this memo is unlimited. 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at: 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at: 44 http://www.ietf.org/shadow.html. 46 Copyright (C) The Internet Society 2000. All Rights Reserved. 48 Abstract 50 The Mobile IP protocol allows a Mobile Node to continue using the 51 same home address even after changing its point of attachment to the 52 Internet. This provides transparency to most existing applications 53 that assume a fixed address and a fixed point of attachment. 54 However, new applications, such as voice-over-IP, have additional 55 real-time requirements such that a change in the point of attachment 56 will cause a noticeable degradation of service unless additional 57 steps are taken to reduce the latency of a handoff event. 59 This specification proposes extensions to the Mobile IP protocol that 60 may be used by Foreign Agents to set up a Mobile Node's visitor 61 entry, and forward its packets, prior to receiving a formal 62 Registration Request from the Mobile Node. This enables a very rapid 63 establishment of service at the new point of attachment so that the 64 effect of the handoff on real-time applications is minimized. 66 Table of Contents 68 1.0 Introduction 69 1.1 Requirements language 70 1.2 Terminology 71 1.3 Fast handoffs 72 2.0 Registration Latency 73 2.1 Gateway Foreign Agents 74 2.2 Anchor Foreign Agent 75 3.0 Movement Detection 76 3.1 Ping-Pong effect 77 4.0 Reverse Tunneling Support 78 5.0 Security Relationships 79 6.0 Power Consumption 80 7.0 Operation 81 7.1 Foreign Agent Considerations 82 7.2 Gateway/Anchor Foreign Agent Considerations 83 8.0 Handoff Request Message 84 9.0 Handoff Reply Message 85 10.0 Link Layer Address NAI 86 10.1 CDMA 2000 Link Layer Address Extension 87 10.2 Ethernet Link Layer Address Extension 88 10.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension 89 11.0 Error Values 90 12.0 IANA Considerations 91 13.0 Security Considerations 92 14.0 References 93 15.0 Acknowledgements 94 16.0 Authors' Addresses 95 17.0 Full Copyright Statement 97 1.0 Introduction 99 This specification proposes extensions to the Mobile IP protocol that 100 may be used by Foreign Agents to set up a Mobile Node's visitor 101 entry, and forward its packets, prior to receiving a formal 102 Registration Request from the Mobile Node. This enables a very rapid 103 establishment of service at the new point of attachment so that the 104 effect of the handoff on real-time applications is minimized. The 105 proposed extensions make a few minimal assumptions about support 106 available from the link layer. These assumptions are fairly broad and 107 abstract. Although they address the kinds of link layer support 108 available in existing radio link layers, the assumptions are not 109 based on any specific radio link protocol. 111 The extensions handle both intra-domain and inter-domain handoff. 112 While intra-domain handoff MAY make use of pre-configured security 113 associations between Mobility Agents, inter-domain handoffs MAY make 114 use of the AAA infrastructure. In the case of inter-technology 115 handoff, active involvement by the mobile is necessary to switch from 116 one network interface to another; however, the delivery of the agent 117 advertisements, indicating the availability of a mobility agent on a 118 new network interface, is still controlled by network assisted 119 handoff. 121 In summary, this draft covers a hand-off scenario not addressed by 122 RFC 2002: that of a pro-active, network-controlled, anchor-chained 123 hand-off. 125 1.1 Requirements language 127 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 128 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 129 described in [4]. 131 1.2 Terminology 133 This document frequently uses the following terms: 135 AAA 136 Authentication, accounting and authorization. 138 Anchor Foreign Agent (AFA) 139 A foreign agent with publicly routable IP address that acts as 140 an anchor point when a mobile moves to a new foreign agent. 141 Upon successful global registration (registration with home 142 agent) of a mobile node, the anchor foreign agent supports 143 local registration when the mobile node changes its point of 144 attachment to some other neighboring foreign agents. 146 cdma2000 147 This is a wide-band radio transmission technology standard, 148 that uses CDMA(code division multiple access) technology, to 149 meet the demands of a third-generation wireless communication 150 system. 152 Connection ID 153 A number used to differentiate different link layer connections 154 originated from the same device. 156 Dormant mode 157 Certain wireless technologies support dormancy, which allows 158 the mobile to go into power saving mode. This typically occurs 159 when the mobile has been idle for some time, but could be 160 initiated by the network. 162 Foreign Agent IP Address Derivation 163 The derivation of the IP address of a source foreign agent or a 164 target foreign agent based on the receipt of a link layer 165 trigger at the target foreign agent or the source foreign agent 166 respectively. 168 Gateway Foreign Agent(GFA) 169 A foreign agent with publicly routable IP address that acts as 170 a concentration point for other foreign agents within an 171 administrative domain. Upon successful global registration 172 (registration with Home agent) of a mobile node, the GFA 173 supports local registration when the mobile node changes its 174 point of Attachment to some other foreign agent of the same 175 administrative Domain. 177 Home Domain 178 The domain where the home network [1] and home agent [1] are 179 located. 181 International Mobile Subscriber information (IMSI) 182 A number used for identifying a mobile subscriber station. 184 Link layer 185 A link layer specifies a protocol used by communicating nodes 186 to exchange information over a physical link. A mobile node 187 attaches itself to a mobile access network, before it can be 188 served by a foreign agent. A mobile node's link layer address 189 is the media access control(MAC) address of the mobile node's 190 network interface. 192 Mobility Agent 193 A foreign agent or a home agent. The foreign agent types 194 include an anchor foreign agent and a gateway foreign agent. 196 Mobility Advertisement 197 An advertisement message constructed by attaching a special 198 extension to a router advertisement message. 200 Movement Detection 201 A detection of a movement in the link layer attachement of the 202 mobile node to a mobile access network. 204 Ping-Pong Handoff 205 The rapid oscillation of a mobile node among coverage area of 206 two or more foreign agents. 208 Proactive Foreign agent 209 A foreign agent that initiates mobile/IP registration on behalf 210 of a mobile node due to reception of some link layer trigger 211 event. 213 Source Trigger 214 A signal received by the source foreign agent mobile/IP stack, 215 via the link layer, when the mobile node departs from the 216 serving area of the source foreign agent. 218 Target Trigger 219 A signal received by the target foreign agent mobile/IP stack, 220 via the link layer, when the mobile node arrives at the serving 221 area of the target foreign agent. 223 Trigger 224 The link layer signal used by wireless link layer to inform 225 inter foreign agent handoff event to Mobile/IP stack. 227 Visited Domain 228 An administrative domain, visited by a Mobile IP client, and 229 containing the AAA infrastructure needed to carry out the 230 necessary operations enabling Mobile IP registrations. From 231 the point of view of the foreign agent, the foreign domain is 232 the local domain. 234 1.2 Fast handoffs 236 MNs connect to FAs via direct, link-layer connections. Because an FA 237 is directly connected to the link-layer, it may obtain link-layer 238 information such as power measurements that might indicate the 239 necessity of a hand-off to a new FA. The FA can also gain assurance 240 of the MN's identity through link-layer authentication, and can 241 authenticate the stream of traffic coming from the MN, including any 242 power measurements or other indications used for hand-off. 244 In this document, we will assume that the link-layer events are 245 signaled to the Foreign Agent as "triggers". The acquisition of a 246 "trigger" to signal that a hand-off is necessary may be more 247 difficult when the technologies differ. We assume that any such 248 triggers will be sufficient to derive the IP addresses of the Foreign 249 Agents that will receive or send the hand-off. If such a trigger is 250 not available or if the MN decides on its own that a hand-off is to 251 take place, then one of the FAs can often still derive the identity 252 (IP address) of the other from link-layer messages. 254 In order for the Mobile IP protocol to provide fast hand-off, the 255 following problems must be addressed: 257 1. Reducing the latency involved in the registration process. 258 Although optimization of the Registration process is not 259 typically considered a Hand-Off problem, this proposal assumes 260 that such a mechanism is in place. 261 2. Reducing the latency involved in the Mobile Node's movement 262 detection process. 263 3. "Bi-casting" the Mobile Node's traffic to two (or more) points 264 of attachment, ensuring that the mobile's traffic is delivered 265 as soon as the link layer hand-off is completed. 266 4. Support for Reverse Tunneling, which MAY be required for 267 private addresses. 268 5. The Security Relationships between the mobility entities for 269 inter-domain hand-offs. 270 6. Does not increase mobile power consumption 272 2.0 Registration Latency 274 The Mobile IP protocol [1] requires that a Mobile Node registers with 275 a Foreign Agent, and subsequently its Home Agent, in order to have 276 its packets delivered to its current point of attachment. The Mobile 277 IP Regional Registration [6] specification proposes optimized 278 registration approaches using two different methods: 280 1. Gateway Foreign Agents (GFA), which are mobility agents that 281 act as concentration points for Foreign Agents within an 282 Administrative Domain. 283 2. Anchor Foreign Agents (AFA), where a previously used Foreign 284 Agent becomes an anchor point when a mobile moves to a new 285 Foreign Agent. 287 Both GFAs and AFAs allow a Mobile Node's registration message to be 288 processed by a Mobility Agent in the local domain, eliminating the 289 need to contact the Home Agent, which MAY be topologically distant. 291 2.1 Gateway Foreign Agents 293 The Mobile IP Regional Registration specification introduces the 294 Gateway Foreign Agent (GFA), as a mobility agent that two Foreign 295 Agents providing service to a Mobile Node have in common. Figure 1 296 provides an example of a Mobile's initial registration, through the 297 GFA. Given this is the first registration message, the message MUST 298 be forwarded to the Home Agent. All packets destined for the mobile 299 will be delivered to the GFA, which in turn will forward the packets 300 to the Foreign Agent servicing the Mobile Node. 302 Reg Req +-----+ Reg Req 303 +----------->| oFA |--------------+ 304 | +-----+ | 305 | v 306 +----+ +-----+ Reg Req +----+ 307 | MN | | GFA |<------->| HA | 308 +----+ +-----+ +----+ 310 +-----+ 311 | nFA | 312 +-----+ 313 Figure 1 - Initial Registrations through GFA 315 In the event that the mobile moves to a new Foreign Agent that is 316 serviced by a GFA that is common with oFA, the Mobile Node MAY issue 317 a Regional Registration Request (see Figure 2). The Regional 318 Registration message does not need to be forwarded to the Home Agent, 319 since the mobile's traffic can still be delivered to the same GFA. 320 This optimized approach effectively reduces the latency involved in 321 the registration process. 323 +-----+ 324 | oFA | 325 +-----+ 327 +----+ +-----+ +----+ 328 | MN | | GFA | | HA | 329 +----+ +-----+ +----+ 330 | ^ 331 | +-----+ | 332 +------------>| nFA |-------------+ 333 Regional Reg +-----+ Regional Reg 335 Figure 2 - Regional Registration through GFA 337 2.2 Anchor Foreign Agent 339 The Mobile IP Regional Registration specification introduces what 340 this document will call the Anchor Foreign Agent, which is similar to 341 [7]. The Anchor Foreign Agent operates very similarly to the GFA, 342 with the exception that the mobile's old Foreign Agent acts as an 343 anchor point for the Mobile Node. 345 In order to minimize the latency involved in the registration 346 process, the Mobile Node MAY issues a Regional Registration message, 347 setting the old Foreign Agent as the GFA, as shown in Figure 3. Once 348 completed, the Mobile Node MAY issue an additional RFC 2002 compliant 349 Registration Messages to eliminate the routing leg through the anchor 350 Foreign Agent. 352 +-----+ +----+ 353 | oFA | | HA | 354 +-----+ +----+ 355 ^ 356 +----+ | 357 | MN | | Regional 358 +----+ | Reg 359 | | 360 | +-----+ 361 +------------>| nFA | 362 Regional Reg +-----+ 363 Figure 3 - Regional Registrations through an AFA 365 3.0 Movement Detection 367 The Mobile IP protocol [1] and the Regional Registration extension 368 [6] require Mobile Nodes to listen for, or solicit, advertisements in 369 order to detect that a movement to a new IP subnet has occurred. This 370 movement detection mechanism introduces significant latency into the 371 hand-off process, which causes service degradation, especially for 372 real-time services. Service is further impacted given the additional 373 latency introduced through the registration process that follows the 374 movement detection, since the mobile's traffic can only be delivered 375 once all of the registration has completed. 377 There have been many solutions proposed to solve this problem, 378 including increasing the advertisement frequency. In networks where 379 radio spectrum is expensive or bandwidth is limited, the additional 380 signaling required for increasing advertisement frequency is a 381 serious issue impacting deployability. 383 In this document, we propose that the Foreign Agent take a pro-active 384 approach and issue the Handoff messages on behalf of the Mobile Node 385 (acting as a surrogate of sorts). When a Foreign Agent is aware that 386 a hand-off is occurring at the link-layer, a trigger is sent to the 387 Mobile IP protocol stack. 389 +-----+ 390 | GFA | 391 +-----+ 392 ^ | 393 3. Regional | | 4. Regional 394 Reg Request | | Reg Reply 395 | v 396 +-----+ 1. Handoff Request +-----+ 397 | | -----------------> | | 398 | oFA | | nFA | 399 | | 2. Handoff Reply | | 400 +-----+ <----------------- +-----+ 402 +-----+ Movement +-----+ 403 | MN | - - - - - - - - -> | MN | 404 +-----+ +-----+ 405 Figure 4 - Source Trigger Pro-Active Handoff 407 A source trigger (see Figure 4) is one that is obtained by the old 408 Foreign Agent (oFA) once the link layer detects that the Mobile Node 409 is departing its coverage area. A target trigger (see Figure 5), on 410 the other hand, is one that is obtained by the new Foreign Agent 411 (nFA) once the link layer detects that the Mobile Node is arriving in 412 its coverage area. Note that both triggers may be available before 413 the actual completion of the link layer handoff. 415 The messages depicted in both Figures 4 and 5 are very similar. The 416 main difference is the initiator of the Handoff Request message. In 417 both examples, an optional Gateway Foreign Agent is used, which 418 requires the use of the Regional Registration messages [6]. 420 In both the source and target triggers, a Foreign Agent obtains 421 link-layer information, such as power measurements, that indicate the 422 necessity of a handoff to the new Foreign Agent. 424 In the event of a source trigger, oFA transmits a Handoff Request 425 message to nFA. The Handoff Request MUST include the Mobile Node's 426 Home Address, Home Agent Address, remaining registration lifetime, as 427 well as the Link-Layer Address Extension (see Section 10). The GFA's 428 identity MUST also be present, if one was used for the Mobile Node's 429 registration. Upon receipt of the message, nFA MUST create the Mobile 430 Node's visitor entry, and respond with the Handoff Reply message. 432 +-----+ 433 | GFA | 434 +-----+ 435 ^ | 436 3. Regional | | 4. Regional 437 Reg Request | | Reg Reply 438 | v 439 +-----+ 1. Handoff Request +-----+ 440 | | <----------------- | | 441 | oFA | | nFA | 442 | | 2. Handoff Reply | | 443 +-----+ -----------------> +-----+ 445 +-----+ Movement +-----+ 446 | MN | - - - - - - - - -> | MN | 447 +-----+ +-----+ 448 Figure 5 - Target Trigger Pro-Active Handoff 450 In target triggers, the trigger occurs on nFA, which results in the 451 transmission of a Handoff Request to oFA. The Handoff Request message 452 MUST include the Mobile Node's Link-Layer Address (see Section 10) in 453 order for oFA to correctly identify the Mobile Node. The request 454 message MAY include additional Mobile Node information, if such 455 information was provided by the link layer. Upon receipt of the 456 request, oFA MUST respond with the Handoff Reply message, which 457 includes the Mobile Node's Home Address, Home Agent Address, 458 remaining registration lifetime and Link-Layer Address Extension. If 459 a GFA was used in the Mobile Node's registration, it's address MUST 460 be supplied. 462 Regardless of the direction of the Handoff Request, if nFA receives 463 GFA information within the message from oFA, it SHOULD issue a 464 Regional Registration Request with the GFA, which will respond with 465 the Regional Registration Reply. 467 3.1 Ping-Pong effect 469 Some link-layers are subject to rapid motion of MNs between two FAs. 470 For example, even though link-layer power measurements may indicate 471 that a hand-off is necessary, the mobile may fail to attach to the 472 new point of attachment, and return almost immediately to its old 473 point of attachment. This event is known as a "ping-pong" effect. 475 Data +-----+ Data +----+ 476 +-------------| oFA |<--------------------------| HA | 477 | +-----+ +----+ 478 v ^ | 479 +----+ Handoff | | Data 480 | MN | Request | | 481 +----+ | | 482 ^ v v 483 | +-----+ 484 +-------------| nFA | 485 Data +-----+ 486 Figure 6 - Bi-Casting by the Anchor Foreign Agent 488 Figure 6 provides an example of bi-casting a Mobile Node's through 489 both the old and new Foreign Agents. Bi-casting is established when 490 the oFA issues a successful Handoff Reply to nFA, or receives a 491 successful Handoff Reply from nFA. This causes oFA to forward all of 492 the Mobile Node's traffic to the nFA, as well as to the Mobile Node, 493 if a link-layer channel exists. 495 Figure 7 provides an example where bi-casting is performed on the 496 Gateway Foreign Agent, which is initiated by nFA setting the 'S' bit 497 (Simultaneous Binding) in the Regional Registration Request. 499 Data +-----+ Data 500 +-------------| oFA |<-------------+ 501 | +-----+ | 502 v | 503 +----+ +-----+ Data +----+ 504 | MN | | GFA |<--------| HA | 505 +----+ +-----+ +----+ 506 ^ | 507 | +-----+ | 508 +-------------| nFA |<-------------+ 509 Data +-----+ Data 511 Figure 7 - Bi-Casting by the Gateway Foreign Agent 513 When simultaneous bindings are in effect, and a ping-pong event 514 occurs, the mobile's service is guaranteed not to experience any 515 additional latency beyond that imposed by the link-layer handoff. 517 4.0 Reverse Tunneling Support 519 In the event the Mobile Node requested Reverse Tunneling [12] 520 support, by setting the 'T' bit in its Registration Request, the 521 Handoff message from oFA (see Sections 8.0 and 9.0) includes the 'T' 522 bit enabled to inform nFA to establish a bi-directional tunnel for 523 the visitor entry. 525 5.0 Security Relationships 527 The Mobile IP Regional Registration specification [6] requires that 528 the communicating Mobility Agents exchange authenticated messages. 529 This imposes a requirement for Mobility Agents to share a pre- 530 established security association. This assumption is valid for 531 intra-domain mobility (mobility within an Administrative Domain). 532 However, such a requirement introduces a scaling problem when the 533 Mobility Agents are owned by separate Administrative Domains (ADs). 535 Given that the existing AAA infrastructure is used to establish 536 dynamic security associations between Foreign and Home Agents in 537 different ADs, the same infrastructure could be used to establish the 538 required security association for the purposes of inter-domain hand- 539 offs (see Figure 8). 541 +-----+ +-----+ 542 | AAA |-------------->| AAA | 543 +-----+ +-----+ 544 ^ | 545 | | 546 | AAA | 547 | Hand-Off | 548 | Req | 549 | v 550 +-----+ +-----+ 551 | oFA | | nFA | 552 +-----+ +-----+ 554 +-----+ Movement +-----+ 555 | MN | - - - - - - > | MN | 556 +-----+ +-----+ 557 Figure 8 - Inter-FA communication using AAA 559 Note that it is possible for geographically neighboring Foreign 560 Agents owned by different Administrative Domains to have a pre- 561 established security association, which would reduce the latency 562 introduced by the AAA infrastructure traversal. Given that such 563 geographically neighboring FAs MAY be small in number, such an 564 approach MAY be reasonable. 566 6.0 Power Consumption 568 An additional benefit that derives from this proposal is the 569 potential for tracking mobile nodes while in dormant mode, if the 570 radio link supports it, allowing significant power saving without 571 adding additional complexity to the network layer protocol in the 572 wired network. One of the primary innovations proposed here, namely 573 to allow the Foreign Agents to set up visitor entries prior to the 574 Mobile Node's registration, is also useful for power saving. Certain 575 radio link layers allow the mobile node to enter dormant mode when 576 idle. Allowing the network to control the handoff ensures that the 577 mobiles do not have to be removed out of dormant mode in order to 578 establish a Mobile IP handoff. 580 Limiting power consumption is a requirement for certain wireless 581 Standards Defining Organizations (SDOs), and a Mobile IP fast handoff 582 proposal MUST satisfy this requirement. 584 7.0 Operation 586 A Foreign Agent can receive two different types of triggers informing 587 it of a handoff (The event that causes the trigger may be derived via 588 link layer messaging assistance from the network or from the mobile): 590 - a "source trigger" is when the old FA is informed of an 591 upcoming link-layer handoff, 592 - a "target trigger" occurs at the new FA when it is informed 593 that a link layer handoff is in progress. 595 The method by which such triggers occur are link-layer specific, and 596 are outside the scope of this document. It is also possible that a 597 particular kind of link layer technology can support both source and 598 target triggers. 600 7.1 Foreign Agent Considerations 602 Upon receipt of a trigger event, a Foreign Agent MAY issue a Handoff 603 request message to the Foreign Agent the mobile is being handed off 604 to/from. If the message is the result of a target trigger, the Type 605 Of Trigger bit MUST be set and the Link-Layer Address Extension (see 606 Section 10) MUST be present. The message's Home Address and Home 607 Agent Address fields MAY be set to NULL if this information is not 608 known at the time the message is transmitted. 610 Upon receipt of a Handoff Request message with the Type Of Trigger 611 bit set, a Foreign Agent MUST respond with the Handoff Reply message. 612 The Handoff Reply MUST include both the Mobile Node's Home Address 613 and Home Agent Address in the message header. The remaining mobile's 614 registration lifetime MUST be included in the Reply's lifetime field. 615 Furthermore, the Foreign Agent MAY include any security associations 616 that were dynamically created, an example of such security 617 associations are those described in [8]. If a Gateway Foreign Agent 618 was used in the Mobile's registration, the GFA's identity MUST be 619 included in the Gateway Foreign Agent Address Extension [6] MUST be 620 present. 622 A Foreign Agent that issues such a Handoff Reply with the Code field 623 set to success (zero value) MUST "bi-cast" all packets destined to 624 the Mobile Node to both the Mobile Node and to the new Foreign Agent. 626 The Foreign Agent that receives a successful Handoff Reply message 627 (one that includes a zero value in the Code field), a visitor entry 628 is created with the information found in the message. The Foreign 629 Agent MUST be prepared to deliver packets to the Mobile Node prior to 630 receiving a Registration Request [1] from the Mobile Node. 632 Note that it is possible for the encapsulation method used between 633 oFA and nFA to be different from the one requested by the Mobile Node 634 during its Registration process. When this occurs, the respective 635 Foreign Agents MUST perform encapsulation translation. 637 A Foreign Agent that receives a source trigger, it MUST send a 638 Handoff Request message with the Type Of Trigger bit disabled. The 639 message MUST also include the Mobile Node's Home Address and Home 640 Agent Address in the message header. The remaining mobile 641 registration lifetime MUST be included in the lifetime field. The 642 Foreign Agent MAY also include any security associations that were 643 dynamically created (see [8] for an example). If a Gateway Foreign 644 Agent was used for the mobile, it's identity MUST be included in the 645 Gateway Foreign Agent Address Extension [6]. 647 Upon receipt of a Handoff Request with the Type Of Trigger bit 648 disabled, a Foreign Agent MUST process the packet and respond with 649 the Handoff Reply message. If successfully processed, the Foreign 650 Agent MUST create a Visitor Entry for the Mobile Node, and be 651 prepared to deliver packets received by the initiator of the Handoff 652 Request destined for the Mobile Node. The Handoff Reply message MUST 653 include the Home Address, Home Agent Address, lifetime value, and the 654 Link-Layer Address Extension (see Section 10). 656 A Foreign Agent that receives a Handoff Reply with the Code field set 657 to success (zero value) MUST "bi-cast" all packets destined to the 658 Mobile Node to both the Mobile Node and to the new Foreign Agent. 660 If the message received by the new Foreign Agent contained a GFA IP 661 Address Extension [6], and it shares a security association with the 662 GFA, it MUST issue a Regional Registration Request to the GFA. The 663 Regional Registration Request's Care-Of address field MUST be set to 664 the local Foreign Agent's address, while the GFA IP Address MUST be 665 set to the address of the recipient of the request. The request's 666 lifetime field is set to an administratively configured value. A 667 successful Regional Registration Reply MUST cause the Foreign Agent 668 to create a visitor entry for the Mobile Node. 670 If a Regional Registration Reply message is received with the code 671 field set to DO_NOT_SERVICE_MN (Section 11), the Foreign Agent SHOULD 672 NOT provide service to the Mobile Node. The Foreign Agent MAY enforce 673 this by closing the Link-Layer connection (if possible), not issuing 674 any Mobility Advertisements to the Mobile Node (assuming a point-to- 675 point Link Layer), or simply denying all Registration Requests with 676 the error code set to 65 (Administratively Prohibited) [1]. 678 Once a visitor entry has been created, and the Mobile Node 679 establishes a link layer channel with the Foreign Agent, its traffic 680 will be immediately delivered, along with a Mobility Advertisement 681 message [1]. A Mobile Node MUST issue a Registration Request when it 682 receives a Mobility Advertisement from a new Foreign Agent. 684 Note that Foreign Agents MAY delay in sending Mobility 685 Advertisements, especially to reduce noticeable service disruption 686 during a ping-pong effect. However, when doing so, the Foreign Agent 687 MAY need to re-issue a new Handoff Request to oFA (and optionally the 688 Regional Registration message to GFA), to extend the visitor entry's 689 lifetime. 691 Delaying Mobility Advertisements MAY also be done in wireless 692 technologies that support dormant mobiles. When this is done, a 693 Foreign Agent would typically wait to send the advertisement until 694 the mobile is no longer in the dormant mode. When data is received by 695 the Foreign Agent for a dormant Mobile Node, it SHOULD initiate the 696 link-layer mechanism that causes the mobile to "wake-up" (this is 697 typically known as paging). 699 The above procedures require that Foreign Agents issue Handoff 700 Requests as a result of Link-Layer triggers. However, the discovery 701 of the identity of the Foreign Agents to which the Handoff messages 702 must be sent is outside the scope of this document. 704 In the event that a Foreign Agent handling a particular Mobile Node's 705 visitor entry is soon to expire, and the Mobile Node has not yet 706 issued a Registration Request, the FA has the option to transmit a 707 new Handoff Request message to the old Foreign Agent (and the 708 optional Regional Registration Request to the GFA). Whether the 709 renewal is performed on behalf of the Mobile Node is a policy 710 decision up to the network administrator. 712 A Foreign Agent MAY receive packets for a Mobile Node to which it 713 does not have a direct link layer connection. At this point, the 714 Foreign Agent MAY: 715 1. Drop all packets for the Mobile Node 716 2. Buffer packets for the Mobile Node 717 3. Attempt to establish a link-layer connection with the mobile 718 4. Issue a Regional Registration Request with a zero lifetime 720 Given that a Mobile Node's packets will be delivered prior to 721 registration, a Mobile Node is free to discard all packets received 722 from Foreign Agents with which it hasn't registered. 724 When the new Foreign Agent receives the Mobile Node's Registration 725 Request [1], its Anchor Foreign Agent changes to the new Foreign 726 Agent. The Foreign Agent MUST transmit a Handoff Request message to 727 the old Foreign Agent with the lifetime field set to zero. A Foreign 728 Agent that receives a Handoff Request with the lifetime field set to 729 zero is being informed that it is no longer the anchor point for the 730 mobile. It MAY issue a Handoff Request to the new Foreign Agent in 731 the future if it wishes to keep receiving the mobile's packets for 732 possible delivery. 734 When a Foreign Agent determines that it is no longer servicing a 735 Mobile Node, it SHOULD issue a Regional Registration Request message 736 with the lifetime field set to zero (0). This will cause the visitor 737 entry associated with the Foreign Agent's Care-Of address on the GFA 738 to be deleted. Foreign Agents MAY decide to not issue this message 739 immediately when a link-layer trigger is received, in order to 740 support smooth service during a ping-pong event. 742 7.2 Gateway Foreign Agent Considerations 744 Upon receipt of a Regional Registration Request, a GFA MUST create a 745 visitor entry indicating the Mobile Node's current point of 746 attachment. In the event that a visitor entry already exists, the 747 GFA SHOULD be able to create multiple visitor entries for the same 748 Mobile Nodes with different Care-Of addresses. If the 'S' bit was 749 enabled in the Regional Registration Request, the GFA MUST be able to 750 forward the mobile's packets to all Foreign Agents in the visitor 751 entries. 753 When constructing the Regional Registration Reply, the GFA SHOULD 754 include the FA-FA authentication extension [6], and set the lifetime 755 field to the lesser of: 756 1. number of seconds before the Mobile Node's Registration with 757 its Home Agent will expire. 758 2. The lifetime of the locally created Visitor Entry. 760 In the event that the Regional Registration Request's lifetime field 761 was set to zero (0), the GFA MUST remove the visitor entry associated 762 with the Care-Of address in the message. 764 Should the GFA decide that the Foreign Agent is not to provide 765 service to the Mobile Node, it MUST issue a Regional Registration 766 Reply message, with the code field set to DO_NOT_SERVICE_MN (see 767 Section 11). 769 8.0 Handoff Request Message 771 The Handoff Request message is used to inform a peer that a pro- 772 active handoff is being initiated. The Handoff Request message can be 773 used for both source and target triggers, through the Type of Trigger 774 'I' bit in the message flags. When sent as a result of a target 775 trigger, the Home Address and Home Agent fields MAY be set to zero 776 (unless this information was communicated by the link layer, which is 777 outside the scope of this document). 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type |S|x|I|M|G|r|T|x| Lifetime | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | MN Home Address | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Home Agent Address | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | 789 + Identification + 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Extensions ... 793 +-+-+-+-+-+-+-+- 794 Type TBD (Handoff Request) 796 S When set, and when no GFA address extension is 797 present, it indicates that both oFA and nFA will 798 attempt to deliver datagrams directly to MN, if 799 a link-layer connection exists. If a GFA 800 address extension is present, it implies that 801 nFA should set the 'S' bit in its regional 802 registration. 804 I Type of Trigger. A value of zero is a source 805 trigger (sent by oFA), while a value of one is a 806 target trigger (sent by nFA). 808 M, G, T As defined in [1, 12]. This refers to the 809 tunnel between oFA and nFA, or, if GFA IP 810 address extension is present, to the parameters 811 that should be requested in the Regional Reg 812 Req. 814 Lifetime The requested Lifetime for which nFA will serve 815 the MN on behalf of oFA, without requiring a new 816 registration. 818 MN Home Address The home address of the mobile node. When using 819 a private address, the G and T flags must be 820 sent and a GRE Key extension must be included. 822 Home Agent Addr The home agent address of the mobile node. 824 Identification As in defined in [1]. 826 Extensions The Message MUST include LLA (see Section 10), 827 the FA-FA Authentication Extension [6], and MAY 828 include GFA IP address. 830 9.0 Handoff Reply Message 832 The Handoff Reply message is sent in response to the Handoff Request 833 message. When a source trigger caused the Handoff Request message to 834 be sent, this message is sent with a successful code if the Visitor 835 Entry was successfully created. When a target trigger caused the 836 Handoff Request message, receipt of this message with a successfuly 837 code SHOULD cause the Visitor Entry to be created. 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Type | Code | Lifetime | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 |S|x|I|M|G|r|T|x| Reserved | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | MN Home Address | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Home Agent Address | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | | 851 + Identification + 852 | | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Extensions ... 855 +-+-+-+-+-+-+-+- 857 Type TBD (Handoff Reply) 859 Code A value indicating the result of the Handoff 860 Request. See below for a list of currently 861 defined Code values. 863 Lifetime If the Code field indicates that the 864 registration was accepted, the Lifetime field is 865 set to the number of seconds remaining before 866 the registration is considered expired. A value 867 of zero indicates that the mobile node has been 868 deregistered. A value of 0xffff indicates 869 infinity. If the Code field indicates that the 870 registration was denied, the contents of the 871 Lifetime field are unspecified and MUST be 872 ignored on reception. 874 S When set, and when no GFA address extension is 875 present, it indicates that both oFA and nFA will 876 attempt to deliver datagrams directly to MN, if 877 a link-layer connection exists. If a GFA 878 address extension is present, it implies that 879 nFA should set the 'S' bit in its regional 880 registration. 882 I Type of Trigger. A value of zero is a source 883 trigger (sent by oFA), while a value of one is a 884 target trigger (sent by nFA). 886 M, G, T As defined in [1, 12]. This refers to the 887 tunnel between oFA and nFA, or, if GFA IP 888 address extension is present, to the parameters 889 that should be requested in the Regional Reg 890 Req. 892 MN Home Address The home address of the mobile node. When using 893 a private address, the G and T flags must be 894 sent and a GRE Key extension must be included. 896 Home Agent Addr The home agent address of the mobile node. 898 Lifetime The requested Lifetime for which nFA will serve 899 the MN on behalf of oFA, without requiring a new 900 registration. 902 Identification As in defined in [1]. 904 Extensions The Message MUST include LLA (see Section 10) 905 and the FA-FA Authentication Extension [6]. 907 10.0 Generalized Link Layer Address Extension 909 This section defines the Generalized Link Layer Address (LLA) 910 Extension, used by any that needs to communicate Link Layer 911 Addresses. The format of the extension follows MIER [13], and each 912 sub-type of link-layer address defines its own sub-structure. This 913 draft defines two sub-types, the cdma2000 IMSI and the Ethernet 914 Address. Future RFCs should allocate their own sub-type and define 915 their own address formats. 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Type | Length | Sub-Type | LLA ... 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Type 925 TBD (skippable) [1] 927 Length 929 The length of the Link Layer Address + the one octet Sub-Type field 931 Sub-Type 932 This field contains the Link Layer sub-type identifier 934 LLA 936 Contains the Link Layer Address 938 In this document, two subtypes are defined: 940 1 cdma2000 International Mobile Station Identity [14] 941 2 Ethernet 48 bit MAC address [15] 942 3 64 bit Global ID, EUI-64 [19] 944 10.1 cdma2000 Link Layer Address Extension 946 The cdma2000 Link Layer Address Extension contains the International 947 Mobile Station Identity, as defined in [14]. 949 0 1 2 3 950 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Type | Length | Sub-Type | IMSI ... 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Type 957 TBD (skippable) [1] 959 Length 961 The length of the IMSI field + the one octet Sub-Type field 963 Sub-Type 965 1 967 IMSI 969 Contains the IMSI, in the form: 971 : 973 Where the is an ASCII-based representation of the 974 International Mobile Station Identifier, most significant digit 975 first, ":" is ASCII 0x3a, and the Connection ID is the ASCII 976 representation of a small, decimal number used for 977 distinguishing different link-layer connections from the same 978 device. 980 10.2 Ethernet Link Layer Address Extension 982 The Ethernet Link Layer Address Extension contains the 48 bit 983 Ethernet MAC Address, as defined in [15]. 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Type | Length | Sub-Type | MAC ... 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 Type 993 TBD (skippable) [1] 995 Length 997 7 (includes the Sub-Type field) 999 Sub-Type 1001 2 1003 MAC 1005 Contains the 48 bit Ethernet MAC Address. 1007 10.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension 1009 The 64-Bit Global Identifier (EUI-64) Address Extension contains the 1010 64 bit address, as defined in [19]. 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Type | Length | Sub-Type | MAC ... 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 Type 1020 TBD (skippable) [1] 1022 Length 1024 7 (includes the Sub-Type field) 1026 Sub-Type 1027 3 1029 MAC 1031 Contains the 64-Bit Global Identifier Address. 1033 11.0 Error Values 1035 The following table contains the name of Code [9] to be returned in a 1036 Registration Reply, the value for the Code, and the section in which 1037 the error is first mentioned in this specification. 1039 Error Name Value Section of Document 1040 ---------------------- ----- ------------------- 1041 DO_NOT_SERVICE_MN TBD 7.1 1043 12.0 IANA Considerations 1045 The number for the Generalized Link Layer Address Extension in 1046 section 10 is taken from the numbering space defined for Mobile IP 1047 registration extensions defined in RFC 2002 [1]. These MUST NOT 1048 conflict with any numbers used in RFC 2002[1], RFC 2344 [12], RFC 1049 2356 [16], RFC 2794 [17] and RFC 3012 [18]. 1051 The Code values specified for errors, listed in section 11, MUST NOT 1052 conflict with any other code values listed in RFC 2002 [1], RFC 2344 1053 [12], RFC 2356 [16], RFC 2794 [17] and RFC 3012 [18]. 1055 Sections 8 and 9 require numbers assigned from the Mobile IP control 1056 message type address space. The numbers assigned MUST NOT conflict 1057 with [1], [6] and [7]. 1059 13.0 Security Considerations 1061 Similar to [6] and [7], this specification assumes that the local 1062 Foreign Agent, and the GFA (or AFA) inherently trust each other. This 1063 MAY be achieved through the use of a long lived security association. 1065 This specification introduces a new change to Mobile IP, which is the 1066 ability for a Mobile Node to receive packets from a Foreign Agent to 1067 which it has not yet registered. In the event that the Mobile Node 1068 does not wish to receive packets from unknown Foreign Agents, it MAY 1069 drop them. 1071 Although this document does not specify how Foreign Agents can 1072 identify, or track, Mobile Nodes, it is assumed that the wireless 1073 link layer be sufficiently secure in order to correctly identify a 1074 Mobile Node. Wireless networks that do not provide such features will 1075 be subjected to impersonation attacks, where malicious nodes could 1076 cause the Foreign Agents to believe that a Mobile Node has moved to 1077 other service areas. 1079 14.0 References 1081 [1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October 1082 1996. 1084 [2] T. Hiller et al. "Cdma2000 Wireless Data Requirements for AAA". 1085 draft-hiller-cdma2000-AAA-00.txt (work in progress). October 1086 1999. 1088 [3] U. Black. "2nd Generation Wireless Networks". Prentice-Hall. 1089 New York. 1999. 1091 [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement 1092 Levels". BCP 14. RFC 2119. March 1997. 1094 [5] C. Perkins and D. Johnson. "Route Optimization in Mobile IP". 1095 draft-ietf-mobileip-optim-08.txt (work in progress). February 1096 1999. 1098 [6] E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional 1099 Registration", draft-ietf-mobileip-reg-tunnel-02.txt (work in 1100 progress), March 2000. 1102 [7] G. Dommety. "Local and Indirect Registration for Anchoring Hand- 1103 offs", draft-dommety-mobileip-anchor-handoff-00.txt (work in 1104 progress), March 2000. 1106 [8] P. Calhoun, H. Akhtar, E. Qaddoura, N. Asokan, "Foreign Agent 1107 Keys Encoded as Opaque Tokens for use in Hand-off Process", 1108 draft-calhoun-mobileip-fa-tokens-00.txt (work in progress), 1109 March 2000. 1111 [9] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 1112 Encapsulation (GRE). Request for Comments (Informational) 1701, 1113 Internet Engineering Task Force, October 1994. 1115 [10] C. Perkins. Minimal Encapsulation within IP. Request for Com- 1116 ments (Proposed Standard) 2004, Internet Engineering Task Force, 1117 October 1996. 1119 [11] Mohamed M.Khalil, Emad Qaddoura, Haseeb Akhtar, Pat R. Calhoun, 1120 "Generalized NAI Extension (GNAIE)", draft-ietf-mobileip-gnaie- 1121 00.txt (work in progress), February 2000. 1123 [12] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1124 1998. 1126 [13] Khalil, and et. al. Mobile IP Extensions Rationalization (MIER) 1127 draft-ietf-mobileip-mier-00.txt, Dec 1999. 1129 [14] TIA/EIA/IS-95-B 1131 [15] D. Plummer, "An Ethernet Address Resolution Protocol - or - Con- 1132 verting Network Protocol Addresses to 48.bit Ethernet Address 1133 for Transmission on Ethernet Hardware", RFC 826, Symbolics, 1134 Inc., November 1982. 1136 [16] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for 1137 Mobile IP", RFC 2356, June 1998. 1139 [17] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier 1140 Extension", RFC 2794, March 2000. 1142 [18] C. Perkins, P. Calhoun. Mobile IP Challenge/Response Exten- 1143 sions. RFC 3012, November 2000. 1145 [19] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Regis- 1146 tration Authority", 1147 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 1148 March 1997. 1150 15.0 Acknowledgements 1152 The authors would like to thank Charles Perkins, George Tsirtsis and 1153 Scott Corson for their valuable feedback. 1155 16.0 Authors' Addresses 1157 Questions about this memo can be directed to: 1159 Pat R. Calhoun 1160 Network and Security Research Center, Sun Labs 1161 Sun Microsystems, Inc. 1162 15 Network Circle 1163 Menlo Park, California, 94025 1164 USA 1166 Phone: +1 650 786 7733 1167 Fax: +1 650 786 6445 1168 E-mail: pcalhoun@eng.sun.com 1170 Tom Hiller 1171 Lucent Technologies 1172 Rm 2F-218 1173 263 Shuman Blvd 1174 Naperville, IL 60566-7050 1175 USA 1177 Phone: +1 630 979 7673 1178 FAX: +1 630 979 7673 1179 E-Mail: tom.hiller@lucent.com 1181 James Kempf 1182 Network and Security Research Center, Sun Labs 1183 Sun Microsystems, Inc. 1184 15 Network Circle 1185 Menlo Park, California, 94025 1186 USA 1188 Phone: +1 650 786 5890 1189 Fax: +1 650 786 6445 1190 E-mail: james.kempf@eng.sun.com 1192 Peter J. McCann 1193 Lucent Technologies 1194 Rm 2Z-305 1195 263 Shuman Blvd 1196 Naperville, IL 60566-7050 1197 USA 1199 Phone: +1 630 713 9359 1200 FAX: +1 630 713 4982 1201 E-Mail: mccap@lucent.com 1202 Chandana Pairla 1203 University of Illinois - Urbana Champaign 1204 3315, DCL, 1205 1304, W. Springfield Ave., 1206 Urbana, IL 61801 1207 USA 1209 Phone: +1 217 244 7117 1210 E-mail: pairla@uiuc.edu 1212 Sebastian Thalanany 1213 Motorola 1214 1475 West Shure Drive 1215 Arlington Heights, IL - 60004 1216 USA 1218 Phone: +1 847 435 9296 1219 E-mail: sthalan1@email.mot.com 1221 Ajoy Singh 1222 Motorola 1223 1501 West Shure Drive 1224 Arlington Heights, IL � 60004 1225 USA 1227 Phone: +1 847 632 6941 1228 E-mail: asingh1@email.mot.com 1230 17.0 Full Copyright Statement 1232 Copyright (C) The Internet Society (2000). All Rights Reserved. 1234 This document and translations of it may be copied and furnished to 1235 others, and derivative works that comment on or otherwise explain it 1236 or assist in its implementation may be prepared, copied, published 1237 and distributed, in whole or in part, without restriction of any 1238 kind, provided that the above copyright notice and this paragraph are 1239 included on all such copies and derivative works. However, this docu- 1240 ment itself may not be modified in any way, such as by removing the 1241 copyright notice or references to the Internet Society or other 1242 Internet organizations, except as needed for the purpose of develop- 1243 ing Internet standards in which case the procedures for copyrights 1244 defined in the Internet Standards process must be followed, or as 1245 required to translate it into languages other than English. The lim- 1246 ited permissions granted above are perpetual and will not be revoked 1247 by the Internet Society or its successors or assigns. This document 1248 and the information contained herein is provided on an "AS IS" basis 1249 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1250 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1251 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1252 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1253 FITNESS FOR A PARTICULAR PURPOSE."