idnits 2.17.1 draft-ietf-mobileip-cellular-requirements-00.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 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 11 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 4 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 (August 1999) is 9018 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) == Outdated reference: A later version (-02) exists of draft-ietf-diffserv-framework-01 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-00 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' == 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. '10' -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-07 ** Obsolete normative reference: RFC 2344 (ref. '13') (Obsoleted by RFC 3024) ** Obsolete normative reference: RFC 2002 (ref. '14') (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. '15' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-07 -- Possible downref: Normative reference to a draft: ref. '16' ** Downref: Normative reference to an Informational RFC: RFC 2216 (ref. '18') -- Possible downref: Normative reference to a draft: ref. '19' Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 14 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 INTERNET-DRAFT February 1999 3 Expires August 1999 4 Annika Jonsson, Ericsson 5 Elisabeth Hubbard, Telia 6 Jonas Malmkvist, Telia 7 Anders Roos, Telia 9 Requirements on Mobile IP from a Cellular Perspective 10 12 Status of this memo 14 This document is a submission by the Mobile IP Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the mobile-ip@smallworks.com mailing list. Distribution of this 17 memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The increasing interest in Mobile IP as a potential macro-mobility 39 solution for cellular networks leads to new solutions and extensions 40 to the existing protocol. There is also a need to put together the 41 demands on Mobile IP, from a cellular perspective, in order to 42 harmonize the evolution of Mobile IP and the existing mobility 43 solutions in cellular networks. 45 This draft lists a first set of requirements on Mobile IP for use in 46 cellular networks, for instance IMT-2000, and relates the requirements 47 to proposed solutions. These requirements consider Mobile IPv4, but 48 the list will be extended for Mobile IPv6 as well. 50 Table of contents 52 1. Introduction......................................................2 53 2. General requirements..............................................3 54 3. Authentication....................................................4 55 4. Surrogate registrations...........................................5 56 5. Private networks..................................................6 57 6. Reverse tunnelling................................................6 58 7. Route optimization................................................7 59 8. Dynamic home address assignment...................................8 60 9. Dynamic home agent assignment.....................................8 61 10. Handover performance.............................................8 62 11. Conclusions......................................................9 63 12. Acknowledgements.................................................9 64 13. References.......................................................9 65 14. Author's address................................................11 67 1. Introduction 69 Recently, there has been an increasing interest in Mobile IP as a 70 potential future mobility standard, common to cellular systems and the 71 Internet as a whole [11]. The benefits of adopting a common mobility 72 solution would include independence of access network technologies, 73 common solutions for fixed and wireless networks, and ultimately a 74 world-wide acknowledged mobility standard. 76 The purpose of this document is to state a first version of the 77 requirements on Mobile IP as a potential macro-mobility solution for 78 cellular networks. The requirements in this document mainly refer to 79 Mobile IPv4 [14] and its extension drafts, but the list of requirements 80 will be extended for Mobile IPv6 [12] as well. 82 One important aspect on the requirements is the compatibility with 83 existing solutions, for instance the GPRS Tunnelling Protocol (GTP). The 84 General Packet Radio Service (GPRS) will be deployed in GSM cellular 85 mobile systems starting 1999, giving IP mobility service to potentially 86 hundreds of millions of users. The GSM/GPRS standard is evolving into 87 the third generation systems: Universal Mobile Telecommunication System 88 (UMTS) and the Enhanced Data rates for GSM Evolution (EDGE). These will, 89 like Cdma2000, fulfil the ITU requirements for third generation mobile 90 systems, IMT-2000. 92 We start in Section 2 by describing some general requirements for IP 93 mobility in cellular networks. Then we list more specific requirements 94 in Section 3 through Section 10. Section 11 concludes the document. 96 2. General requirements 98 To allow Mobile IP to be a mobility solution which supports many 99 different kinds of access networks/technologies, the Mobile IP 100 functionality shall be independent of the access network technology. For 101 Mobile IP to be deployed in future cellular networks, it also needs to 102 provide compatibility with existing protocols, for instance GTP. 104 Mobile IP provides authentication of the signalling messages [14]. For 105 security reasons, such as keeping the current location of a user unknown 106 to other users, it should also be possible to provide encryption of the 107 Mobile IP signalling. This may be implemented through, for instance, 108 IPSec tunnels and security associations established on a permanent basis 109 inside and between different administrative domains. It should also be 110 possible to provide encryption of the traffic. A solution is to employ 111 IPSec together with Mobile IP, as suggested in [19]. 113 As emerging Internet quality-of-service mechanisms are expected to 114 enable a wide-spread use of real-time services between stationary nodes, 115 for instance voice over IP and videoconferencing, there will be a demand 116 for using the same kind of services when being mobile. Promising a 117 certain level of quality of service to a mobile user is generally 118 difficult, since there may not be enough resources available in the part 119 of the network that the mobile node is moving into. However, when network 120 resources allow, there should be mechanisms to handle quality of service 121 for mobile users, particularly in case of reverse tunnelling, route 122 optimization and handover. The differences between stationary and mobile 123 nodes making use of quality-of-service mechanisms should also be 124 minimized. An application requesting a quality-of-service level should 125 not need to be mobile aware, and network operators should not need to 126 employ different quality of service platforms for stationary and mobile 127 users. The emerging quality-of-service architectures, Integrated 128 Services and Differentiated Services [3][4][17][18], do not consider 129 mobile nodes. Additions or changes may be needed. 131 Quality-of-service mechanisms enforce a differentiated sharing of 132 bandwidth among different services and different users. Thus, there must 133 be mechanisms available to identify traffic flows with different 134 quality-of-service attributes, and to make it possible to charge the 135 different users accordingly. 137 It is well known that mobile nodes are more complex to handle than 138 stationary ones. Anyway, the extra handling of mobile nodes should be 139 based on the same basic mechanisms as the stationary ones, rather than 140 on separate mechanisms. Among these basic mechanisms are (i) an 141 Authentication, Authorization, Accounting (AAA) infrastructure; (ii) 142 quality of service and policy control; and (iii) directory services and 143 gateway services like IP telephony. 145 Lastly, as more and more users become mobile, the need for a uniform 146 service delivery across various access technologies increases. 148 Ultimately, the user should not need to know what kind of access 149 technology is in use at a particular moment. When bandwidth and other 150 network capabilities allow, IP-based services should appear the same way 151 independently of the access technology. Moreover, a normal user will try 152 to employ the most efficient access, considering capacity and cost, 153 which means that changes of access technology can be expected during 154 active sessions. Thus, the change of access technology should be as 155 smooth and as transparent to the user as possible. 157 These are the general requirements; some of them apply to Mobile IP and 158 some may be fulfilled through other protocols and solutions. The 159 following sections address more specific requirements on Mobile IP for 160 use in a cellular environment, in order to provide solutions 161 satisfactory for operators as well as end users. 163 3. Authentication 165 The authentication of a mobile node or user can be performed at different 166 locations and be based upon different parameters. We may also consider 167 two phases of the authentication procedure: initial or full 168 authentication and subsequent authentications. Full authentication is 169 performed when the existing security associations are insufficient, for 170 instance at initial registration, or when a mobile node requests a new 171 home agent. Subsequent authentications are performed at handover, that 172 is, when a mobile node changes its point of attachment within the same 173 administrative domain, or to renew bindings before they are timed out. 175 The Mobile IP protocol specifies registrations to be performed at the 176 home agent, and to be based on the home IP address of the mobile node 177 [14]. However, additional solutions and extensions to Mobile IP have 178 introduced identification and authentication based on the Network Access 179 Identifier (NAI) [1][2][5][6][7][8][9]. Basing the authentication on 180 the IP address means that it is the host that is authenticated, while 181 authentication based on the NAI results in authentication of the mobile 182 user. The latter alternative would alleviate the connection between a 183 specific user and a specific host, and provide a secure way for dynamic 184 allocation of IP addresses. Therefore, we advocate the full 185 authentication to be based on a unique user identity, for example the 186 NAI. 188 Furthermore, the full authentication should not be performed at the home 189 agent, since the home agent may be dynamically allocated. Instead, it 190 should be performed at the home network or home administrative domain 191 as suggested in [5][7], for instance through AAA functionality. 193 For reasons of subscription handling and charging, the full 194 authentication should always be performed at the home domain or by the 195 home operator, that is, where the user has its subscription. However, 196 once a mobile node is connected to a visited network, performing 197 subsequent authentications at the home domain could result in 199 significant signalling delay. To minimize the signalling delay, and to 200 reduce the signalling between the visited and the home network, it 201 should be possible to perform subsequent authentications in the visited 202 network, as described in [5]. 204 Finally, since the Mobile IP protocol shall allow independence of the 205 access network technology, the Mobile IP authentication should be 206 independent of the authentication for the access, for instance the radio 207 resources. A separation of the authentication procedures is motivated 208 by the fact that radio resources are scarce, and an access network 209 operator may not want to allow Mobile IP signalling until the access 210 network in itself has accepted to provide resources for a mobile node. 211 Also, different access networks with, for instance, radio-based or fixed 212 access, experience different types of security threats, and may address 213 them differently. 215 The requirements for the authentication procedure are: 217 1. It should be possible to perform Mobile IP authentication without 218 interaction with the access network / radio resources. 220 2. There must be a generic Mobile IP authentication procedure, 221 specifying full and subsequent authentication, as well as authentication 222 for surrogate registrations. 224 3. Full authentication must be performed with the home network, the 225 home administrative domain or with the home operator of the mobile user. 227 4. There must be a unique user identity for full authentication, for 228 instance the NAI [2]. 230 5. It should be possible to perform subsequent authentication locally 231 at the visited network. 233 6. Mobile IP should use the same authentication infrastructure as 234 stationary Internet nodes. 236 4. Surrogate registrations 238 In access networks that have sufficient lower-level signalling, Mobile 239 IP registrations between the mobile node and the foreign agent are 240 unnecessary. Such situations are supported by surrogate registrations 241 as described in [6]. 243 For reasons of backward compatibility with existing systems, it must be 244 possible to implement Mobile IP, for instance in GPRS networks, without 245 introducing Mobile IP signalling in the terminal. Surrogate 246 registrations provide such a solution. They also provide a means to 247 minimize the signalling over the radio link, and shall therefore be 248 included in Mobile IP. 250 The requirements for surrogate registrations are: 252 1. It must be possible to employ Mobile IP in a network without 253 introducing Mobile IP signalling in the terminal. 255 2. Secure full and subsequent authentication for surrogate 256 registrations must be ensured according to the generic authentication 257 procedure for Mobile IP. 259 5. Private networks 261 Since private networks are an important part of the communication 262 network structure, Mobile IP must support private networks and private 263 address spaces. A proposed solution is to support private address spaces 264 through proxy home and foreign agents [5]. This solution also supports 265 hierarchical foreign agents within a network. Such a hierarchy may be 266 valuable in order to improve handover performance. It may also be 267 important for security reasons, since it allows the existence of agents 268 without direct connection to external agents, that is, agents external 269 to for instance a private network. Since most private networks are 270 protected by firewalls, Mobile IP must provide a means for signalling 271 and traffic to pass these firewalls. 273 Larger private networks may provide their own home agents, but there is 274 also the case where one operator provides a home agent which is shared 275 by several smaller private networks. Then, a mobile node may want access 276 to a private network which is not its home network. In this case, we 277 recognize a need for the VPN Identifier Extension in the registration 278 request [6]. The NAI of a mobile user points out the home network of the 279 user and the VPN Identifier Extension points out the final destination 280 of the tunnel. 282 The requirements for support of private networks are: 284 1. Support of private address spaces must be included in Mobile IP. 286 2. Mobile IP must support proxy agents and hierarchical agents. 288 3. Mobile IP must provide a means for signalling and traffic to pass 289 through firewalls. 291 4. The VPN Identifier Extension must be supported in Mobile IP. 293 6. Reverse tunnelling 295 The Mobile IP protocol, as specified in [14], is built on the concept 296 of triangular routing. Reverse tunnelling has been suggested as an 297 addition to Mobile IP, to support topologically correct reverse tunnels 299 [13]. For reasons of security and charging, it must be possible for a 300 network operator to employ reverse tunnelling, and to refuse mobile 301 nodes, or surrogate agents, which do not request reverse tunnelling when 302 required. It must also be possible to employ encryption of the traffic 303 with reverse tunnelling. In the case of private networks, it should be 304 possible to choose how to employ reverse tunnelling: all the way to the 305 home agent, to the proxy home agent, or only to the proxy foreign agent. 307 The requirements for reverse tunnelling are: 309 1. It must be possible to employ reverse tunnelling together with Mobile 310 IP. 312 2. A network operator must be able to refuse mobile nodes, or surrogate 313 agents, which do not request reverse tunnelling when required. 315 3. With private networks, it should be possible to employ reverse 316 tunnelling to the home agent, to the proxy home agent or to the proxy 317 foreign agent. 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 through efficient routing. In the Mobile IP protocol, datagrams destined 325 to a mobile node are sent to its home address and are tunnelled by its 326 home agent to the current care-of address [14]. Route optimization is a 327 suggested addition to Mobile IP, which allows correspondent nodes to 328 send datagrams directly to a mobile node [16][15]. In order to minimize 329 the delay, and to optimize the utilization of network resources, it 330 shall be possible for an operator to employ route optimization. 331 Especially, this would improve the performance for two mobile nodes 332 located in a visited network, which are communicating with each other. 334 The authentication procedure for route optimization must be according 335 to the generic authentication procedure for Mobile IP, and there must 336 be a secure way to distribute information of the current address of a 337 mobile node. If requested, encryption must also be ensured for the 338 traffic. Integrated and Differentiated services [3][4][17][18] do not 339 always handle the change from triangular to optimized routing in a 340 smooth way. Mobile IP extensions or changes may be needed. Lastly, 341 choosing the optimal route, with respect to the number of hops, may 342 result in a lower level of quality of service. In order to maintain a 343 negotiated quality of service, the quality-of-service mechanisms may 344 need to interact with the route optimization mechanisms. 346 The requirements for route optimization are: 348 1. It must be possible to employ route optimization together with Mobile 349 IP. 351 2. It should be possible to employ quality-of-service mechanisms 352 together with route optimization. 354 8. Dynamic home address assignment 356 A solution for dynamic home address assignment is proposed in [8]. 357 Dynamic assignment of the home address provides a means to better 358 utilize the IP addresses at the home sub-network. Moreover, in case the 359 home agent is dynamically assigned the home address needs to be 360 dynamically assigned as well, since the home address must belong to the 361 same sub-network as the home agent [14]. The dynamic assignment of home 362 addresses is in conflict with the use of the home address as the mobile 363 node identifier in [14], and a different identifier is required. In [8], 364 the NAI is employed for identification. 366 The requirements for dynamic address assignment are: 368 1. Dynamic home address assignment must be included in Mobile IP. 370 9. Dynamic home agent assignment 372 In addition to dynamically assigned home addresses, there is a need for 373 dynamic allocation of the home agent. A dynamically allocated home agent 374 in the visited network can, for instance, improve the routing 375 performance. It shall be possible for a mobile node, or a surrogate 376 agent, to request and obtain a dynamically assigned home agent in the 377 home network or in the visited network. It shall also be possible for a 378 mobile node which has obtained a dynamically assigned home agent in a 379 visited network, to keep this home agent when moving to another network. 380 A solution for dynamic home agent assignment, fulfilling these 381 requirements, has been suggested in [9]. 383 The requirements for dynamic home agent assignment are: 385 1. Dynamic home agent assignment must be included in Mobile IP. 387 2. It must be possible for a mobile node, or a surrogate agent, to 388 request and be assigned a dynamic home agent either in the home network 389 or in the visited network. 391 3. A mobile node which has been assigned a dynamic home agent in a 392 visited network must be able to keep this home agent when moving to 393 another network. 395 10. Handover performance 397 Mobile IP, as specified in [14], does not provide seamless/loss-less 398 handover between different foreign agents within the same administrative 399 domain. The existing solution may be acceptable for certain non-delay- 400 sensitive and loss-tolerant applications, but needs to be improved in 401 order to support for instance real-time applications. 403 There have been suggestions on how to improve the handover performance, 404 in terms of making the signalling procedure faster [5][10][16]. However, 405 the handover performance still needs to be improved in order to support 406 for instance real-time applications, or to support loss-less handover. 408 The requirements for handover are: 410 1. The handover performance, in terms of loss and delay, must be 411 improved to support real-time and loss-sensitive applications. 413 11. Conclusions 415 This draft provides a first list of requirements on Mobile IPv4 for use 416 in cellular networks, such as IMT-2000. Beside the general requirements 417 on functionality and security, there are specific requirements on 418 authentication, address assignment, routing and issues providing 419 backward compatibility to existing solutions, for instance GTP. 421 All the requirements provided in this draft may not be necessary in a 422 first step of introducing Mobile IP in cellular networks. However, we 423 believe that they all need to be considered to eventually support all 424 various demands from different operators and end users. The requirements 425 list will also be extended for Mobile IPv6. 427 12. Acknowledgements 429 The authors would like to thank Henrik Basilier, Martin Korling, Lars 430 Westberg, Anders Herlitz, Yuri Ismailov, Ulf Olsson, Thomas Eklund and 431 Georg Chambert at Ericsson for their valuable comments. 433 13. References 435 [1] B. Aboba: "Support for Mobile IP in Roaming", Internet draft 436 (expired), draft-ietf-roamops-mobileip-01.txt, March 1998. 438 [2] B. Aboba, M. Beadles: "The Network Access Identifier", RFC 2486, 439 January 1999. 441 [3] S. Blake, Editor: "A Framework for Differentiated Services", 442 Internet draft (work in progress), draft-ietf-diffserv-framework-01, 443 October 1998. 445 [4] S. Blake, Editor: "An Architecture for Differentiated Services", RFC 446 2475, December 1998. 448 [5] P.R. Calhoun, G. Montenegro, C.E. Perkins: "Mobile IP Regionalized 449 Tunnel Management", Internet draft (work in progress), draft-ietf- 450 mobileip-reg-tunnel-00.txt, November 1998. 452 [6] P.R. Calhoun, G. Montenegro, C.E. Perkins: "Tunnel Establishment 453 Protocol", Internet draft (expired), draft-ietf-mobileip-calhoun-tep- 454 01.txt, March 1998. 456 [7] P.R. Calhoun, C.E. Perkins: "DIAMETER Mobile IP Extensions", 457 Internet draft (work in progress), draft-calhoun-diameter-mobileip- 458 01.txt, November 1998 460 [8] P.R. Calhoun, C.E. Perkins: "Mobile IP Dynamic Home Address 461 Allocation Extension", Internet draft (work in progress), draft-ietf- 462 mobileip-home-addr-alloc-00.txt, November 1998. 464 [9] P.R. Calhoun, C.E. Perkins: "Mobile IP Foreign Agent 465 Challenge/Response Extension", Internet draft (work in progress), 466 draft-ietf-mobileip-challenge-00.txt, November 1998. 468 [10] M. Chuah, A. Yan, Y. Li: "Distributed Registrations Enhancements 469 to Mobile IP", Internet draft (work in progress), draft-chuali-mobileip- 470 dremip-02.txt, November 1998. 472 [11] E. Gustafsson, A. Herlitz, A. Jonsson, M. Korling: "UMTS/IMT-2000 473 and Mobile IP/DIAMETER Harmonization", Internet draft (work in 474 progress), draft-gustafsson-mobileip-imt-2000-00.txt, November 1998. 476 [12] D.B. Johnson, C. Perkins: "Mobility Support in IPv6", Internet 477 draft (work in progress), draft-ietf-mobileip-ipv6-07.txt, November 478 1998. 480 [13] G. Montenegro: "Reverse Tunneling for Mobile IP", RFC 2344, May 481 1998. 483 [14] C. Perkins, Editor: "IP Mobility Support", RFC 2002, October 1996. 485 [15] C. Perkins, D.B. Johnson: "Registration Keys for Route 486 Optimization", Internet draft (expired), draft-ietf-mobileip-regkey- 487 00.txt, November 1997. 489 [16] C. Perkins, D.B. Johnson: "Route Optimization in Mobile IP", 490 Internet draft (expired), draft-ietf-mobileip-optim-07.txt, November 491 1997. 493 [17] S. Shenker, J. Wroclawski: "General Characterization Parameters for 494 Integrated Service Network Elements", RFC 2215, September 1997. 496 [18] S. Shenker, J. Wroclawski: "Network Element Service Specification 497 Template", RFC 2216, September 1997. 499 [19] J.K. Zao, M. Condell: "Use of IPSec in Mobile IP", Internet draft 500 (expired), draft-ietf-mobileip-ipsec-use-00.txt, November 1997. 502 14. Author's address 504 Eva Gustafsson, Annika Jonsson 505 Ericsson Radio Systems AB 506 Network and Systems Research 507 SE-164 80 Stockholm 508 SWEDEN 510 {eva.m.gustafsson | annika.jonsson}@era.ericsson.se 512 Elisabeth Hubbard, Jonas Malmkvist, Anders Roos 513 Telia Research AB 514 Network Research 515 Vitsandsgatan 9 516 SE-123 86 Farsta 517 SWEDEN 519 {elisabeth.a.hubbard | jonas.x.malmkvist | anders.g.roos}@telia.se 521 Expires August 1999