idnits 2.17.1 draft-le-aaa-mipv6-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 0) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 30 has weird spacing: '... It is inapp...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Since Mobile IPv6 does not have a Foreign Agent and mobility support in the protocol is different (i.e. MN directly sends Binding Updates directly to the home agent and correspondent nodes), these requirements do not apply for MIPv6 and SHOULD not be considered. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 526, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 541, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 554, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 558, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 3588 (ref. '6') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Stefano M. Faccin 3 INTERNET-DRAFT Franck Le 4 Date: February 2004 Basavaraj Patil 5 Expires: August 2004 Charles E. Perkins 6 Nokia Research Center 8 Francis Dupont 9 ENST Bretagne 11 Maryline Laurent-Maknavicius 12 Julien Bournelle 13 INT Evry 15 Mobile IPv6 Authentication, Authorization, and Accounting Requirements 16 18 Status of This Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes the motivation why Diameter support for 42 Mobile IPv6 is required and needs to be developped. It analyses the 43 requirements expressed in RFC 2977 which was written both for MIPv4 44 and MIPv6; and it finally updates the IPv6 requirements for the AAA 45 support for Mobile IPv6 to reflect the latest modifications and 46 evolution of the Mobile IP, AAA and other relevant working groups. 48 Table of Contents 50 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 52 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Basic model . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Modifications to basic model . . . . . . . . . . . . . . . . 5 60 3.2. AAA Protocol Roaming Requirements . . . . . . . . . . . . . 6 62 4. Requirements related to basic IP connectivity . . . . . . . . . . 6 64 5. AAA for Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Attendant functionnality . . . . . . . . . . . . . . . . . . 7 66 5.2. Security associations . . . . . . . . . . . . . . . . . . . 8 67 5.3. Authentication and key distribution mechanisms. . . . . . . 8 68 5.4. Integration of Mobile IP and AAA procedures . . . . . . . . 9 69 5.5. Home agent allocation . . . . . . . . . . . . . . . . . . . 10 71 6. Security considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Mobile IP defines a method that allows a Mobile Node to change its 79 point of attachment to the Internet with minimal service disruption. 80 But Mobile IP in itself does not provide any specific support for 81 mobility across different administrative domains, which limits the 82 applicability of Mobile IP in a large-scale commercial deployment. 84 AAA protocols such as Diameter precisely enable mobile users to roam 85 and obtain service in networks that may not necessarily be owned by 86 their home service provider. For Mobile IP to be deployed in 87 commercial networks, there therefore has to be AAA support for the 88 protocol. 90 RFC 2977 [1] describes the requirements that have to be supported by 91 a AAA service to aid in Mobile IP services; and Diameter extensions 92 for Mobile IPv4 [2] have already been specified allowing a MIPv4 node 93 to receive services from service providers (home and foreign) and 94 allowing the Diameter servers to authenticate, authorize and collect 95 accounting information for those MIPv4 nodes. 97 Even though MIPv4 and MIPv6 are similar when observed at high level, 98 the two protocols are actually quite different when considering the 99 support for Inter Domain deployment. Mobile IPv6 e.g. does not have 100 the equivalent of a Foreign Agent as defined in Mobile IPv4, and as a 101 result does not offer any mechanism by which the visited network can 102 authenticate and authorize access to the network. In addition, 103 extending the Diameter Mobile IPv4 Application to support Mobile IPv6 104 will reduce the flexibility and result in some AAA capability 105 exchange issues: it will be difficult to differentiate which AAA 106 nodes support only Mobile IPv4, which ones support only Mobile IPv6 107 and which ones support both. 109 Some Diameter Mobile IPv6 Application will have to be specified to 110 allow Mobile IPv6 nodes to receive services from foreign domains. 111 Such application will allow: 113 * local network access control: cf section 3 115 * remote network access control: cf section 3 117 * credentials/trusted third party: the AAA server act as trusted 118 third party allowing user authentication and key distribution. 120 * MN-Attendant LSA establishment: cf section 3.1 122 * home address allocation 123 * home agent allocation (cf. 4.5): eventhough Mobile IPv6 124 specifies a dynamic home agent assignement procedure, the AAA 125 servers allow a secure and efficient alternative method. 127 * transport of messages for MN-HA SA establishment by AAA 129 * key distribution for MN-HA SA establishment (need a higher 130 level of trust than for the previous) 132 * transport of MN-HA mobility signaling messages (need the two 133 previous items) 135 But before designing the solution, this document describes the Mobile 136 IPv6 AAA requirements: RFC 2977 [1] describes the requirements for 137 both Mobile IPv4 and Mobile IPv6 and this document will therefore be 138 taken as the base. But since that time, many changes have happened in 139 the IETF, different mechanisms have been defined and many 140 modifications have ocurred in the Mobile IP and AAA working Groups; 141 this draft will thus update the requirements to reflect those latest 142 modifications for the Mobile IPv6/AAA requirements. 144 In RFC 2977 [1], after a description of the model, the requirements 145 were presented in a progressive fashion: 147 - Requirements based on the general model 149 - Requirements based on providing IP service for mobile nodes 151 - Requirements derived from specific Mobile IP needs 153 This document will take the same structure, updating the requirements 154 for the IPv6 specific case, and taking into account the latest 155 amendments of the working groups. 157 2. Terminology 159 This document frequently uses the following terms in addition to 160 those defined in RFC 2977: 162 Home Domain 163 A Home Domain is the administrative domain with whom the user 164 maintains an account relationship. 166 Foreign Domain 167 An administrative domain, visited by a Mobile IP client, and 168 containing the AAA infrastructure needed to carry out the 169 necessary operations enabling network access and Mobile IP 170 registrations. 172 Attendant 173 The attendant is the entity that extracts identification and 174 authorization data sent by the client and forwards them to AAAL 175 for verification. 177 AAAL 178 The AAA server in the foreign domain that mediates local access 179 to the AAA infrastructure. 181 AAAH 182 The AAA server in the home domain which is able to authorize 183 each of its clients. 185 Credential 186 Data provided by a client to the AAA server in a message 187 authentication code constructed using a secret shared between 188 the client and AAAH. 190 Local Security Association 191 Security association shared between the client and the foreign 192 domain. The sharing of such SA gives the foreign domain 193 significant local control over the authentication of a roaming 194 client: Local Security Association e.g. allows the foreign 195 domain to authenticate the user and perform key distribution 196 without involvement of any external authority such as the 197 client's home domain. LSA can thus allow optimizations in terms 198 of signaling load towards the external authorities and delay 199 involved in the security procedures. 201 Key distribution 202 Process or protocol whereby a shared secret becomes available 203 to two or more parties for subsequent crytographic use. 205 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 206 recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 207 described in RFC 2119 [11]. 209 3. Basic model 211 The Basic Model described in RFC 2977 [1] still applies: 213 When a client belonging to one administrative domain (called the 214 home domain) roams to another administrative domain (called the 215 foreign domain) and needs to use the local network resources, an 216 attendant in the foreign domain is likely to require that the 217 client provides some credentials that can be authenticated before 218 access to the resources is permitted. These credentials may be 219 something the foreign domain understands, but in most cases they 220 are assigned by, and understood only by the home domain, and may 221 be used for setting up secure channels with the mobile node. 223 The attendant which often does not have direct access to the data 224 needed to complete the transaction will forward the request to the 225 local AAA server. 227 The local AAAL itself may not have enough information stored 228 locally to carry out the verification for the credentials of the 229 client. In such cases, the AAAL has to contact other external 230 authorities such as the AAAH to verify the client's credentials. 232 In many typical cases, the authorization depends only upon secure 233 authentication of the client's credentials. And once the 234 authorization has been obtained by the local authority, and the 235 authority has notified the attendant about the successful 236 negotiation, the attendant can provide the requested resources to 237 the client. 239 Local Domain Home Domain 240 +--------------+ +----------------------+ 241 | +------+ | | +------+ | 242 | | | | | | | | 243 | | AAAL | | | | AAAH | | 244 | | +-------------------+ | | 245 | +---+--+ | | +------+ | 246 | | | | | 247 | | | +----------------------+ 248 +------+ | +---+--+ | 249 | | | | | | C = client 250 | C |- -|- -| A | | A = attendant 251 | | | | | | AAAL = local authority 252 +------+ | +------+ | AAAH = home authority 253 | | 254 +--------------+ 256 Figure 1: AAA Servers in Home and Local Domains 258 Therefore, the Security Association Model and the requirements 259 deduced from this model (RFC 2977 [1] section 3) are still valid for 260 IPv6. 262 +------+ +------+ 263 | | | | 264 | AAAL +--------------+ AAAH | 265 | | | | 266 +---+--+ +--+---+ 267 | | 268 | | 269 +---+--+ +--+---+ 270 C = client | | | | 271 A = attendant | A | | C | 272 AAAL = local authority | | | | 273 AAAH = home authority +------+ +------+ 275 Figure 2: Security Associations 277 3.1. Modifications to basic model 279 A modification to the basic model that is required is the need to 280 support and utilize Local Security Associations. LSAs have been 281 recently introduced in IETF ([3], [5]). After an initial successful 282 authentication of the user through the home domain, LSAs allow the 283 local domain to authenticate the user and perform key distribution 284 without involvement of any external authority such as the client's 285 home domain. LSA can thus allow optimizations in terms of signaling 286 load between network domains and delay caused by security procedures 287 between network domains: the requests can be processed locally and 288 the latency due to the time taken to traverse the wide-area Internet 289 that is likely to separate the AAAL and the AAAH can thus be avoided. 291 Thus, the following requirement is formulated: 293 - LSA ([3], [5]) SHOULD be supported and utilized by AAA in order to 294 support, e.g., user re-registration, user re-authentication, key 295 distribution/refreshment, etc. 297 3.2. AAA Protocol Roaming Requirements 299 The Diameter Mobile IPv6 Application is a new application extension 300 to the Diameter Base Protocol [6]: the retransmission algorithms of 301 the transport mechanism will therefore rely on the already defined 302 ones. 304 Except this remark, all the other requirements described in section 305 3.1 of RFC 2977 [1] are still valid. 307 4. Requirements related to basic IP connectivity 309 Since the usages scenarios described in section 4 of RFC 2977 [1] are 310 still valid, the two main requirements on AAA for IP connectivity are 311 still applicable: 313 - Either AAA server MUST be able to obtain, or to coordinate the 314 allocation of, a suitable IP address for the customer, upon 315 request by the customer 317 - AAA servers MUST be able to identify the client by some means 318 other than its IP address 320 And so are the derived ones such as: 322 - Policy in the home domain may dictate that the home agent instead 323 of the AAAH manages the allocation of the home IP address for the 324 mobile node. AAA servers MUST be able to coordinate the allocation 325 of an IP address for the mobile node at least in this way. 327 In the Diameter Mobile IPv4 Application, clients use the Network 328 Access Identifier (NAI) [7] to identify themselves. In the same way, 329 in MIPv6, Mobiles nodes should use the NAI: AAA servers today 330 identify clients using NAI, and in addition using NAI allows AAAL to 331 easily determine the home domain ("realm") for the client. 333 From these reasons, derives the following requirement: 335 - In the Diameter support for MIPv6, mobiles nodes SHOULD use the 336 NAI 338 5. AAA for Mobile IP 340 Since RFC 2977 [1] was written for both MIPv4 and MIPv6 and the 341 previous sections mainly describe the general, AAA and functional 342 requirements, most of them are still valid for MIPv6. 344 This section analyzes the Mobile IPv6 specific requirements and, as 345 MIPv6 and MIPv4 are quite different when looking at the architectural 346 model(MIPv6 does not e.g. have the equivalent of a Foreign Agent), 347 the main differences are described in this section. 349 5.1. Attendant functionnality 351 As defined in the basic model (section 2), the attendant is 352 responsible for authorization and authentication of the user before 353 giving him access to the local resources. The attendant receives the 354 user's credentials and is in charge of performing the necessary 355 functions to verify it (e.g. translating to the appropriate 356 protocols) but the attendant is not responsible for the address 357 allocation. 359 The attendant MAY interact with a DHCP Server, but instead of the 360 attendant functionality being the address allocation entity as 361 suggested in RFC 2977 [1], it is suggested that the attendant SHOULD 362 be some other agent in the network. Since RFC 2977 [1] was written, 363 several new mechanisms have evolved and new ones have been introduced 364 in IETF, e.g. new working Groups have been created such as PANA. 366 This draft suggest the following requirement for support of Mobile 367 IPv6 by AAA: 369 - AAA SHOULD support different network access protocols (e.g. PANA). 370 The location of the attendant depends on the specific protocol. 371 E.g. in the specific case of PANA, the attendant SHOULD be located 372 in the PANA Agent defined in [3] if such agent is present in the 373 network. 375 5.2. Security associations 377 RFC 2977 [1] requires the AAA servers to be able to perform key 378 distributions, and in particular requires supports for key 379 distribution for the security associations between the Home Agent and 380 the Foreign Agent, and the SA between the Mobile Node and the Foreign 381 Agent. 383 Since Mobile IPv6 does not have a Foreign Agent and mobility support 384 in the protocol is different (i.e. MN directly sends Binding Updates 385 directly to the home agent and correspondent nodes), these 386 requirements do not apply for MIPv6 and SHOULD not be considered. 388 The remaining requirements about key distribution are still valid 389 (support of mobile node-home agent security association, certificate 390 validation, SA distribution, etc.) and SHOULD be supported for Mobile 391 IPv6. 393 In the same way that in MIPv4, a security association is established 394 between the mobile node and the attendant; for MIPv6, it is still 395 relevant to set up a SA between the mobile node and the attendant, 396 more particularly for Local Security Association. 398 5.3. Authentication and key distribution mechanisms. 400 When RFC 2977 [1] was written, the requirements did not specify any 401 particular authentication and key distribution mechanisms. 402 However,the Diameter Mobile IPv4 Application defines a very specific 403 mechanism. 405 In order to make Mobile IPv6 support in AAA flexible and future 406 proof, the following requirement is considered: 408 - for authentication and key distribution, support for Mobile IPv6 409 in AAA SHOULD allow different mechanisms to be supported. 411 EAP provides a more generic mechanism for authentication and the 412 advantages of EAP are explained in RFC2284. Each authentication 413 method (such as CHAP [9], AKA [10], etc.) has its own properties, and 414 different users belonging to different home domains may have 415 different requirements. The adoption of EAP as one of the mechanisms 416 supported by AAA for Mobile IPv6 would provide a wider choice for the 417 AAAH and MN of which authentication method to adopt based on their 418 policies and requirements. 420 As for the key distribution, the Mobile IPv6 support in AAA should 421 also allow different possible protocols and more flexible behavior. 423 For this reason, the following requirement is expressed: 425 - for authentication and key distribution, support for Mobile IPv6 426 in AAA SHOULD allow for AAA to act only as trusted third party. 428 This would allow the MN and the home agent to authenticate each other 429 and perform key distribution with other mechanisms (e.g. IKE) without 430 directly involving AAA. 432 If no SA is shared by MN and HA, an SA MAY be negotiated through AAA 433 exchanges with AAA acting as trusted third party 435 5.4. Integration of Mobile IP and AAA procedures 437 The following requirement is already present in RFC 2977 [1] and 438 still applies to Mobile IPv6: 440 - After the initial registration, the mobile node is authorized to 441 continue using Mobile IP at the foreign domain without requiring 442 further involvement by the AAA servers. 444 This implies that at the initial registration the mobile node needs 445 to be authenticated and authorized, and mobility procedures need to 446 be performed (e.g. between the foreign agent and the home agent) to 447 guarantee the mobile node can use Mobile IP. 449 Initial registration may take a long time, e.g. if the foreign and 450 the home domains are far away from each other. In order to reduce 451 latency in the initial registration, it is important to reduce the 452 time taken for communications between the AAA servers to traverse the 453 wide-area Internet that is likely to separate the AAAL and the AAAH. 455 In the AAA support for Mobile IPv4, in order to reduce the number of 456 messages between domains that traverse the network for initial 457 registration of a Mobile Node and the resulting latency, the initial 458 registration message between the foreign agent and the home agent is 459 carried by AAA through the AAA functions in the visited network 460 (AAAL) and the home network (AAAH). As a result, latency is reduced 461 by handling the initial registration in conjunction with AAA and the 462 mobile IP mobility agents. 464 A similar solution should be adopted also for the support of Mobile 465 IPv6, and the following requirement is formulated: 467 - it SHOULD be possible to combine authorization and authentication 468 of a mobile node through AAA with Mobile IPv6 mobility procedures 469 (e.g. Binding Update). 471 Moreover, subsequent registrations, and authentication could be 472 optimized thanks to LSA. 474 Thanks to this requirement, unless the authentication mechanism 475 adopted requires several round trips, all needed AAA and Mobile IP 476 functions can be processed during a single exchange of messages 477 between the foreign domain and the home domain. 479 5.5. Home agent allocation 481 Another important requirement that needs to receive special attention 482 when defining the IPv6 solution is the Home agent allocation. 483 Scenarios for home agent allocation have already been described in 484 RFC 2977 [1] and still apply. 486 The Diameter Mobile IPv4 Application defines the procedure to assign 487 the Home agent in the visited domain. The ability to support this not 488 only provides more flexibility, but also allows more business 489 scenarios and reduces delays for the Mobile IP signaling procedures. 490 Thanks to the application, the Home Agent allocated to the MN needs 491 not be part of the MN home domain. E.g. this situation can occur if 492 the home address of the mobile node is provided by one domain (e.g. 493 an ISP that the mobile user uses while at home), and the 494 authorization and accounting by another (specialized) domain, e.g., a 495 credit card company. Another example is that the MN may want to get 496 connectivity and the ability to be mobile in a foreign domain and by 497 using the subscription with a home ISP (home domain), but the MN does 498 not desire to be reachable for packets destined to the MN home 499 address given by the home ISP. 501 Such functionality SHOULD also be considered when designing the AAA 502 support for MIPv6 solution. 504 6. Security considerations 506 This document does not specify a solution but describes the 507 requirements that need to be considered when developing a solution 508 for Mobile IPv6 and AAA. The security requirements have been listed 509 and explained in the previous sections. Different solutions MAY 510 fulfill the functional requirements expressed in this document. For 511 each of these, the security implications need to be analyzed 513 7. References 515 [1] Glass, et al.; Mobile IP Authentication, Authorization and 516 Accounting Requirements, RFC 2977, Internet Engineering 517 Task Force, October 2000. 519 [2] Pat R. Calhoun, Charles E. Perkins; Diameter Mobile IPv4 520 Application, Internet draft, Internet Engineering Task 521 Force, February 2004. 523 [3] Protocol Carrying Authentication for Network Access WG 524 (pana) http://www.ietf.org/html.charters/pana-charter.html. 526 [4] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig, A. Yegin 527 Protocol for Carrying Authentication for Network Access 528 (PANA),Internet draft, Internet Engineering Task Force, 529 February 9, 2004 531 [5] Stefano M. Faccin, Franck Le; AAA Local Security 532 Association (LSA): The Temporary Shared Key (TSK), Internet 533 draft, Internet Engineering Task Force, July 2001. 535 [6] Pat R. Calhoun, et al.; Diameter Base Protocol, RFC 3588, 536 Internet Engineering Task Force, September 2003. 538 [7] B. Aboba et M. Beadles, The Network Access Identifier, RFC 539 2486, Internet Engineering Task Force, January 1999. 541 [8] Charles E. Perkins et al., AAA for IPv6 Network Access, 542 Internet draft, Internet Engineering Task Force, July 2001 544 [9] W. Simpson, PPP Challenge Handshake Authentication Protocol 545 (CHAP), RFC 1994, Internet Engineering Task Force, August 546 1996 548 [10] J. Arkko et H. Haverinen, EAP AKA Authentication, Internet 549 draft, Internet Engineering Task Force, 27 October, 2003 551 [11] S. Bradner, "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [12] Stefano M. Faccin, Franck Le; Diameter Mobile IPv6 555 Application, Internet draft, Internet Engineering Task 556 Force, November 2001. 558 [13] Francis Dupont, Maryline Laurent-Maknavicius et Julien 559 Bournelle; AAA for mobile IPv6; Internet draft, Internet 560 Engineering Task Force, November 2001. 562 8. Authors' Addresses 563 Stefano M. Faccin 564 Nokia Research Center 565 6000 Connection Drive 566 Irving, TX 75039 567 USA 569 Phone: +1 972 894-4994 570 E-mail: stefano.faccin@nokia.com 572 Franck Le 573 Nokia Research Center 574 6000 Connection Drive 575 Irving, TX 75039 576 USA 578 Phone: +1 972 374-1256 579 E-mail: franck.le@nokia.com 581 Basavaraj Patil 582 Nokia Corporation 583 6000 Connection Drive 584 Irving, TX 75039 585 USA 587 Phone: +1 972-894-6709 588 E-Mail: Raj.Patil@nokia.com 590 Charles E. Perkins 591 Nokia Research Center 592 313 Fairchild Drive 593 Mountain View, California 94043 594 USA 596 Phone: +1 650-625-2986 597 E-Mail: charliep@iprg.nokia.com 599 Francis Dupont 600 ENST Bretagne 601 Campus de Rennes 602 2, rue de la Chataigneraie 603 BP 78 604 35512 Cesson-Sevigne Cedex 605 FRANCE 606 Fax: +33 2 99 12 70 30 607 EMail: Francis.Dupont@enst-bretagne.fr 609 Maryline Laurent-Maknavicius 610 INT Evry 611 9, rue Charles Fourier 612 91011 Evry Cedex 613 FRANCE 614 Fax: +33 1 60 76 47 11 615 EMail: Maryline.Maknavicius@int-evry.fr 617 Julien Bournelle 618 INT Evry 619 9, rue Charles Fourier 620 91011 Evry Cedex 621 FRANCE 622 Fax: +33 1 60 76 47 11 623 EMail: Julien.Bournelle@int-evry.fr