idnits 2.17.1 draft-ietf-mobileip-3gwireless-ext-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 6 months document validity. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 59 lines 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 124 == Unused Reference: '2' is defined on line 539, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 548, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 552, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2344 (ref. '2') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '4') == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-05 == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-06 == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Yingchun Xu (editor) 2 Internet Draft Rajesh Bhalla 3 January 2000 Ed Campbell 4 Karl Freter 5 3Com Corporation 6 Eileen McGrath Hadwen 7 Alcatel 8 Gopal Dommety 9 Kirit Joshi 10 Cisco Systems 11 Parviz Yegani 12 Ericson Wireless Communication Inc. 13 Takeo Matsumura 14 FUJITSU 15 Atsushi Teshima 16 HITACHI Ltd. 17 Lee Dong Hyun 18 HYUNDAI Electronics 19 Naoto Itoh 20 IDO Corporation 21 Kimihiro Ohki 22 KDD Corporation 23 Byung-Keun Lim 24 LG Information & Communications, Ltd 25 Peter J. McCann 26 Thomas Towle 27 Lucent Technologies 28 Jay Jayapalan 29 Motorola Inc. 30 Peter W. Wenzel 31 Carey B. Becker 32 James Jiang 33 Nortel Networks 34 Shota Shikano 35 Oki Electric Industry Co.,Ltd. 36 Woojune Kim 37 Yong Chang 38 Samsung Electronics Ltd. 39 Jun Mo Koo 40 SK Telecom 41 Bill Semper 42 Samsung Telecommunications 43 Mark A. Lipford 44 Frederic Leroudier 45 Sprint PCS 46 Jim Gately 47 USWest Advanced Technologies 49 Mobile IP Based Micro Mobility Management Protocol in 50 The Third Generation Wireless Network 51 53 Xu et al. Expires July 2000 1 54 Status of this Memo 56 This document is an Internet Draft and is in full conformance with 57 all provisions of Section 10 of RFC2026. Internet Drafts are working 58 documents of the Internet Engineering Task Force (IETF), its areas, 59 and working groups. Note that other groups may also distribute 60 working documents as Internet Drafts. 62 Internet Drafts are draft documents valid for a maximum of six 63 months and may be updated, replaced, or obsolete by other documents 64 at anytime. It is inappropriate to use Internet Drafts as reference 65 material or to cite them other than as "work in progress." 67 The list of current Internet-Drafts can be accessed at 68 http://www.ietf.org/ietf/1id-abstracts.txt. 70 The list of Internet-Draft Shadow Directories can be accessed at 71 http://www.ietf.org/shadow.html. 73 Abstract 75 This document defines extensions to the Mobile IP protocol [1] to 76 allow mobility management for the interface between a radio network 77 and a packet data network in the third generation cdma2000 network. 79 Mobile IP requires link layer connectivity between the Mobile Node 80 and the Foreign Agent. This draft proposes a protocol for achieving 81 this when the physical layer terminates at a point distant from the 82 FA. In particular, this protocol applies to cdma2000 networks where 83 the physical layer terminates at a Radio Network Node (RNN) and the 84 FA resides inside a separate Packet Data Serving Node (PDSN). The 85 PDSN is responsible for establishing, maintaining, and terminating 86 the link layer to the Mobile Node. A RNN is responsible for relaying 87 the link layer protocol between a Mobile Node and its corresponding 88 PDSN. 90 The interface between the RNN and the PDSN is called the RP 91 interface. This interface requires mobility management for handling 92 handoff from one RNN to another without interrupting end to end 93 communication. It also requires the support of the link layer 94 protocol encapsulation. 96 1. Introduction 98 This document defines extensions to the Mobile IP protocol [1] to 99 allow mobility management for the interface between a radio network 100 and a packet data network in the third generation cdma2000 network. 102 Mobile IP requires link layer connectivity between the Mobile Node 103 and the Foreign Agent. This draft proposes a protocol for achieving 104 this when the physical layer terminates at a point distant from the 106 Xu et al. Expires July 2000 2 107 FA. In particular, this protocol applies to cdma2000 networks where 108 the physical layer terminates at a Radio Network Node (RNN) and the 109 FA resides inside a separate Packet Data Serving Node (PDSN). The 110 PDSN is responsible for establishing, maintaining, and terminating 111 the link layer to the Mobile Node. A RNN is responsible for relaying 112 the link layer protocol between a Mobile Node and its corresponding 113 PDSN. 115 The interface between the RNN and the PDSN is called the RP 116 interface. This interface requires mobility management for handling 117 handoff from one RNN to another without interrupting end to end 118 communication. It also requires the support of the link layer 119 protocol encapsulation. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 123 this document are to be interpreted as described in [RFC-2119]. 125 2. Glossary 127 CDMA Code Division Multiple Access 128 FA Foreign Agent 129 HA Home Agent 130 MN Mobile Node 131 PDSN Packet Data Serving Node 132 RNN Radio Network Node 133 RP Interface between the RNN and the PDSN 135 3. cdma2000 Network RP Interface Overview 137 The high level architecture of a third generation cdma2000 network 138 RP interface is shown in Figure 1. 140 +---------+ +---------+ +---------+ 141 | | | | | | 142 | RNN |----RP------| PDSN |---------| HA | 143 | | Interface | | | | 144 +---------+ +---------+ +---------+ 145 /|\ 146 | Visited Access Home Network 147 | Provider Network 148 | 149 | 150 \|/ 151 +--------+ 152 | Mobile | 153 | Node | 154 +--------+ 156 Figure 1: The Third Generation cdma2000 Network RP Interface 158 Xu et al. Expires July 2000 3 159 In above figure 1, the PDSN will be responsible for establishing, 160 maintaining, and terminating the link layer to the Mobile Node. It 161 initiates the authentication, authorization, and accounting for the 162 Mobile Node and optionally, securely tunnels to the Home Agent. 164 The RNN is responsible for mapping the Mobile Node identifier 165 reference to a unique link layer identifier used to communicate with 166 the PDSN. RNN validates the Mobile Station for access service and 167 manages the physical layer connection to the Mobile Node. 169 4. Mobile IP Extensions 171 This section describes extensions to the Mobile IP protocol for the 172 RP interface within the third generation cdma2000 network. 174 4.1 Registration Request 176 In a cdma2000 network, the mobile node initiates a connection by 177 sending a call setup indication to the RNN across the radio network. 178 When this indication is received by a RNN, a Registration Request 179 will be sent from the RNN to the PDSN to setup a new RP session. 181 A RNN MUST send a Registration Request with the GRE encapsulation 182 and the reverse tunneling bit set. The Home Address field is set to 183 zero. The Home Agent field will be assigned to the IP address of the 184 PDSN and the Care-of Address field will be assigned to the IP 185 address of RNN. 187 When a Registration Request is received by a PDSN, the information 188 from the Session Specific Extension (see next section) will be used 189 to identify a RP session. When a registration is accepted, a GRE 190 tunnel will be created for this Mobile Node. 192 The fields of the Registration Request message are shown below: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type |S|B|D|M|G|V|T| | Lifetime | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Home Address | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Home Agent | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Care-of Address | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 + Identification + 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Extensions ... 210 +-+-+-+-+-+-+-+- 212 Xu et al. Expires July 2000 4 213 Type 1 (Registration Request) 215 G This bit MUST be set to 1 for GRE tunneling. 217 T This bit MUST be set to 1 for reverse 218 tunneling. 220 Home Address 221 The field is set to zero. 223 Home Agent 224 This field is assigned to the IP address of the 225 PDSN. 227 Care-of Address 228 This field is assigned to the IP address of RNN. 230 Extensions 231 The Session Specific Extension as described in 232 the next section MUST be included along with 233 the ones described in RFC2002. Specifically, 234 the MN-HA Authentication extension as described 235 in RFC2002 MUST be included along with this 236 extension. 238 4.2 Session Specific Extension 240 This extension is defined to carry information related to the 241 session between a Mobile Node and its serving PDSN. 243 The detailed format of the extension is shown as follows. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Protocol Type | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Key | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | reserved | MN Connection ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | MN ID Type | MN ID Length | MN ID | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | MN ID � 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Type 39 (not-skippable). 261 Xu et al. Expires July 2000 5 262 Length This is a one octet field and it indicates the 263 length (in bytes) of the extension, NOT 264 including the Type and Length fields. 266 Protocol Type 267 This is a two octet field. It indicates the type 268 of the protocol to be tunneled across the RP 269 interface. It is same as the Protocol Type field 270 in the GRE header. 272 Key This is a four octet value assigned by the RNN 273 and inserted in every GRE frame across the RP 274 interface during user data tunneling. 276 Reserved This is a two octet field. It is not used and is 277 set to zero. 279 MN Connection ID 280 This is a two octet field and it is used to 281 differentiate the multiple sessions from the 282 same Mobile Node. It is locally unique to a 283 Mobile Node. 285 MN ID Type 286 This is a two octet field and it indicates the 287 type of the following Mobile Node ID value. 289 MN ID Length 290 This is a one octet field and it indicates the 291 length (in bytes) of the following Mobile Node 292 ID field. 294 MN ID This is the Mobile Node ID, which is globally 295 unique. It is used to uniquely identify a Mobile 296 Node. 298 This extension MUST be included in the Registration Request, 299 Registration Reply, Registration Update and Registration Acknowledge 300 (see section 4.5) messages. It will be included before the MN-HA 301 Authentication extension in the Registration Request and 302 Registration Reply messages and before the Registration Update 303 Authentication Extension in the Registration Update and Registration 304 Acknowledge messages. 306 The MN ID and the MN Connection ID together will uniquely identify a 307 Mobile Session. 309 4.3 Registration Reply 311 The Registration Reply will be sent by a PDSN following the 312 procedure as described in [1]. The Home Address field will be the 313 same value as the Home Address field from the corresponding 314 Registration Request message received by the PDSN. 316 Xu et al. Expires July 2000 6 317 4.4 Registration Update/Acknowledge 319 Two new messages are defined to support PDSN initiated RP tunnel 320 tear down and to speed up resource reclamation on the RNN. 322 The Registration Update message is used for notification of the 323 change of the registration associated with a call. It shall be sent 324 by the PDSN to the previous RNN when a RNN to RNN handoff happens. 326 Both messages are sent with UDP using well-known port number 434. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Reserved | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Home Address | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Home Agent Address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 + Identification + 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Extensions ... 342 +-+-+-+-+-+-+-+- 344 The format of the Registration Update message is illustrated above, 345 and contains the following fields: 347 Type 20 349 Reserved Sent as 0; ignored on reception. 351 Home Address Sent as 0; 353 Home Agent Address 354 The IP Address of the PDSN. 356 Identification 357 A 64-bit number assigned by the node sending 358 the Registration Update message. It is used to 359 assist in matching requests with replies, and 360 in protecting against replay attacks. 361 Extensions 362 Both Registration Update Authentication 363 Extension (see section 4.6) and Session 364 Specific Extension (see section 4.2) SHALL be 365 included. 367 Xu et al. Expires July 2000 7 368 A Registration Update shall be sent by a PDSN to indicate the 369 closure of a RP session. The RNN may reclaim the resource associated 370 with that session. 372 A Registration Acknowledge message is used to acknowledge receipt of 373 a Registration Update message. It MUST be sent by a node receiving a 374 Registration Update message. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type | Reserved | Status | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Home Address | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Care Of Address | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 + Identification + 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Extensions ... 390 +-+-+-+-+-+-+-+- 392 The format of the Registration Acknowledge message is illustrated 393 above, and contains the following fields: 395 Type 21 397 Status If the Status is nonzero, this acknowledgment is 398 negative. 400 Reserved 401 Sent as 0; ignored on reception. 403 Home Address 404 Copied from the Registration Update message 405 being acknowledged. 407 Care of Address 408 The IP address of the RNN. 410 Identification 411 Copied from the Registration Update message 412 being acknowledged. 414 Extensions 415 Both Registration Update Authentication 416 Extension (see section 4.6) and Session 417 Specific Extension (see section 4.2) SHALL be 418 included. 420 Xu et al. Expires July 2000 8 421 Allowable values for the Status include: 423 0 successful acknowledgement 424 128 reason unspecified 425 129 administratively prohibited 426 131 sending node failed authentication 427 133 identification mismatch 428 134 poorly formed Registration Update 430 4.5 Registration Update Authentication Extension 432 The Registration Update Authentication extension is used to 433 authenticate the Registration Update and Registration Acknowledge 434 messages. It has the same format and default algorithm support 435 requirements as the authentication extension defined for Mobile IP 436 protocol [1], but with a different type (40). The authenticator 437 value is computed from the stream of bytes including the shared 438 secret, the UDP payload all prior extensions in their entirety, and 439 the type and length of this extension, but not including the 440 authenticator field itself nor the UDP header. The secret used for 441 computing the authenticator field is shared between the RN and PDSN. 442 This extension is required in both Registration Update and 443 Registration Acknowledge messages. 445 4.6 Summary 447 The extensions to Mobile IP include enabling the GRE encapsulation 448 and reverse tunneling during Registration. A new extension called 449 Session Specific Extension is defined and is mandatory in the 450 Registration Request, Registration Reply, Registration Update and 451 Registration Acknowledge messages. The Home Address field MUST be 452 set to zero in the Registration Request, Registration Reply, 453 Registration Update and Registration Acknowledge messages. 455 Two new messages (Registration Update and Registration Acknowledge) 456 are defined to support the RP session disconnection in order to 457 speed up resource reclamation. 459 5.0 GRE Encapsulation 461 GRE encapsulation as described in [3] shall be supported during user 462 data transmission. A new protocol type might be required to support 463 the link layer protocol defined for the third generation cdma2000 464 network. The Key field shall be required and its value shall be same 465 as the one from the Session Specific Extension as described above. 466 The sequence number may be required, depending on the requirement of 467 the protocol encapsulated within the GRE frame. 469 During traffic tunneling, the sender will insert the Key value from 470 the Registration Request message into the Key field of the GRE 472 Xu et al. Expires July 2000 9 473 header. The receiver will use the Key value from the GRE header to 474 decide where to forward the user data. 476 6.0 IANA Considerations 478 This document specifies two new messages and two new extensions to 479 Mobile IP protocol [1]. The numbers to be assigned to these messages 480 and extensions have been taken from the numbering space assigned to 481 Mobile IP in RFC 2002 [1] and extended in RFC 2356 [4]. 483 The Registration Update and Registration Acknowledge messages 484 defined in section 4.4 MUST be assigned the Type values of 20 and 21 485 respectively. 487 The Session Specific Extension defined in section 4.2 MUST be 488 assigned the Type value of 39, and the Registration Update 489 Authentication Extension defined in section 4.5 MUST be assigned a 490 value of 40. The Status values defined in section 4.4 are the error 491 codes defined in RFC 2002 [1]. They correspond to the error values 492 conventionally associated with a rejection by a home agent (i.e., 493 the values from the range 128-255). The IANA MUST record the Status 494 values as defined in section 4.4 of this document. 496 With these assignments, the Type values assigned to the two new 497 messages and to two new extensions, and the error values for the 498 Status field, have been identified as not conflicting with any 499 numbers defined for Mobile IP to date and documented at 500 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 502 7.0 Security Considerations 504 The protocol presented in this draft is designed for use over a 505 protected, private network between RNN and PDSN. Pre-arranged 506 security associations in the style of Mobile IPv4 are assumed to 507 exist among every (RNN, PDSN) pair that will form an RP connection. 508 Also, it is assumed that the session specific information is 509 authenticated by means outside the scope of this draft. 511 Several potential vulnerabilities exist if these assumptions are not 512 met. First, if the network connecting the RNN and PDSN is accessible 513 to an attacker, user traffic may be intercepted and/or spoofed if 514 there are no other end-to-end security mechanisms in place. Second, 515 the Mobile IP control messages must be authenticated, to prevent 516 tunnel setup and tear down by unauthorized parties. Mobile IP 517 Authentication Extensions are used to provide this additional 518 protection for control messages. Finally, if session specific 519 information is not authenticated, a denial-of-service attack is 520 possible if a RNN unknowingly sends a registration request to the 521 PDSN with a spoofed session specific extension. The PDSN would then 522 send an explicit tunnel tear down to the previous RNN, causing user 523 traffic to be misdirected to the new RNN. This would cause a loss of 525 Xu et al. Expires July 2000 10 526 service and possibly interception of traffic, depending on what 527 other security measures are in place. 529 8.0 Acknowledgments 530 The authors of this draft would like to thank Charles E. Perkins and 531 David B. Johnson for the ideas presented in the Route Optimization 532 draft [7]. 534 References 536 [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 537 1996. 539 [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May 540 1998. 542 [3] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic 543 Routing Encapsulation (GRE)", RFC 1701, October 1994. 545 [4] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for 546 Mobile IP". RFC 2356, June 1998. 548 [5] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network 549 Address Identifier Extension". draft-ietf-mobileip-mn-nai- 550 05.txt, October 1999. (work in progress). 552 [6] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/ 553 Response Extensions". draft-ietf-mobileip-challenge-06.txt, 554 October 1999. (work in progress). 556 [7] Charles E. Perkins and David B. Johnson. "Route Optimization in 557 Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999. 558 (work in progress). 560 Xu et al. Expires July 2000 11 561 Authors� Addresses 563 Yingchun Xu 564 3Com Corporation 565 1800 West Central Road 566 Mount Prospect, 567 USA 60056 568 Phone: (847) 342-6814 569 Email: Yingchun_Xu@3com.com 571 Rajesh Bhalla 572 3Com Corporation 573 1800 West Central Road 574 Mount Prospect, 575 USA 60056 576 Phone: (847) 797-2618 577 Email: rajesh_bhalla@3com.com 579 Karl Freter 580 3Com Corporation 581 1800 W. Central Road 582 Mount Prospect, IL 60056 583 Phone: (847) 222-2268 584 Email: karl_freter@3com.com 586 Ed Campbell 587 3Com Corporation 588 1800 W. Central Road 589 Mount Prospect, IL 60056 590 Phone:(847) 342-6769 591 Email: ed_campbell@3com.com 593 Eileen McGrath Hadwen 594 Alcatel 595 PO Box 4442, 596 Boulder CO 80306 597 Phone: 303 499 1496 598 Email: mcgrath.hadwen@worldnet.att.net 600 Gopal Dommety 601 Cisco Systems 602 170 West Tasman Drive 603 San Jose, CA 95134 604 Phone: (408) 525-1404 605 Email: gdommety@cisco.com 607 Kirit Joshi 608 Cisco Systems 609 170 West Tasman Drive 610 San Jose, CA 95134 611 Phone: (408) 525 7367 612 Email: kjoshi@cisco.com 614 Xu et al. Expires July 2000 12 615 Parviz Yegani 616 Ericson Wireless Communication Inc. 617 6455 Lusk Blvd. 618 San Diego, CA 92121 619 Phone: (858) 332-6017 620 Email: p.yeqani@ericsson.com 622 Takeo Matsumura 623 FUJITSU 624 Kamiodanaka 625 Nakahara-ku, Kawasaki-City 626 Phone: +81-44-740-8109 627 Email: matumura@mcs.ts.fujitsu.co.jp 629 Atsushi Teshima 630 HITACHI Ltd. 631 216 Totsuka-cho, Totsuka-ku, Yokohama Japan 244-8567 632 Phone:+81-45-865-7003 633 Email: atsushi_teshima@cm.tcd.hitachi.co.jp 635 Lee Dong Hyun 636 HYUNDAI Electronics Industry 637 KOREA Kyungkido Icheonsi 435-050 638 Phone: 82-336-630-2756 639 Email: jihs@hei.co.kr 641 Naoto Itoh 642 IDO Corporation 643 Gobancho YS building 644 12-3 Gobancho, Chiyoda-ku, Tokyo Japan 102-8361 645 Phone: +81-3-3263-9660 646 Email: nao-itoh@ido.co.jp 648 Kimihiro Ohki 649 KDD Corporation 650 3-2, Nishi-Shinjuku 2-chome, 651 Shinjuku-ku, Tokyo 163-8003, Japan 652 Phone: +81-3-3347-5477 653 Email: ki-ohki@kdd.co.jp 655 Byung-Keun Lim, 656 LG Information & Communications, Ltd. 657 533, Hogye-dong, Dongan-ku, Anyang-shi, 658 Kyungki-do,431-080, Korea 659 Phone: +82-343-450-7199 660 Email: bklim@lgic.co.kr 662 Peter J. McCann 663 Lucent Technologies 664 Rm 2Z-305 665 263 Shuman Blvd 666 Naperville, IL 60566 667 Phone: (630) 713 9359 669 Xu et al. Expires July 2000 13 670 EMail: mccap@lucent.com 672 Thomas Towle 673 Lucent Technologies 674 Rm. 2D-225 675 263 Shuman Blvd 676 Naperville, IL 60566 677 Phone: 630-979-7303 678 Email: ttowle@lucent.com 680 Jay Jayapalan 681 Motorola Inc. 682 1501 W Shure Drive 683 Arlington Heights,IL 60004 684 Phone: (847) 642-4031 685 Email: jayapal@cig.mot.com 687 Peter W. Wenzel 688 Nortel Networks 689 2201 Lakeside Blvd. 690 Richardson, TX 75082, USA 691 Phone: (972) 684-7134 692 Email: wenzel@nortelnetworks.com 694 Carey B. Becker 695 Nortel Networks 696 2201 Lakeside Blvd. 697 Richardson, TX 75082, USA 698 Phone: (972) 685-0560 699 Email: becker@nortelnetworks.com 701 James Jiang 702 Nortel Networks 703 2201 Lakeside Blvd. 704 Richardson, TX 75082, USA 705 Phone: (972)684-5885 706 Email: jjiang@nortelnetworks.com 708 Shota Shikano 709 Oki Electric Industry Co., Ltd. 710 Phone:+81-3-3454-2111 711 Email: shikano471@oki.co.jp 713 Woojune Kim 714 Samsung Electronics Ltd. 715 11th Fl, Samsung Plaza Bldg, 716 263, Seohyeon-dong, Pundang-gu, 717 Sungnam-shi, Kyunggi-do, 718 463-050 Pundang P.O. Box 32, Korea 719 Phone: +82-342-779-8526 720 Email: keg@telecom.samsung.co.kr 722 Yong Chang 724 Xu et al. Expires July 2000 14 725 Samsung Electronics Ltd. 726 11th Fl, Samsung Plaza Bldg, 727 263, Seohyeon-dong, Pundang-gu, 728 Sungnam-shi, Kyunggi-do, 729 463-050 Pundang P.O. Box 32, Korea 730 Phone: +82-342-779-6822 731 Email : yong@telecom.samsung.co.kr 733 Bill Semper 734 Samsung Telecommunications 735 1130 Arapaho Rd 736 Richardson, TX 75082 737 Phone: 972-761-7996 738 Email: bsemper@telecom.samsung.com 740 Jun Mo Koo 741 SK Telecom 742 Phone: 650-568-5762 743 Email: jmkoo@sktelecom.com 745 Mark A. Lipford 746 Sprint PCS 747 8001 College Blvd. Suite 210 748 KSOPKZ0101 749 Overland Park, KS 66210 750 Phone: 913-664-8335 751 Email: Mlipfo01@sprintspectrum.com 753 Frederic Leroudier 754 Sprint PCS 755 8001 College Blvd. Suite 210 756 KSOPKZ0101 757 Overland Park, KS 66210 758 Phone: 913-664-8350 759 Email: FLerou01@sprintspectrum.com 761 Jim Gately 762 USWest Advanced Technologies 763 4001 Discovery Drive 764 Boulder, CO 80303 765 Phone: 303-541-6415 766 Email: jgately@uswest.com 768 Xu et al. Expires July 2000 15