idnits 2.17.1 draft-ietf-mobileip-cellular-requirements-01.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- The document date (October 1999) is 8953 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-ietf-roamops-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2486 (ref. '2') (Obsoleted by RFC 4282) -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-02) exists of draft-ietf-diffserv-framework-01 -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '5') == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-00 -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '10' -- No information found for draft-ietf-mobileip-chal - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-00 -- No information found for draft-chuali-mobileip-dremip - is the name correct? -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' -- No information found for draft-hiller-3Gwireless - is the name correct? -- Possible downref: Normative reference to a draft: ref. '17' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-07 ** Obsolete normative reference: RFC 2344 (ref. '19') (Obsoleted by RFC 3024) ** Obsolete normative reference: RFC 2002 (ref. '20') (Obsoleted by RFC 3220) == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-regkey-00 -- Possible downref: Normative reference to a draft: ref. '21' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '22' ** Downref: Normative reference to an Informational RFC: RFC 2216 (ref. '24') -- Possible downref: Normative reference to a draft: ref. '25' Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Eva Gustafsson, Ericsson, Editor 2 Expires October 1999 3 Annika Jonsson, Ericsson 4 Elisabeth Hubbard, Telia 5 Jonas Malmkvist, Telia 6 Anders Roos, Telia 8 Requirements on Mobile IP from a Cellular Perspective 9 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@smallworks.com mailing list. Distribution of this 16 memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The increasing interest in Mobile IP as a potential macro-mobility 38 solution for cellular networks leads to new solutions and extensions 39 to the existing protocol. As part of this work, there is a need to put 40 together the requirements on Mobile IP from a cellular perspective. 41 This draft lists a set of requirements on Mobile IP for use in cellular 42 networks, for instance IMT-2000, and relates the requirements to 43 proposed solutions. These requirements consider Mobile IPv4, but the 44 list will be extended for Mobile IPv6 as well. 46 Table of contents 48 1. Introduction......................................................2 49 2. General considerations............................................3 50 3. Authentication....................................................4 51 4. Registration requests generated on behalf of a mobile node........5 52 5. Private networks..................................................6 53 6. Reverse tunnelling................................................7 54 7. Route optimization................................................7 55 8. Dynamic home address assignment...................................8 56 9. Temporary home....................................................8 57 10. Handover performance.............................................9 58 11. Conclusions......................................................9 59 12. Intellectual property considerations............................10 60 13. Acknowledgements................................................10 61 14. References......................................................10 62 15. Author's address................................................12 64 1. Introduction 66 Recently, there has been an increasing interest in Mobile IP as a 67 potential future mobility standard, common to cellular systems and the 68 Internet as a whole [3][16][17]. The benefits of adopting a common 69 mobility solution would include independence of access network 70 technologies and common solutions for fixed and wireless networks. 72 The purpose of this document is to state a first version of the 73 requirements on Mobile IP as a potential macro-mobility solution for 74 future cellular networks. In particular, we consider third generation 75 mobile systems fulfilling the requirements from ITU for International 76 Mobile Telecommunications - 2000 (IMT-2000). The Universal Mobile 77 Telecommunication System (UMTS) and the Enhanced Data rates for GSM 78 Evolution (EDGE), which both evolve from the GSM/GPRS standard, as well 79 as Cdma2000, are such IMT-2000 systems. One important aspect when 80 considering Mobile IP for cellular networks, is to provide interworking 81 with existing solutions. 83 Parts of the requirements presented in this document are specific for 84 Mobile IP in cellular networks, while others consider mobile users in 85 general. However, we have chosen to include all kinds of requirements 86 necessary for a cellular operator to deploy Mobile IP. The requirements 87 in this document mainly refer to Mobile IPv4 [20], but will be extended 88 for Mobile IPv6 [18] as well. 90 We start in Section 2 with some general, system-level requirements for 91 IP mobility in cellular networks. Then we list more specific 92 requirements in Section 3 through Section 10. Section 11 concludes the 93 document. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [6]. 99 2. General considerations 101 This section describes some general considerations and requirements on 102 a system using Mobile IP. Note that these requirements are not specific 103 requirements on the Mobile IP protocol, but point out important aspects 104 on a system level. 106 To allow Mobile IP to be a mobility solution which supports many 107 different kinds of access networks/technologies, the Mobile IP 108 functionality shall be independent of the access network technology. For 109 Mobile IP to be deployed in future cellular networks, it also needs to 110 provide interworking with existing protocols. 112 Mobile IP provides authentication of the signalling messages [20]. For 113 security reasons, such as keeping the current location of a user unknown 114 to other users, it should also be possible to provide encryption of the 115 Mobile IP signalling. This may be implemented through, for instance, 116 IPSec tunnels and security associations established on a permanent basis 117 inside and between different administrative domains. It should also be 118 possible to provide encryption of the traffic. A solution is to employ 119 IPSec together with Mobile IP, as suggested in [25]. 121 As emerging Internet quality-of-service mechanisms are expected to 122 enable a wide-spread use of real-time services between stationary nodes, 123 for instance voice over IP and videoconferencing, there will be a demand 124 for using the same kind of services when being mobile. Promising a 125 certain level of quality of service to a mobile user is generally 126 difficult, since there may not be enough resources available in the part 127 of the network that the mobile node is moving into. However, when network 128 resources allow, there should be mechanisms to handle quality of service 129 for mobile users, particularly in case of handover and route 130 optimization. The differences between stationary and mobile nodes making 131 use of quality-of-service mechanisms should also be minimized, and 132 network operators should not need to employ different quality of service 133 platforms for stationary and mobile users. The emerging quality-of- 134 service architectures, Differentiated Services and Integrated Services 135 [4][5][23][24], do not consider mobile nodes. Additions or changes may 136 be needed. 138 Quality-of-service mechanisms enforce a differentiated sharing of 139 bandwidth among different services and different users. Thus, there must 140 be mechanisms available to identify traffic flows with different 141 quality-of-service attributes, and to make it possible to charge the 142 different users accordingly. 144 It is well known that mobile nodes are more complex to handle than 145 stationary ones. Anyway, the extra handling of mobile nodes should be 146 based on the same basic mechanisms as the stationary ones, rather than 147 on separate mechanisms. Among these basic mechanisms are (i) an 148 Authentication, Authorization, Accounting (AAA) infrastructure; (ii) 149 quality of service and policy control; and (iii) directory services and 150 gateway services like IP telephony. 152 Lastly, as more and more users become mobile, the need for a uniform 153 service delivery across various access technologies increases. 154 Ultimately, the user should not need to know what kind of access 155 technology is in use at a particular moment. When bandwidth and other 156 network capabilities allow, IP-based services should appear the same way 157 independently of the access technology. Moreover, a normal user will try 158 to employ the most efficient access, considering capacity and cost, 159 which means that changes of access technology can be expected during 160 active sessions. Thus, the change of access technology should be as 161 smooth and as transparent to the user as possible. 163 These are general considerations and requirements; some of them may 164 apply to Mobile IP and some may be fulfilled through other protocols and 165 solutions. The following sections address more specific requirements on 166 Mobile IP, in order to provide solutions satisfactory for operators as 167 well as end users. 169 3. Authentication 171 The authentication of a mobile node or user can be performed at different 172 locations and be based upon different parameters. We may also consider 173 two phases of the authentication procedure: full or initial 174 authentication and subsequent authentications. Full authentication is 175 performed when the existing security associations are insufficient, for 176 instance at initial registration, or when a mobile node requests a new 177 home agent. Subsequent authentications are performed at handover, that 178 is, when a mobile node changes its point of attachment within the same 179 administrative domain, or to renew bindings before they are timed out. 181 The Mobile IP protocol specifies authentications to be performed at the 182 home agent, and the identifications to be based on the home IP address 183 of the mobile node [20]. However, additional solutions and extensions 184 to Mobile IP have introduced identification and authentication based on 185 the Network Access Identifier (NAI) [1][2][8][9][10][11][12][13]. 186 Basing the authentication on the IP address means that it is the host 187 that is authenticated, while authentication based on the NAI results in 189 authentication of the mobile user. The latter alternative would 190 alleviate the connection between a specific user and a specific host, 191 and provide a secure way for dynamic allocation of IP addresses. Thus, 192 the full authentication must be based on a unique user identity, for 193 example the NAI. 195 For reasons of subscription handling and charging, the full 196 authentication must always be performed at the home domain or by the 197 home operator, that is, where the user has its subscription. Such 198 authentication procedures have been suggested in [8][10], and may, for 199 instance, be performed through AAA functionality. The full 200 authentication should not be performed at the home agent, since the home 201 agent may be dynamically allocated. 203 However, once a mobile node is connected to a visited network, 204 performing subsequent authentications at the home domain could result 205 in significant signalling delay. To minimize the signalling delay, and 206 to reduce the signalling between the visited and the home network, it 207 should be possible to perform subsequent authentications in the visited 208 network, as described in [8]. 210 Finally, since the Mobile IP protocol shall allow independence of the 211 access network technology, the Mobile IP authentication should be 212 independent of the authentication for the access, for instance the radio 213 resources. A separation of the authentication procedures is motivated 214 by the fact that radio resources are scarce, and an access network 215 operator may not want to allow Mobile IP signalling until the access 216 network in itself has accepted to provide resources for a mobile node. 217 Also, different access networks with, for instance, radio-based or fixed 218 access, experience different types of security threats, and may address 219 them differently. 221 The requirements for the authentication procedure are: 223 1. There MUST be a generic Mobile IP authentication procedure, 224 specifying full and subsequent authentication, as well as authentication 225 for registration requests generated on behalf of a mobile node. 227 2. Full authentication MUST be performed with the home network, the 228 home administrative domain or with the home operator of the mobile user. 230 3. There MUST be a unique user identity for full authentication. 232 4. It SHOULD be possible to perform subsequent authentication locally 233 at the visited network. 235 5. Mobile IP SHOULD use the same authentication infrastructure as 236 stationary Internet nodes. 238 4. Registration requests generated on behalf of a mobile node 240 There may be cases when a mobile node does not support Mobile IP 241 signalling. If so, the signalling between the mobile node and the 242 foreign agent could be handled by lower-level functionality in the 243 access network. Then, the foreign agent could generate a registration 244 request on behalf of the mobile node. This was described in [9] as 245 surrogate registrations. 247 For reasons of backward compatibility with existing systems, it must be 248 possible to implement Mobile IP without introducing Mobile IP signalling 249 in the terminal. Registration requests generated by the foreign agent 250 on behalf of a mobile node provide such a solution. They also provide a 251 means to minimize the signalling over the radio link, and shall be 252 included in Mobile IP. Lastly, secure full and subsequent authentication 253 for registration requests generated on behalf of a mobile node must be 254 ensured according to the generic authentication procedure for Mobile IP. 256 The requirements for registration requests generated on behalf of a 257 mobile node are: 259 1. It MUST be possible to employ Mobile IP in a network without 260 introducing Mobile IP signalling in the terminal. 262 5. Private networks 264 Since private networks are an important part of the communication 265 network structure, Mobile IP must support private networks and private 266 address spaces. A proposed solution is to support private address spaces 267 through proxy home and foreign agents [8]. This solution also supports 268 hierarchical foreign agents within a network. Such a hierarchy may be 269 valuable in order to improve handover performance. It may also be 270 important for security reasons, since it allows the existence of agents 271 without direct connection to external agents, that is, agents external 272 to for instance a private network. Since most private networks are 273 protected by firewalls, Mobile IP must provide a means for signalling 274 and traffic to pass these firewalls. 276 Larger private networks may provide their own home agents, but there is 277 also the case where one operator provides a home agent which is shared 278 by several smaller private networks. Then, a mobile node may want access 279 to a private network which is not its home network. In this case, we 280 recognize a need for, for instance, the VPN Identifier Extension in the 281 registration request [9]. The NAI of a mobile user points out the home 282 network of the user and the VPN Identifier Extension points out the final 283 destination of the tunnel. 285 The requirements for support of private networks are: 287 1. Support of private address spaces MUST be included in Mobile IP. 289 2. Mobile IP MUST provide a means for signalling and traffic to pass 290 through firewalls. 292 3. Mobile IP MUST provide a means for a mobile node, or an agent 293 generating registration requests on behalf of a mobile node, to request 294 access to a network which is not the home network of the mobile node. 296 6. Reverse tunnelling 298 The Mobile IP protocol, as specified in [20], is built on the concept 299 of triangular routing. Reverse tunnelling has been suggested as an 300 addition to Mobile IP, to support topologically correct reverse tunnels 301 [19]. For reasons of security and charging, it must be possible for a 302 network operator to employ reverse tunnelling, and to refuse mobile 303 nodes, or agents generating registration requests on behalf of mobile 304 nodes, which do not request reverse tunnelling when required. It must 305 also be possible to employ encryption of the traffic with reverse 306 tunnelling. Lastly, it should be possible to choose how to employ 307 reverse tunnelling: all the way to the home agent, or to a firewall or 308 gateway somewhere between the foreign agent and the home agent. 310 The requirements for reverse tunnelling are: 312 1. It MUST be possible to employ reverse tunnelling together with Mobile 313 IP. 315 2. A network operator MUST be able to refuse mobile nodes, or agents 316 generating registration requests on behalf of mobile nodes, which do not 317 request reverse tunnelling. 319 7. Route optimization 321 New access techniques are expected to give users significantly more 322 bandwidth than today, which will lead to more traffic in the backbone 323 networks. Thus, it is important to minimize the load on the backbone, 324 as well as the delay, through efficient routing. In the Mobile IP 325 protocol, datagrams destined to a mobile node are sent to its home 326 address and are tunnelled by the home agent to the current care-of 327 address [20]. Route optimization is a suggested addition, which allows 328 correspondent nodes to send datagrams directly to a mobile node 329 [22][21]. In order to minimize the delay, and to optimize the 330 utilization of network resources, it must be possible for an operator 331 to employ route optimization. Especially, this would improve the 332 performance for two mobile nodes located in a visited network, which are 333 communicating with each other. 335 The authentication procedure for route optimization must be according 336 to the generic authentication procedure for Mobile IP, and there must 337 be a secure way to distribute information of the current address of a 338 mobile node. If requested, encryption must also be ensured for the 339 traffic. Integrated and differentiated services [4][5][23][24] do not 340 always handle the change from triangular to optimized routing in a 341 smooth way, and Mobile IP extensions or changes may be needed. Lastly, 342 choosing the optimal route, with respect to the number of hops, may 343 result in a lower level of quality of service. In order to maintain a 344 negotiated quality of service, the quality-of-service mechanisms may 345 need to interact with the route optimization mechanisms. 347 The requirements for route optimization are: 349 1. It MUST be possible to employ route optimization together with Mobile 350 IP. 352 8. Dynamic home address assignment 354 In many networks, including home networks of mobile nodes, addresses are 355 assigned dynamically. Dynamic address assignment provides a means to 356 better utilize the IP addresses in a network. It must be possible to 357 assign an address to a mobile node, which belongs to a home network that 358 usually employs dynamic address assignment. Furthermore, if the home 359 agent is dynamically assigned, the home address needs to be dynamically 360 assigned as well, since the home address must belong to the same sub- 361 network as the home agent [20]. A solution for dynamic home address 362 assignment was proposed in [12]. 364 The requirements for dynamic home address assignment are: 366 1. Dynamic home address assignment MUST be included in Mobile IP. 368 9. Temporary home 370 According to Mobile IP, as specified in [20], the home agent is allocated 371 in the home network. However, mobile users may have a need for a 372 temporary home, not necessarily through a home agent assigned in the 373 home network. The need could be to have an anchor point for some period 374 of time, and the most optimal solution, considering routing performance, 375 would be to have a home agent dynamically assigned in the visited 376 network. 378 It must be possible for a mobile node, or an agent generating 379 registration requests on behalf of a mobile node, to request and obtain 380 a dynamically assigned home agent in the home network or in the visited 381 network. It should also be possible for a mobile node which has obtained 382 a dynamically assigned home agent in a visited network, to keep this 383 home agent when moving to another network. A solution for dynamic home 384 agent assignment, fulfilling these requirements, has been suggested in 385 [13]. 387 The requirements for a temporary home solution are: 389 1. It MUST be possible for a mobile node, or an agent generating 390 registration requests on behalf of a mobile node, to request and be 391 assigned a dynamic home agent either in the home network or in the 392 visited network. 394 2. A mobile node which has been assigned a dynamic home agent in a 395 visited network SHOULD be able to keep this home agent when moving to 396 another network. 398 10. Handover performance 400 Mobile IP, as specified in [20], does not provide seamless/loss-less 401 handover between different foreign agents within the same administrative 402 domain. The existing solution may be acceptable for certain non-delay- 403 sensitive and loss-tolerant applications, but needs to be improved in 404 order to support for instance real-time applications. 406 There have been suggestions on how to improve the handover performance, 407 in terms of making the signalling procedure faster [8][14][15][22]. 408 However, the handover performance still needs to be improved in order 409 to support for instance real-time applications, or to support loss-less 410 handover. 412 11. Conclusions 414 This draft provides a list of requirements on Mobile IPv4 for use in 415 cellular networks. Beside the general requirements on functionality and 416 security, there are specific requirements on authentication, address 417 assignment, routing and issues providing interworking with existing 418 cellular solutions. 420 All the requirements provided in this draft may not be necessary in a 421 first step of introducing Mobile IP in cellular networks. However, we 422 believe that they all need to be considered to eventually support all 423 various demands from different operators and end users. The requirements 424 list will also be extended for Mobile IPv6. 426 12. Intellectual property considerations 428 Ericsson has a patent US 5708655 which might be relevant to the issues 429 considered in this document. If access to this patent should become 430 necessary for implementing any standard or standards proposal based on 431 this document, Ericsson is willing to license this patent and any 432 foreign counterparts on fair and reasonable terms and conditions to 433 anybody for such use. If somebody asking for such a license from Ericsson 434 owns or controls a patent also necessary for implementing the standard, 435 Ericsson consider fair and reasonable terms and conditions to include a 436 grant back license on such patent and any foreign counterparts. For the 437 avoidance of doubt Ericsson supports the handling of IPR issues 438 according to RFC 2026 [7]. 440 13. Acknowledgements 442 The authors would like to thank Henrik Basilier, Martin Korling, Lars 443 Westberg, Anders Herlitz, Yuri Ismailov, Ulf Olsson, Thomas Eklund and 444 Georg Chambert at Ericsson for their valuable comments. 446 14. References 448 [1] B. Aboba: "Support for Mobile IP in Roaming", Internet draft 449 (expired), draft-ietf-roamops-mobileip-01.txt, March 1998. 451 [2] B. Aboba, M. Beadles: "The Network Access Identifier", RFC 2486, 452 January 1999. 454 [3] C.B. Becker, B. Patil, E. Qaddoura: "IP Mobility Architecture 455 Framework", Internet draft (work in progress), draft-ietf-mobileip-ipm- 456 arch-00, February 1999. 458 [4] S. Blake, Editor: "A Framework for Differentiated Services", 459 Internet draft (work in progress), draft-ietf-diffserv-framework-01, 460 October 1998. 462 [5] S. Blake, Editor: "An Architecture for Differentiated Services", RFC 463 2475, December 1998. 465 [6] S. Bradner: "Key words for use in RFCs to Indicate Requirements 466 Levels", RFC 2119, March 1997. 468 [7] S. Bradner: "The Internet Standards Process -- Revision 3", RFC 469 2026, October 1996. 471 [8] P.R. Calhoun, G. Montenegro, C.E. Perkins: "Mobile IP Regionalized 472 Tunnel Management", Internet draft (work in progress), draft-ietf- 473 mobileip-reg-tunnel-00.txt, November 1998. 475 [9] P.R. Calhoun, G. Montenegro, C.E. Perkins: "Tunnel Establishment 476 Protocol", Internet draft (expired), draft-ietf-mobileip-calhoun-tep- 477 01.txt, March 1998. 479 [10] P.R. Calhoun, C.E. Perkins: "DIAMETER Mobile IP Extensions", 480 Internet draft (work in progress), draft-calhoun-diameter-mobileip- 481 01.txt, November 1998. 483 [11] P.R. Calhoun, C.E. Perkins: "Mobile IP Challenge/Response 484 Extensions", Internet draft (work in progress), draft-ietf-mobileip- 485 chal-01.txt, February 1999. 487 [12] P.R. Calhoun, C.E. Perkins: "Mobile IP Dynamic Home Address 488 Allocation Extension", Internet draft (work in progress), draft-ietf- 489 mobileip-home-addr-alloc-00.txt, November 1998. 491 [13] P.R. Calhoun, C.E. Perkins: "Mobile IP Foreign Agent 492 Challenge/Response Extension", Internet draft (work in progress), 493 draft-ietf-mobileip-challenge-00.txt, November 1998. 495 [14] M. Chuah, A. Yan, Y. Li: "Distributed Registrations Enhancements 496 to Mobile IP", Internet draft (work in progress), draft-chuali-mobileip- 497 dremip-02.txt, November 1998. 499 [15] S.F. Foo, K.C. Chua: "Regional Aware Foreign Agent (RAFA) for Fast 500 Local Handoffs", Internet draft (work in progress), draft-chuafoo- 501 mobileip-rafa-00.txt, November 1998. 503 [16] E. Gustafsson, A. Herlitz, A. Jonsson, M. Korling: "UMTS/IMT-2000 504 and Mobile IP/DIAMETER Harmonization", Internet draft (work in 505 progress), draft-gustafsson-mobileip-imt-2000-00.txt, November 1998. 507 [17] T. Hiller, Editor: "3G Wireless Data Provider Architecture Using 508 Mobile IP and AAA", Internet draft (work in progress), draft-hiller- 509 3Gwireless-00.txt, March 1999. 511 [18] D.B. Johnson, C. Perkins: "Mobility Support in IPv6", Internet 512 draft (work in progress), draft-ietf-mobileip-ipv6-07.txt, November 513 1998. 515 [19] G. Montenegro: "Reverse Tunneling for Mobile IP", RFC 2344, May 516 1998. 518 [20] C. Perkins, Editor: "IP Mobility Support", RFC 2002, October 1996. 520 [21] C. Perkins, D.B. Johnson: "Registration Keys for Route 521 Optimization", Internet draft (expired), draft-ietf-mobileip-regkey- 522 00.txt, November 1997. 524 [22] C. Perkins, D.B. Johnson: "Route Optimization in Mobile IP", 525 Internet draft (work in progress), draft-ietf-mobileip-optim-08.txt, 526 February 1999. 528 [23] S. Shenker, J. Wroclawski: "General Characterization Parameters for 529 Integrated Service Network Elements", RFC 2215, September 1997. 531 [24] S. Shenker, J. Wroclawski: "Network Element Service Specification 532 Template", RFC 2216, September 1997. 534 [25] J.K. Zao, M. Condell: "Use of IPSec in Mobile IP", Internet draft 535 (expired), draft-ietf-mobileip-ipsec-use-00.txt, November 1997. 537 15. Author's address 539 Eva Gustafsson, Annika Jonsson 540 Ericsson Radio Systems AB 541 Network and Systems Research 542 SE-164 80 Stockholm 543 SWEDEN 545 {eva.m.gustafsson | annika.jonsson}@era.ericsson.se 547 Elisabeth Hubbard, Jonas Malmkvist, Anders Roos 548 Telia Research AB 549 Network Research 550 Vitsandsgatan 9 551 SE-123 86 Farsta 552 SWEDEN 554 {elisabeth.a.hubbard | jonas.x.malmkvist | anders.g.roos}@telia.se 556 Expires October 1999