idnits 2.17.1 draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-mip6-bootstrapping-integrated-03', but the file name used is 'draft-ietf-mip6-bootstrapping-integrated-dhc-03' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 19, 2007) is 6217 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) == Unused Reference: 'RFC1035' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC3118' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC4005' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC4030' is defined on line 525, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-04 == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-02 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-03 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-radius-02 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Downref: Normative reference to an Informational RFC: RFC 3753 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Downref: Normative reference to an Informational RFC: RFC 4640 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury, Editor 3 Internet-Draft Starent Networks 4 Intended status: Standards Track A. Yegin 5 Expires: October 21, 2007 Samsung AIT 6 April 19, 2007 8 MIP6-bootstrapping for the Integrated Scenario 9 draft-ietf-mip6-bootstrapping-integrated-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 21, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Mobile IPv6 bootstrapping problem statement describes two main 43 scenarios. In the first scenario (i.e. the split scenario), the 44 mobile node's mobility service is authorized by a different service 45 authorizer than the basic network access authorizer. In the second 46 scenario (i.e. the integrated scenario), the mobile node's mobility 47 service is authorized by the same service authorizer as the basic 48 network access service authorizer. This document defines a method 49 for home agent information discovery for the integrated scenario. 51 Table of Contents 53 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. List of Assumptions . . . . . . . . . . . . . . . . . . . . . 5 56 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Logical Diagram of the Integrated Scenario . . . . . . . . 6 58 4.2. Bootstrapping Message Sequence, Success Case . . . . . . . 7 59 4.2.1. Home Agent allocation in the MSP . . . . . . . . . . . 7 60 4.2.2. Home Agent allocation in the ASP . . . . . . . . . . . 9 61 4.3. Bootstrapping Message Sequence: Fallback case . . . . . . 11 62 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated 63 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 70 Intellectual Property and Copyright Statements . . . . . . . . . . 19 72 1. Introduction and Scope 74 The Mobile IPv6 protocol [RFC3775] requires the mobile node to have 75 knowledge of its Home Address, the home agent address and the 76 cryptographic materials for establishing an IPsec security 77 association with the home agent prior to performing home 78 registration. The mechanism via which the mobile node obtains these 79 information is called Mobile IPv6 bootstrapping. In order to allow a 80 flexible deployment model for Mobile IPv6, it is desirable to define 81 a bootstrapping mechanism for the mobile node to acquire these 82 parameters dynamically. The [RFC4640] describes the problem 83 statement for Mobile IPv6 bootstrapping. It also defines two 84 bootstrapping scenarios based on the relationship between the entity 85 that authenticates and authorizes the mobile node for network access 86 (i.e., the Access Service Authorizer) and the entity that 87 authenticates and authorizes the mobile node for mobility service 88 (i.e., the Mobility Service Authorizer). The scenario in which the 89 Access Service Authorizer is not the Mobility Service Authorizer is 90 called the "Split" scenario. The bootstrapping solution for split 91 scenario is defined in [BOOT-SPLIT]. The scenario in which the 92 Access Service Authorizer is also the Mobility Service Authorizer is 93 called the "Integrated" scenario. This document defines a 94 bootstrapping solution for the Integrated scenario. 96 [BOOT-SPLIT] identifies four different components of the 97 bootstrapping problem: home agent address discovery, HoA assignment, 98 IPsec Security Association setup and Authentication and Authorization 99 with the MSA. This document defines a mechanism for home agent 100 address discovery. For the rest of components, please refer to 101 [BOOT-SPLIT]. 103 In the integrated scenario, the bootstrapping of the home agent 104 information can be performed via DHCPv6. DHCPv6 is designed for 105 configuration management and it is being deployed by operators to 106 handle their configuration management needs in their networks. This 107 document defines the mip6 bootstrapping procedures for the integrated 108 scenario. This draft enables Home Agent assignment in the integrated 109 scenario by utilizing DHCP and AAA protocols. The specification 110 utilizes DHCP and AAA options and AVPs that are defined in [HIOPT], 111 [MIP6-Dime], and [MIP6-RADIUS]. This document specifies the 112 interworking among MN, NAS, DHCP, and AAA entities for bootstrapping 113 procedure in the integrated scenario. 115 2. Terminology 117 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 General mobility terminology can be found in [RFC3753]. The 122 following additional terms, as defined in [RFC4640], are used in this 123 document: 125 Access Service Authorizer (ASA): A network operator that 126 authenticates a mobile node and establishes the mobile node's 127 authorization to receive Internet service. 129 Access Service Provider (ASP): A network operator that provides 130 direct IP packet forwarding to and from the mobile node. 132 Mobility Service Authorizer (MSA): A service provider that authorizes 133 Mobile IPv6 service. 135 Mobility Service Provider (MSP): A service provider that provides 136 Mobile IPv6 service. A MSP is called home MSP when MSP == MSA. In 137 this document the term MSP means a Mobility Service Provider that has 138 roaming relationship with the MSA but it is not the MSA. 140 Split scenario: A scenario where the mobility service and the network 141 access service are authorized by different entities. 143 Integrated Scenario: A scenario where the mobility service and the 144 network access service are authorized by the same entity. 146 3. List of Assumptions 148 The following assumptions are made in this document: 150 a. MSA == ASA. 152 b. MSA and MSP roaming relationship is assumed but not required. 154 c. DHCP relay and NAS are collocated or there is a way to pass 155 received AAA information from the NAS to the DHCP relay. 157 d. the NAS shall support MIPv6 specific AAA attributes as specified 158 in [MIP6-RADIUS] and [MIP6-Dime]. 160 e. MSP == MSA scenario is termed as home MSP. 162 4. Solution Overview 164 4.1. Logical Diagram of the Integrated Scenario 166 In the integrated scenario the mobile node utilizes network access 167 authentication process to bootstrap Mobile IPv6. It is assumed that 168 the access service authorizer is mobility service aware. This allows 169 for Mobile IPv6 bootstrapping at the time of access authentication 170 and authorization. Also, the mechanism defined in this document 171 requires the NAS to support Mobile IPv6 specific AAA attributes and a 172 collocated DHCP relay agent. 174 The following diagram shows the network elements and layout in the 175 integrated scenario: 177 | 178 ASP(/MSP) | ASA/MSA(/MSP) 179 | 180 | 181 +-------+ | +-------+ 182 | | | | | 183 |AAAV |-----------|--------|AAAH | 184 | | | | | 185 | | | | | 186 +-------+ | +-------+ 187 | | 188 | | 189 | | 190 | | 191 | | 192 | | 193 | | 194 +-----+ +------+ | 195 +----+ | | |DHCP | | 196 | MN |------| NAS/|----|Server| | 197 +----+ |Relay| | | | 198 +-----+ +------+ | 199 | 200 | 201 +--------+ | +--------+ 202 | HA | | | HA | 203 | in ASP | | |in MSP | 204 +--------+ | +--------+ 206 Integrated Scenario, Network Diagram with DHCP Server 208 Figure 1. Integrated Scenario, Network Diagram with DHCP 210 Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA 211 proxy in the visited network and a AAA server in the home network. 212 The user's home network authorizes the mobile node for network access 213 and also for mobility services. Note that a home agent for usage 214 with the mobile node might be selected in the access service 215 provider's network or alternatively in the mobility service 216 provider's network. 218 The mobile node interacts with the DHCP Server via the Relay Agent 219 after the network access authentication as part of the mobile node 220 configuration procedure. 222 4.2. Bootstrapping Message Sequence, Success Case 224 In the success case, the mobile node is able to acquire the home 225 agent address via a DHCPv6 query. The message flows for home agent 226 allocation in the ASP and the MSP are illustrated below. Since, in 227 the integrated scenario, the ASA and the MSA are the same, it can be 228 safely assumed that the AAAH used for network access authentication 229 (ASA) has access to the same database as the AAAH used for the 230 mobility service authentication (MSA). Hence, the same AAAH can 231 authorize the mobile node for network access and mobility service at 232 the same time. When the MN performs Mobile IPv6 registration (IKEv2 233 exchanges), the AAAH ensures that the MN is accessing the assigned 234 Home Agent for that MSP. 236 4.2.1. Home Agent allocation in the MSP 238 This section describes a scenario where the home agent is allocated 239 in the mobile node's MSP network(s). in order to provide the mobile 240 node with information about the assigned home agent the AAAH conveys 241 the assigned home agent's information to the NAS via AAA protocol 242 [MIP6-RADIUS] or [MIP6-Dime]. 244 | 245 --------------ASP------>|<--ASA+MSA-- 246 | 247 +----+ +------+ +-------+ +-----+ 248 | | | | | | | | 249 | MN/| |NAS/ | | DHCP | |AAAH | 250 |User| |DHCP | | Server| | | 251 | | |relay | | Server| | | 252 +----+ +------+ +-------+ +-----+ 253 | | | | 254 | 1 | 1 | | 255 |<------------->|<---------------------->| 256 | | | | 257 | | | | 258 | 2 | | | 259 |-------------->| | | 260 | | | | 261 | | 3 | | 262 | |------------>| | 263 | | | | 264 | | 4 | | 265 | |<------------| | 266 | | | | 267 | 5 | | | 268 |<--------------| | | 269 | | | | 271 Home Agent in the MSP 273 Figure 2. The home agent allocation in the MSP 275 Figure 2 shows the message sequence for home agent allocation in the 276 MSP. 278 (1) The mobile node executes the network access authentication 279 procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the 280 NAS. The NAS is in the ASP and it interacts with the AAAH, which is 281 in the ASA/MSA, to authenticate the mobile node. In the process of 282 authorizing the mobile node the AAAH verifies in the AAA profile that 283 the mobile node is allowed to use Mobile IPv6 service. The AAAH 284 assigns home agent in the home MSP and other authorized MSPs and 285 returns this information to the NAS. The NAS may keep the received 286 information for a configurable duration or it may keep the 287 information for as long as the MN is connected to the NAS. 289 (2) The mobile node sends a DHCPv6 Information Request message 290 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 292 In this message the mobile node (DHCP client) SHALL include the 293 Option Code for Home Network Identifier Option [HIOPT] in the 294 OPTION_ORO, Home Network Identifier Option with id-type set to 1 and 295 the Home Network Identifier field set to the network realm of the 296 home MSP [HIOPT]. The mobile node SHALL also include the 297 OPTION_CLIENTID to identify itself to the DHCP server. 299 (3) The Relay Agent intercepts the Information Request from the 300 mobile node and forwards it to the DHCP server. The Relay Agent also 301 includes the received home agent information from the AAAH in the 302 OPTION_MIP6-RELAY-Option [HIOPT]. If a NAS implementation does not 303 store the received information as long as the MN's session remains in 304 the ASP, and if the MN delays sending DHCP request, the NAS/DHCP 305 relay does not include the OPTION_MIP6-RELAY-Option in the Relay 306 Forward message. 308 (4) The DHCP server identifies the client by looking at the DUID for 309 the client in the OPTION_CLIENTID. The DHCP server also determines 310 that the mobile node is requesting home agent information in the MSP 311 by looking at the Home Network Identifier Option (id-type 1). The 312 DHCP server determines that the home agent is allocated by the AAAH 313 by looking at the MIP6 home agent sub-option in the OPTION_MIP6- 314 RELAY-Option. The DHCP server extracts the allocated home agent 315 information from the OPTION_MIP6-RELAY-Option and includes it in the 316 Home Network Information Option [HIOPT] in the Reply Message. If the 317 requested information is not available in the DHCP server, it follows 318 the behavior described in [HIOPT]. 320 (5) The Relay Agent relays the Reply Message from the DHCP server to 321 the mobile node. At this point, the mobile node has the home agent 322 information that it requested. 324 4.2.2. Home Agent allocation in the ASP 326 This section describes a scenario where the mobile node requests for 327 home agent allocation in the ASP by setting the id-type field to zero 328 in the Home Network Identifier Option in the DHCPv6 request message. 329 In this scenario, the ASP becomes the MSP for the duration of the 330 network access authentication session. 332 | 333 --------------ASP-------->|<--ASA+MSA-- 334 | 335 +----+ +-------+ +-------+ +------+ 336 | | | | | | | | 337 | MN/| | NAS/ | | DHCP | |AAAH | 338 |User| | DHCP | | Server| | | 339 | | | relay | | Server| | | 340 +----+ +-------+ +-------+ +------+ 341 | | | | 342 | 1 | 1 | | 343 |<------------->|<------------------------>| 344 | | | | 345 | | | | 346 | 2 | | | 347 |-------------->| | | 348 | | | | 349 | | 3 | | 350 | |------------->| | 351 | | | | 352 | | 4 | | 353 | |<-------------| | 354 | | | | 355 | 5 | | | 356 |<--------------| | | 357 | | | | 359 Home Agent in the ASP 361 Figure 3. The home agent allocation in the ASP 363 Figure 3 shows the message sequence for home agent allocation in the 364 ASP. 366 (1) The mobile node executes the network access authentication 367 procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the 368 NAS. The NAS is in the ASP and it interacts with the AAAH, which is 369 in the ASA/MSA, to authenticate the mobile node. In the process of 370 authorizing the mobile node the AAAH verifies in the AAA profile that 371 the mobile node is allowed to use Mobile IPv6 services. The AAAH 372 assigns a home agent in the home MSP and returns this information to 373 the NAS. Note that the AAAH is not aware of the fact that the mobile 374 node will rather request for a home agent allocation in the ASP. 375 Therefore the assigned home agent may not be used by the mobile node. 376 This leaves the location of the mobility anchor point decision to the 377 mobile node. 379 (2) The mobile node sends a DHCPv6 Information Request message 380 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 381 In this message the mobile node (DHCP client) SHALL include the 382 Option Code for Home Network Identifier Option [HIOPT] in the 383 OPTION_ORO, Home Network Identifier Option with id-type set to 0. 384 The mobile node SHALL also include the OPTION_CLIENTID to identify 385 itself to the DHCP server. 387 (3) The Relay Agent intercepts the Information Request from the 388 mobile node and forwards it to the DHCP server. The Relay Agent 389 (which is the NAS) also includes the received AAA AVP from the AAAH 390 in the OPTION_MIP6-RELAY-Option [HIOPT]. 392 (4) The DHCP server identifies the client by looking at the DUID for 393 the client in the OPTION_CLIENTID. The DHCP server also determines 394 that the mobile node is requesting home agent information in the ASP 395 by looking at the Home Network Identifier Option (id-type 0). If 396 configured to do so, the DHCP server allocates an home agent from its 397 configured list of home agents and includes it in the Home Network 398 Information Option [HIOPT] in the Reply Message. Note that in this 399 case, the DHCP server does not use the received information in the 400 OPTION_MIP6-RELAY-Option. 402 (5) The Relay Agent relays the Reply Message from the DHCP server to 403 the mobile node. At this point, the mobile node has the home agent 404 information that it requested. 406 4.3. Bootstrapping Message Sequence: Fallback case 408 In the fallback case, the mobile node is not able to acquire the home 409 agent information via DHCPv6. The mobile node MAY perform DNS 410 queries to discover the home agent address as defined in 411 [BOOT-SPLIT]. To perform DNS based home agent discovery, the mobile 412 node needs to know the DNS server address. How the mobile node knows 413 the DNS server address is outside the scope of this document. 415 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario 417 In the integrated scenario, the HoA, IPsec Security Associations 418 setup, and Authentication and Authorization with the MSA are 419 bootstrapped via the same mechanism as described in the bootstrapping 420 solution for split scenario [BOOT-SPLIT]. 422 5. Security Considerations 424 The transport of the assigned home agent information via the AAA 425 infrastructure (i.e., from the AAA server to the AAA client) to the 426 NAS may only be integrity protected as per standard RADIUS and 427 Diameter security mechanisms. No additional security considerations 428 are imposed by the usage of this document. The security mechanisms 429 provided by [RFC2865] and [RFC3588] are applicable for this purpose. 431 6. IANA Considerations 433 None 435 7. Acknowledgements 437 The authors would like to thank Kilian Weniger, Vidya Narayanan, and 438 George Tsirtsis for their review and comments. 440 8. Contributors 442 This contribution is a joint effort of the bootstrapping solution 443 design team of the MIP6 WG. The contributors include Gerardo 444 Giaretta, Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, 445 Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal 446 Chowdhury, Julien Bournelle, and Hannes Tschofenig. 448 The design team members can be reached at: 450 Gerardo Giaretta gerardo.giaretta@tilab.com 452 Basavaraj Patil basavaraj.patil@nokia.com 454 Alpesh Patel alpesh@cisco.com 456 Jari Arkko jari.arkko@kolumbus.fi 458 James Kempf kempf@docomolabs-usa.com 460 Gopal Dommety gdommety@cisco.com 462 Alper Yegin alper.yegin@samsung.com 464 Junghoon Jee jhjee@etri.re.kr 466 Vijay Devarapalli vijayd@iprg.nokia.com 468 Kuntal Chowdhury kchowdhury@starentnetworks.com 470 Julien Bournelle julien.bournelle@int-evry.fr 472 Hannes Tschofenig hannes.tschofenig@siemens.com 474 9. Normative References 476 [BOOT-SPLIT] 477 Giaretta et. al., A., "Mobile IPv6 bootstrapping in split 478 scenario.", draft-ietf-mip6-bootstrapping-split-04.txt 479 (work in progress), December 2006. 481 [HIOPT] Hee Jang et. al., A., "DHCP Option for Home Agent 482 Discovery in MIPv6.", draft-ietf-mip6-hiopt-02.txt (work 483 in progress), February 2007. 485 [MIP6-Dime] 486 Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA 487 Support.", draft-ietf-dime-mip6-integrated-03.txt (work in 488 progress), February 2007. 490 [MIP6-RADIUS] 491 Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.", 492 draft-ietf-mip6-radius-02.txt (work in progress), 493 March 2007. 495 [RFC1035] Mockapetris, P., "Domain names - implementation and 496 specification", STD 13, RFC 1035, November 1987. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 502 "Remote Authentication Dial In User Service (RADIUS)", 503 RFC 2865, June 2000. 505 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 506 Messages", RFC 3118, June 2001. 508 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 509 and M. Carney, "Dynamic Host Configuration Protocol for 510 IPv6 (DHCPv6)", RFC 3315, July 2003. 512 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 513 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 515 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 516 RFC 3753, June 2004. 518 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 519 in IPv6", RFC 3775, June 2004. 521 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 522 "Diameter Network Access Server Application", RFC 4005, 523 August 2005. 525 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 526 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 527 Option", RFC 4030, March 2005. 529 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 530 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 531 September 2006. 533 Authors' Addresses 535 Kuntal Chowdhury 536 Starent Networks 537 30 International Place 538 Tewksbury, MA 01876 539 US 541 Phone: +1 214-550-1416 542 Email: kchowdhury@starentnetworks.com 544 Alper Yegin 545 Samsung AIT 546 Istanbul, 547 Turkey 549 Phone: 550 Email: alper01.yegin@partner.samsung.com 552 Full Copyright Statement 554 Copyright (C) The IETF Trust (2007). 556 This document is subject to the rights, licenses and restrictions 557 contained in BCP 78, and except as set forth therein, the authors 558 retain all their rights. 560 This document and the information contained herein are provided on an 561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 563 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 564 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 565 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Intellectual Property 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Acknowledgment 594 Funding for the RFC Editor function is provided by the IETF 595 Administrative Support Activity (IASA).