idnits 2.17.1 draft-ietf-mip6-bootstrapping-integrated-dhc-06.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 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. 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-06', but the file name used is 'draft-ietf-mip6-bootstrapping-integrated-dhc-06' 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 == 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 20, 2008) is 5843 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: 'RFC2119' is defined on line 478, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-15 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-04 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-radius-03 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 7 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 22, 2008 Samsung AIT 6 April 20, 2008 8 MIP6-bootstrapping for the Integrated Scenario 9 draft-ietf-mip6-bootstrapping-integrated-06.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 22, 2008. 36 Abstract 38 Mobile IPv6 bootstrapping can be categorized into two primary 39 scenarios, the split scenario and the integrated scenario. In the 40 split scenario, the mobile node's mobility service is authorized by a 41 different service authorizer than the network access authorizer. In 42 the integrated scenario, the mobile node's mobility service is 43 authorized by the same service authorizer as the network access 44 service authorizer. This document defines a method for home agent 45 information discovery for the integrated scenario. 47 Table of Contents 49 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Assumptions & Conformance . . . . . . . . . . . . . . . . . . 5 52 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. Logical View of the Integrated Scenario . . . . . . . . . 6 54 4.2. Bootstrapping Message Sequence . . . . . . . . . . . . . . 7 55 4.2.1. Home Agent allocation in the MSP . . . . . . . . . . . 8 56 4.2.2. Home Agent allocation in the ASP . . . . . . . . . . . 9 57 4.3. Bootstrapping Message Sequence: Fallback case . . . . . . 10 58 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated 59 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 63 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 68 Intellectual Property and Copyright Statements . . . . . . . . . . 19 70 1. Introduction and Scope 72 The Mobile IPv6 protocol [RFC3775] requires the mobile node to have 73 information of its Home Address, the home agent address and the 74 cryptographic materials for establishing an IPsec security 75 association with the home agent prior to initiating the registration 76 process. The mechanism via which the mobile node obtains these 77 information is called Mobile IPv6 bootstrapping. In order to allow a 78 flexible deployment model for Mobile IPv6, it is desirable to define 79 a bootstrapping mechanism for the mobile node to acquire these 80 parameters dynamically. [RFC4640] describes the problem statement 81 for Mobile IPv6 bootstrapping. It also defines the bootstrapping 82 scenarios based on the relationship between the entity that 83 authenticates and authorizes the mobile node for network access 84 (i.e., the Access Service Authorizer) and the entity that 85 authenticates and authorizes the mobile node for mobility service 86 (i.e., the Mobility Service Authorizer). The scenario in which the 87 Access Service Authorizer is not the Mobility Service Authorizer is 88 called the "Split" scenario. The bootstrapping solution for the 89 split scenario is defined in [RFC5026]. The scenario in which the 90 Access Service Authorizer is also the Mobility Service Authorizer is 91 called the "Integrated" scenario. This document defines a 92 bootstrapping solution for the Integrated scenario. 94 [RFC5026] identifies four different components of the bootstrapping 95 problem: home agent address discovery, HoA assignment, IPsec Security 96 Association [RFC4301] setup, and Authentication and Authorization 97 with the MSA. This document defines a mechanism for home agent 98 address discovery. The other components of bootstrapping are as per 99 [RFC5026]. 101 In the integrated scenario, the bootstrapping of the home agent 102 information can be achieved via DHCPv6. This document defines the 103 MIPv6 bootstrapping procedures for the integrated scenario. It 104 enables Home Agent assignment in the integrated scenario by utilizing 105 DHCP and AAA protocols. The specification utilizes DHCP and AAA 106 options and AVPs that are defined in [HIOPT], [MIP6-Dime], and 107 [MIP6-RADIUS]. This document specifies the interworking among MN, 108 NAS, DHCP, and AAA entities for the bootstrapping procedure in the 109 integrated scenario. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119. 117 General mobility terminology can be found in [RFC3753]. The 118 following additional terms, as defined in [RFC4640], are used in this 119 document: 121 Access Service Authorizer (ASA): A network operator that 122 authenticates a mobile node and establishes the mobile node's 123 authorization to receive Internet service. 125 Access Service Provider (ASP): A network operator that provides 126 direct IP packet forwarding to and from the mobile node. 128 Mobility Service Authorizer (MSA): A service provider that authorizes 129 Mobile IPv6 service. 131 Mobility Service Provider (MSP): A service provider that provides 132 Mobile IPv6 service. A MSP is called home MSP when MSP == MSA. In 133 this document the term MSP means a Mobility Service Provider that has 134 roaming relationship with the MSA but it is not the MSA. 136 Split scenario: A scenario where the mobility service and the network 137 access service are authorized by different entities. 139 Integrated Scenario: A scenario where the mobility service and the 140 network access service are authorized by the same entity. 142 3. Assumptions & Conformance 144 The following assumptions are made in this document: 146 a. MSA == ASA. 148 b. MSA and MSP roaming relationship is assumed but not required. 150 c. DHCP relay and NAS are co-located or there is a mechanism to 151 transfer received AAA information from the NAS to the DHCP relay. 153 Note: If assignment of a home agent in the home MSP is not required 154 by a deployment, co-location of the NAS and the DHCP relay functions 155 or a mechanism to transfer received AAA information from the NAS to 156 the DHCP relay won't be necessary. In such a case, only the 157 implementation of the options and procedures defined in [HIOPT] 158 should suffice. 160 d. The NAS shall support MIPv6 specific AAA attributes as specified 161 in [MIP6-RADIUS] and [MIP6-Dime]. 163 e. The AAAH used for network access authentication (ASA) has access 164 to the same database as the AAAH used for the mobility service 165 authentication (MSA). 167 If home agent assignment only in the ASP is required by the 168 deployment, a minimal implementation of this specification MAY only 169 support the delivery of information from the DHCP server to the DHCP 170 client through [HIOPT]. However, if home agent assignment in the MSP 171 is required by the deployment, an implementation conforming to this 172 specification SHALL be able to transfer received information (from 173 the AAA server) from the NAS to the DHCP relay function. This can be 174 achieved either by co-locating the NAS and the DHCP relay functions 175 or via an interface between these functions. The detail of this 176 interface is out of scope of this specification. 178 4. Solution Overview 180 4.1. Logical View of the Integrated Scenario 182 In the integrated scenario, the mobile node utilizes the network 183 access authentication process to bootstrap Mobile IPv6. It is 184 assumed that the access service authorizer is mobility service aware. 185 This allows for Mobile IPv6 bootstrapping at the time of access 186 authentication and authorization. Also, the mechanism defined in 187 this document requires the NAS to support Mobile IPv6 specific AAA 188 attributes and a co-located DHCP relay agent. 190 The following diagram shows the network elements and layout in the 191 integrated scenario: 193 | 194 ASP(/MSP) | ASA/MSA(/MSP) 195 | 196 | 197 +-------+ | +-------+ 198 | | | | | 199 |AAAV |-----------|--------|AAAH | 200 | | | | | 201 +-------+ | +-------+ 202 | | 203 | | 204 | | 205 | | 206 +-----+ +------+ | 207 +----+ | NAS/| |DHCP | | 208 | MN |------|DHCP |----|Server| | 209 +----+ |Relay| | | | 210 +-----+ +------+ | 211 | 212 | 213 +--------+ | +--------+ 214 | HA | | | HA | 215 | in ASP | | |in MSP | 216 +--------+ | +--------+ 218 Figure 1. Integrated Scenario, Network Diagram with DHCP Server 220 Figure 1 shows the AAA infrastructure with an AAA client (NAS), an 221 AAA proxy in the visited network and an AAA server in the home 222 network. The user's home network authorizes the mobile node for 223 network access and also for mobility services. Note that a home 224 agent for usage with the mobile node might be selected in the access 225 service provider's network or alternatively in the mobility service 226 provider's network. 228 The mobile node interacts with the DHCP Server via the Relay Agent 229 after the network access authentication as part of the mobile node 230 configuration procedure. 232 4.2. Bootstrapping Message Sequence 234 In this case, the mobile node is able to acquire the home agent 235 address via a DHCPv6 query. The message flows for home agent 236 allocation in the ASP and the MSP are illustrated below. In the 237 integrated scenario, the ASA and the MSA are the same, it can be 238 safely assumed that the AAAH used for network access authentication 239 (ASA) has access to the same database as the AAAH used for the 240 mobility service authentication (MSA). Hence, the same AAAH can 241 authorize the mobile node for network access and mobility service at 242 the same time. When the MN performs Mobile IPv6 registration, the 243 AAAH ensures that the MN is accessing the assigned Home Agent for 244 that MSP. 246 Figure 2 shows the message sequence for home agent allocation in both 247 scenarios -- HA in the MSP, and HA in the ASP. 249 | 250 --------------ASP------>|<--ASA+MSA-- 251 | 252 +----+ +------+ +-------+ +-----+ 253 | | | | | | | | 254 | MN/| |NAS/ | | DHCP | |AAAH | 255 |User| |DHCP | | Server| | | 256 | | |relay | | | | | 257 +----+ +------+ +-------+ +-----+ 258 | | | | 259 | 1 | 1 | | 260 |<------------->|<---------------------->| 261 | | | | 262 | | | | 263 | 2 | | | 264 |-------------->| | | 265 | | | | 266 | | 3 | | 267 | |------------>| | 268 | | | | 269 | | 4 | | 270 | |<------------| | 271 | | | | 272 | 5 | | | 273 |<--------------| | | 274 | | | | 276 Figure 2. Message sequence for Home Agent allocation 278 4.2.1. Home Agent allocation in the MSP 280 This section describes a scenario where the home agent is allocated 281 in the mobile node's MSP network(s). In order to provide the mobile 282 node with information about the assigned home agent, the AAAH conveys 283 the assigned home agent's information to the NAS via an AAA protocol, 284 e.g., [MIP6-RADIUS] or [MIP6-Dime]. 286 Figure 2 shows the message sequence for home agent allocation. In 287 the scenario with HA in the MSP, the following details apply. 289 (1) The mobile node executes the network access authentication 290 procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. 291 The NAS is in the ASP and it interacts with the AAAH, which is in the 292 ASA/MSA, to authenticate the mobile node. In the process of 293 authorizing the mobile node, the AAAH verifies in the AAA profile 294 that the mobile node is allowed to use the Mobile IPv6 service. The 295 AAAH assigns a home agent in the home MSP and it assigns one or more 296 home agent(s) in other authorized MSPs and returns this information 297 to the NAS. The NAS may keep the received information for a 298 configurable duration or it may keep the information for as long as 299 the MN is connected to the NAS. 301 (2) The mobile node sends a DHCPv6 Information Request message 302 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 303 In this message, the mobile node (DHCP client) SHALL include the 304 Option Code for the Home Network Identifier Option [HIOPT] in the 305 OPTION_ORO, and a Home Network Identifier Option with id-type set to 306 1 and the Home Network Identifier field set to the network realm of 307 the home MSP [HIOPT]. The mobile node SHALL also include the 308 OPTION_CLIENTID to identify itself to the DHCP server. 310 (3) The Relay Agent intercepts the Information Request from the 311 mobile node and forwards it to the DHCP server. The Relay Agent also 312 includes the received home agent information from the AAAH in the 313 OPTION_MIP6-RELAY-Option [HIOPT]. If a NAS implementation does not 314 store the received information as long as the MN's session remains in 315 the ASP, and if the MN delays sending a DHCP request, the NAS/DHCP 316 relay does not include the OPTION_MIP6-RELAY-Option in the Relay 317 Forward message. 319 (4) The DHCP server identifies the client by looking at the DUID for 320 the client in the OPTION_CLIENTID. The DHCP server also determines 321 that the mobile node is requesting home agent information in the MSP 322 by looking at the Home Network Identifier Option (id-type 1). The 323 DHCP server determines that the home agent is allocated by the AAAH 324 by looking at the MIP6 home agent sub-option in the OPTION_MIP6- 325 RELAY-Option. The DHCP server extracts the allocated home agent 326 information from the OPTION_MIP6-RELAY-Option and includes it in the 327 Home Network Information Option [HIOPT] in the Reply Message. If the 328 requested information is not available in the DHCP server, it follows 329 the behavior described in [HIOPT]. 331 (5) The Relay Agent relays the Reply Message from the DHCP server to 332 the mobile node. At this point, the mobile node has the home agent 333 information that it requested. 335 4.2.2. Home Agent allocation in the ASP 337 This section describes a scenario where the mobile node requests for 338 home agent allocation in the ASP by setting the id-type field to zero 339 in the Home Network Identifier Option [HIOPT] in the DHCPv6 request 340 message. In this scenario, the ASP becomes the MSP for the duration 341 of the network access authentication session. 343 Figure 2 shows the message sequence for home agent allocation. In 344 the scenario with HA in the ASP, the following details apply. 346 (1) The mobile node executes the network access authentication 347 procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. 348 The NAS is in the ASP and it interacts with the AAAH, which is in the 349 ASA/MSA, to authenticate the mobile node. In the process of 350 authorizing the mobile node, the AAAH verifies in the AAA profile 351 that the mobile node is allowed to use the Mobile IPv6 services. The 352 AAAH assigns a home agent in the home MSP and it assigns one or more 353 home agent(s) in other authorized MSPs and returns this information 354 to the NAS. Note that the AAAH is not aware of the fact that the 355 mobile node prefers a home agent allocation in the ASP. Therefore 356 the assigned home agent may not be used by the mobile node. This 357 leaves the location of the mobility anchor point decision to the 358 mobile node. 360 (2) The mobile node sends a DHCPv6 Information Request message 361 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 362 In this message, the mobile node (DHCP client) SHALL include the 363 Option Code for the Home Network Identifier Option [HIOPT] in the 364 OPTION_ORO, and a Home Network Identifier Option with id-type set to 365 0. The mobile node SHALL also include the OPTION_CLIENTID to 366 identify itself to the DHCP server. 368 (3) The Relay Agent intercepts the Information Request from the 369 mobile node and forwards it to the DHCP server. The Relay Agent 370 (which is the NAS) also includes the received AAA AVP from the AAAH 371 in the OPTION_MIP6-RELAY-Option [HIOPT]. 373 (4) The DHCP server identifies the client by looking at the DUID for 374 the client in the OPTION_CLIENTID. The DHCP server also determines 375 that the mobile node is requesting home agent information in the ASP 376 by looking at the Home Network Identifier Option (id-type 0). If 377 configured to do so, the DHCP server allocates a home agent from its 378 configured list of home agents and includes it in the Home Network 379 Information Option [HIOPT] in the Reply Message. Note that in this 380 case, the DHCP server does not use the received information in the 381 OPTION_MIP6-RELAY-Option. 383 (5) The Relay Agent relays the Reply Message from the DHCP server to 384 the mobile node. At this point, the mobile node has the home agent 385 information that it requested. 387 4.3. Bootstrapping Message Sequence: Fallback case 389 In the fallback case, the mobile node is not able to acquire the home 390 agent information via DHCPv6. The mobile node MAY perform DNS 391 queries to discover the home agent address as defined in [RFC5026]. 393 To perform DNS based home agent discovery, the mobile node needs to 394 know the DNS server address. The details of how the MN is configured 395 with the DNS server address is outside the scope of this document. 397 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario 399 In the integrated scenario, the HoA, IPsec Security Association 400 setup, and Authentication and Authorization with the MSA are 401 bootstrapped via the same mechanism as described in the bootstrapping 402 solution for the split scenario [RFC5026]. 404 5. Security Considerations 406 The transport of the assigned home agent information via the AAA 407 infrastructure (i.e., from the AAA server to the AAA client) to the 408 NAS may only be integrity protected as per standard RADIUS and 409 Diameter security mechanisms. No additional security considerations 410 are imposed by the usage of this document. The security mechanisms 411 provided by [RFC2865] and [RFC3588] are applicable for this purpose. 412 This document does not introduce any new security issues to Mobile 413 IPv6. 415 6. IANA Considerations 417 None 419 7. Acknowledgements 421 The authors would like to thank Kilian Weniger, Vidya Narayanan, and 422 George Tsirtsis for their review and comments. Thanks to Alfred 423 Hoenes for thorough review and valuable suggestions to improve the 424 readability of the document. 426 8. Contributors 428 This contribution is a joint effort of the bootstrapping solution 429 design team of the MEXT WG. The contributors include Gerardo 430 Giaretta, Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, 431 Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal 432 Chowdhury, Julien Bournelle, and Hannes Tschofenig. 434 The design team members can be reached at: 436 Gerardo Giaretta gerardog@qualcomm.com 438 Basavaraj Patil basavaraj.patil@nsn.com 440 Alpesh Patel alpesh@cisco.com 442 Jari Arkko jari.arkko@kolumbus.fi 444 James Kempf kempf@docomolabs-usa.com 446 Gopal Dommety gdommety@cisco.com 448 Alper Yegin a.yegin@partner.samsung.com 450 Junghoon Jee jhjee@etri.re.kr 452 Vijay Devarapalli Vijay.Devarapalli@AzaireNet.com 454 Kuntal Chowdhury kchowdhury@starentnetworks.com 456 Julien Bournelle julien.bournelle@orange-ftgroup.com 458 Hannes Tschofenig hannes.tschofenig@nsn.com 460 9. References 462 9.1. Normative References 464 [HIOPT] Hee Jang et. al., A., "DHCP Option for Home Agent 465 Discovery in MIPv6.", draft-ietf-mip6-hiopt-15.txt (work 466 in progress), April 2008. 468 [MIP6-Dime] 469 Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA 470 Support.", draft-ietf-dime-mip6-integrated-04.txt (work in 471 progress), May 2007. 473 [MIP6-RADIUS] 474 Lior et. al., A., "RADIUS Mobile IPv6 Support.", 475 draft-ietf-mip6-radius-03.txt (work in progress), 476 November 2007. 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 482 "Remote Authentication Dial In User Service (RADIUS)", 483 RFC 2865, June 2000. 485 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 486 and M. Carney, "Dynamic Host Configuration Protocol for 487 IPv6 (DHCPv6)", RFC 3315, July 2003. 489 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 490 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 492 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 493 in IPv6", RFC 3775, June 2004. 495 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 496 Bootstrapping in Split Scenario", RFC 5026, October 2007. 498 9.2. Informative References 500 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 501 RFC 3753, June 2004. 503 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 504 Internet Protocol", RFC 4301, December 2005. 506 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 507 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 508 September 2006. 510 Authors' Addresses 512 Kuntal Chowdhury 513 Starent Networks 514 30 International Place 515 Tewksbury, MA 01876 516 US 518 Email: kchowdhury@starentnetworks.com 520 Alper Yegin 521 Samsung AIT 522 Istanbul, 523 Turkey 525 Email: a.yegin@partner.samsung.com 527 Full Copyright Statement 529 Copyright (C) The IETF Trust (2008). 531 This document is subject to the rights, licenses and restrictions 532 contained in BCP 78, and except as set forth therein, the authors 533 retain all their rights. 535 This document and the information contained herein are provided on an 536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 538 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 539 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 540 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 Intellectual Property 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed to 547 pertain to the implementation or use of the technology described in 548 this document or the extent to which any license under such rights 549 might or might not be available; nor does it represent that it has 550 made any independent effort to identify any such rights. Information 551 on the procedures with respect to rights in RFC documents can be 552 found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use of 557 such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository at 559 http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention any 562 copyrights, patents or patent applications, or other proprietary 563 rights that may cover technology that may be required to implement 564 this standard. Please address the information to the IETF at 565 ietf-ipr@ietf.org.