idnits 2.17.1 draft-sarikaya-netlmm-prefix-delegation-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (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: Prefixes can be released in two ways, prefix aging or DHCP release procedure. In the former way, a prefix SHOULD not be used by an MN when the prefix ages, and the DHCP Server can delegate it to another MN. A prefix lifetime is delivered from the DHCPv6 server to the requesting router (LMA) through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information option [RFC4861]. == 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 'MUST not' in this paragraph: If PMIPv6 and MIPv6 are being used by the same MN and HA also supports LMA functionality as described in [I-D.devarapalli-netlmm-pmipv6-mipv6] the same binding cache entry for the MN is sometimes modified by the MN or by a MAG. Because of this, at Step 4 in Figure 5, if the HA colocated with LMA receives a MIPv6 registration BU, LMA MUST not release the prefix(es). -- 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 (November 9, 2007) is 6011 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: 'RFC2866' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC3576' is defined on line 392, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-07 == Outdated reference: A later version (-02) exists of draft-sarikaya-16ng-prefix-delegation-01 ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-17) exists of draft-ietf-dime-mip6-split-05 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft F. Xia 4 Expires: May 12, 2008 Huawei USA 5 November 9, 2007 7 DHCPv6 Based Home Network Prefix Delegation for PMIPv6 8 draft-sarikaya-netlmm-prefix-delegation-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 12, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 In Proxy Mobile IPv6, one prefix can only be assigned to one 42 interface of a mobile node by the local mobility anchor (LMA) and 43 different mobile nodes can not share this home network prefix. 44 Managing per-MN's interface home network prefixes is likely to 45 increase the processing load at the LMA. Based on the idea that 46 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers can 47 manage prefixes, we propose a new technique in which LMA offloads 48 delegation and release tasks of the prefixes to the DHCPv6 server. 49 LMA requests a prefix for an incoming mobile node to the DHCPv6 50 server. Based on this prefix, the mobile node can create a home 51 address for its interface. When the mobile station leaves the 52 network, the prefix is returned to the DHCPv6 server. 53 Authentication, Authorization and Accounting (AAA) servers can also 54 play a role in prefix delegation. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. PMIPv6 Home Network Prefix Delegation . . . . . . . . . . . . 5 61 4. AAA Servers in Home Network Prefix Delegation . . . . . . . . 7 62 5. Prefix Release Procedure . . . . . . . . . . . . . . . . . . . 9 63 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 9 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 10 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 10.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . . . 13 73 1. Introduction 75 Proxy Mobile IPv6 (PMIPv6) provides network-based mobility solution 76 to the mobile nodes (MN). MN configures its interface with an 77 address from the home network prefix (HNP) topologically anchored at 78 MN's local mobility anchor (LMA). PMIPv6 adopted per-MN's interface 79 prefix model where a prefix is only assigned to one interface of MN. 80 Different interfaces of the same MN and other MNs can not share a 81 prefix, and multiple prefixes can be assigned to an interface. The 82 same applies to Mobile IPv6 where due to multi-link subnet issues 83 per-MN's interface prefixes must be used in assigning home link 84 prefixes. However, in per interface prefix model, prefix management 85 is an issue that is addressed in this document for PMIPv6. MIPv6 86 prefix management is not addressed in this document. 88 When an MN enters the network, its LMA requests one or more prefixes 89 for the MN's interface. The prefixes should be released when MN 90 leaves the network. When an operator wants to renumber its network 91 [RFC4192], the prefixes with different lifetime are advertised to the 92 MN. 94 Identity Association for Prefix Delegation (IA_PD) Option enables 95 DHCP messages to carry IPv6 prefixes. The procedure for prefix 96 delegation with DHCP which is independent of address assignment with 97 DHCP has been defined in [RFC3633]. Therefore DHCPv6 provides a way 98 to manage the prefixes. AAA protocols, RADIUS or Diameter, can be 99 involved in prefix allocation as defined in [RFC4818]. 101 In this document we propose DHCPv6 based home network prefix 102 allocation to PMIPv6 MNs. Section 3 describes PMIPv6 home network 103 prefix allocation, Section 4 describes PMIPv6 home network prefix 104 allocation with the help of AAA servers, Section 5 describes how 105 prefixes are released and Section 6 presents miscellaneous 106 considerations that apply. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14 [RFC2119]. 114 This document uses the terminology defined in [RFC3315], [RFC3633]. 115 All MIPv6 related terms are defined in [RFC3775] and PMIPv6 related 116 terms are defined in [I-D.ietf-netlmm-proxymip6]. 118 3. PMIPv6 Home Network Prefix Delegation 120 We first describe HNP allocation without policy profile/ store 121 (defined in [I-D.ietf-netlmm-proxymip6]) followed by policy store 122 based HNP allocation using DHCP. 124 MN MAG LMA DHCPS 125 |------>| | | 1. RtSol 126 | |------->| | 2. PBU (HNP=0) 127 | | |------->| 3. DHCP Solicit 128 | | |<-------| 4. DHCP Advertise 129 | | |------->| 5. DHCP Request (HNP) 130 | | |<-------| 6. DHCP Reply (HNP) 131 | |<-------| | 7. PBA (HNP) 132 |<------| | | 8. RA(HNP) 133 |------>| | | 9. DAD NS 135 Figure 1: Prefix request procedure 1 137 Figure 1 illustrates the scenario where MN's interface is assigned a 138 home network prefix without a policy store. In this scenario, LMA 139 has a DHCP Client and DHCP Server is connected directly. DHCP 140 messages need to be relayed using DHCP relay function in the LMA if 141 the LMA and DHCP server are not connected directly. 143 1. An MN solicits a router advertisement (RtSol) for stateless 144 address configuration. 145 2. Mobile Access Gateway (MAG) sends Proxy Binding Update (PBU) 146 message to LMA and with HNP to zero. 147 3. LMA as the requesting router initiates DHCP Solicit procedure to 148 request prefixes for the MN. LMA creates and transmits a Solicit 149 message as described in sections 17.1.1, "Creation of Solicit 150 Messages" and 17.1.2, "Transmission of Solicit Messages" of RFC 151 3315. LMA creates an IA_PD and assigns it an IAID. LMA MUST 152 include the IA_PD option in the Solicit message. 153 4. The DHCP server as the delegating router sends an Advertise 154 message to LMA in the same way as described in section 17.2.2, 155 "Creation and transmission of Advertise messages" of RFC 3315. 156 5. LMA uses the same message exchanges as described in section 18, 157 "DHCP Client-Initiated Configuration Exchange" of RFC 3315 to 158 obtain or update prefixes from a DHCP server. LMA and the DHCP 159 server use the IA_PD Prefix option to exchange information about 160 prefixes in much the same way as IA Address options are used for 161 assigned addresses. 162 6. LMA stores the prefix information it received in the Reply 163 message. 165 7. LMA replies PBU with Proxy Binding Acknowledgement (PBA) and sets 166 MN's prefix to HNP field of PBA. 167 8. MAG advertises prefixes to MN with Router Advertisement (RA) for 168 stateless address configuration. 169 9. The MN starts verifying address uniqueness by sending a Duplicate 170 Address Detection (DAD) Neighbor Solicitation (NS) message. 172 Policy store based home network prefix allocation using DHCP can be 173 done as shown in Figure 2. Policy store contains parameters such as 174 the mobile node's home network prefix, permitted address 175 configuration modes, roaming policy related and other parameters. 177 MN MAG LMA AAA 178 |-------|--------|-----------------| 1. Network entry 179 | |<-------|---------------->| 2. IKEv2 SA Establishment 180 | |------->| | 3. IKEv2 CFG_REQUEST 181 | |--------|-----------------| 4. IKEv2 EAP Authentication 182 | | DHCPS 183 | | |------->| | 5. DHCP Solicit 184 | | |<-------| | 6. DHCP Advertise 185 | | |------->| | 7. DHCP Request (HNP) 186 | | |<-------| | 8. DHCP Reply (HNP) 187 | |<-------|<-------|--------| 9. IKEv2/EAP Success 188 |<------| | | | 10. RA (HNP) 189 |------>| | | | 11. DAD NS 190 | |------->| | | 12. PBU (HNP) 191 | |<-------| | | 13. PBA 192 | | | | | 194 Figure 2: Prefix request procedure 2 196 1. An MN boots up in the network. DHCP Server in Figure 2 is not 197 involved in the network entry procedures. 198 2. The MAG starts IKEv2 procedures to establish a security 199 association with the LMA [I-D.ietf-dime-mip6-split]. 200 3. MAG requests a prefix for MN's interface using CFG_REQUEST 201 payload in the message. 202 4. MAG and LMA authenticate each other using EAP. At this moment 203 LMA is ready to assign a prefix using DHCP PD. 204 5. Step 3 in Figure 1. 205 6. Step 4 in Figure 1. 206 7. Step 5 in Figure 1. 207 8. Step 6 in Figure 1. 208 9. EAP success is indicated by AAA server to LMA and LMA sends 209 IKEv2 message with MN's profile containing MN's prefix to MAG. 210 Successful network entry terminates and MAG gets HNP. 212 10. MAG advertises prefixes to MN with RA for stateless address 213 configuration. 214 11. The MN starts verifying address uniqueness by sending a DAD NS. 215 12. MAG sends PBU with HNP assigned. 216 13. LMA replies with PBA and establishes MAG-LMA tunnel. 218 If stateful address configuration is used in PMIPv6 links, prefix 219 allocation using DHCPv6 can be done as shown in Figure 3. Here it is 220 assumed that MAG and LMA already established a security association. 222 MN MAG LMA AAA 223 |-------|--------|-----------------|1. Network entry 224 |<------|<-------|---------------->|2. EAP Access Authentication 225 | |<-------|-----------------|3. EAP Success + Profile 226 | |------->| |4. PBU (HNP=0) 227 | | DHCPS 228 | | |------->| |5. DHCP Solicit 229 | | |<-------| |6. DHCP Advertise 230 | | |------->| |7. DHCP Request (HNP) 231 | | |<-------| |8. DHCP Reply (HNP) 232 | |<-------| | |9. PBA (HNP) 233 |<------|<-------|<-------|--------|10. Profile Complete 234 |------>| | | |11. DHCP Request 235 |<------| | | |12. DHCP Reply 237 Figure 3: Prefix request procedure 3 239 In Steps 1-3, MN does network entry and MAG receives the 240 authorization profile from AAA server after successful EAP exchanges. 241 In Step 4, MAG sends a PBU with HNP field set to zero. In Steps 5-8, 242 LMA assigns its HNP using DHCPv6. LMA replies with PBA and sets its 243 HNP parameter in Step 9. IN Step 10, EAP authentication and profile 244 acquisition is completed. In Step 11, MN requests an address from 245 the local DHCP proxy/ server colocated in MAG. DHCP Proxy assigns 246 MN-HoA from this prefix and sends it to MN in DHCP Reply in Step 12. 248 4-way exchange between LMA as requesting router (RR) and DHCP server 249 as delegating router (DR) in the scenarios above MAY be reduced into 250 a two message exchange using the Rapid Commit option [RFC3315]. LMA 251 includes a Rapid Commit option in the Solicit message. DR then sends 252 a Reply message containing one or more prefixes. 254 4. AAA Servers in Home Network Prefix Delegation 256 Currently, there is no protocol defined for AAA-based prefix 257 delegation. [RFC4818] defines a RADIUS attribute called Delegated- 258 IPv6-Prefix that carries IPv6 prefixes to be delegated. This 259 attribute is usable within either RADIUS or Diameter. [RFC4818] 260 recommends the delegating router to use AAA server to receive the 261 prefixes to be delegated using Delegated-IPv6-Prefix attribute/AVP. 263 Delegating router for PMIPv6 can use AAA server in two ways: Either 264 it can receive a pool of prefixes from the AAA server initially by 265 way of Framed-IPv6-Prefix attribute and then delegate each prefix on 266 demand using the scenarios described in Section 3 or it can get the 267 prefixes from the AAA server for each MN's interface separately by 268 way of Delegated-IPv6-Prefix attribute. 270 Figure 4 shows AAA-involved DHCP PD for Figure 1. 272 MN MAG LMA DHCPS AAA 273 |------>| | | | 1. RtSol 274 | |------->| | | 2. PBU (HNP=0) 275 | | |========| | DHCP PD Start 276 | | | |------->| 3. AA-Request 277 | | | |<-------| 4. AA-Answer (HNP) 278 | | |========| | DHCP PD End 279 | |<-------| | | 5. PBA (HNP) 280 |<------| | | | 6. RA(HNP) 281 |------>| | | | 7. DAD NS 283 Figure 4: AAA-involved Prefix request procedure 285 1. MN solicits a router advertisement. 286 2. MAG sends PBU to LMA and sets HNP to zero. 287 3. LMA as Diameter client sends AA-Request message with an MN's 288 information to Diameter server. 289 4. If the MN passes the authentication, the Diameter server sends 290 AA-Answer message with prefix information to the LMA. The 291 Delegated-IPv6-Prefix attribute MAY appear in an AA-Request 292 packet as a hint by the LMA to the Diameter server that it would 293 prefer a prefix, for example, a /48 prefix. The Diameter server 294 MAY delegate a /64 prefix which is an extension of the /48 prefix 295 in an AA-Request message containing Delegated-IPv6-Prefix 296 attribute. The attribute can appear multiple times when RADIUS 297 server assigns multiple prefixes to MN. 298 5. Step 7 in Figure 1. 299 6. Step 8 in Figure 1. 300 7. Step 9 in Figure 1. 302 The procedure for AAA-involved DHCP PD corresponding to the scenarios 303 of Figure 2 and Figure 3 can be similarly obtained. 305 5. Prefix Release Procedure 307 MN MAG LMA DHCPS 308 |------>| | | 1. Network exit/deregistration 309 | |------->| | 2. PBU (lifetime=0) 310 | |<-------| | 3. PBA 311 | | |------->| 4. DHCP Release (HNP) 312 | | |<------ | 5. DHCP Reply 313 | | | | 315 Figure 5: PMIPv6 Prefix Release 317 Prefixes can be released in two ways, prefix aging or DHCP release 318 procedure. In the former way, a prefix SHOULD not be used by an MN 319 when the prefix ages, and the DHCP Server can delegate it to another 320 MN. A prefix lifetime is delivered from the DHCPv6 server to the 321 requesting router (LMA) through DHCP IA_PD Prefix option [RFC3633] 322 and RA Prefix Information option [RFC4861]. 324 We describe PMIPv6 prefix release procedure. 326 Figure 5 illustrates how LMA releases prefixes to an DHCP Server: 328 1. An MN detachment signaling, such as switch-off or handover, 329 triggers prefix release procedure. 330 2. MAG sends PBU with lifetime set to zero. 331 3. LMA replies with PBA. 332 4. LMA initiates a Release message to give back the prefixes to the 333 DHCP server. 334 5. The server responds with a Reply message, and then the prefixes 335 can be reused by other MNs. 337 If PMIPv6 and MIPv6 are being used by the same MN and HA also 338 supports LMA functionality as described in 339 [I-D.devarapalli-netlmm-pmipv6-mipv6] the same binding cache entry 340 for the MN is sometimes modified by the MN or by a MAG. Because of 341 this, at Step 4 in Figure 5, if the HA colocated with LMA receives a 342 MIPv6 registration BU, LMA MUST not release the prefix(es). 344 6. Miscellaneous Considerations 346 The considerations on how to generate IAIDs and to delegate prefixes 347 described in [I-D.sarikaya-16ng-prefix-delegation] on the access 348 routers (AR) apply here on the local mobility anchors (LMA). 350 7. Security Considerations 352 This draft introduces no additional messages. Comparing to 353 [RFC3633], [RFC2865] and [RFC3588] there is no additional threats to 354 be introduced. DHCPv6, RADIUS and Diameter security procedures 355 apply. 357 8. IANA consideration 359 None. 361 9. Acknowledgements 363 10. References 365 10.1. Normative References 367 [I-D.ietf-netlmm-proxymip6] 368 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 369 and B. Patil, "Proxy Mobile IPv6", 370 draft-ietf-netlmm-proxymip6-07 (work in progress), 371 November 2007. 373 [I-D.sarikaya-16ng-prefix-delegation] 374 Sarikaya, B. and F. Xia, "Using DHCPv6 and AAA Server for 375 Mobile Station Prefix Delegation", 376 draft-sarikaya-16ng-prefix-delegation-01 (work in 377 progress), March 2007. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 383 "Remote Authentication Dial In User Service (RADIUS)", 384 RFC 2865, June 2000. 386 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 388 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 389 and M. Carney, "Dynamic Host Configuration Protocol for 390 IPv6 (DHCPv6)", RFC 3315, July 2003. 392 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 393 Aboba, "Dynamic Authorization Extensions to Remote 394 Authentication Dial In User Service (RADIUS)", RFC 3576, 395 July 2003. 397 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 398 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 400 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 401 Host Configuration Protocol (DHCP) version 6", RFC 3633, 402 December 2003. 404 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 405 in IPv6", RFC 3775, June 2004. 407 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 408 Attribute", RFC 4818, April 2007. 410 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 411 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 412 September 2007. 414 10.2. Informative References 416 [I-D.devarapalli-netlmm-pmipv6-mipv6] 417 Devarapalli, V., "Proxy Mobile IPv6 and Mobile IPv6 418 interworking", draft-devarapalli-netlmm-pmipv6-mipv6-01 419 (work in progress), April 2007. 421 [I-D.ietf-dime-mip6-split] 422 Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 423 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 424 Agent to Diameter Server Interaction", 425 draft-ietf-dime-mip6-split-05 (work in progress), 426 September 2007. 428 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 429 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 430 September 2005. 432 Authors' Addresses 434 Behcet Sarikaya 435 Huawei USA 436 1700 Alma Dr. Suite 500 437 Plano, TX 75075 439 Email: sarikaya@ieee.org 440 Frank Xia 441 Huawei USA 442 1700 Alma Dr. Suite 500 443 Plano, TX 75075 445 Phone: +1 972-509-5599 446 Email: xiayangsong@huawei.com 448 Full Copyright Statement 450 Copyright (C) The IETF Trust (2007). 452 This document is subject to the rights, licenses and restrictions 453 contained in BCP 78, and except as set forth therein, the authors 454 retain all their rights. 456 This document and the information contained herein are provided on an 457 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 458 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 459 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 460 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 461 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 462 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 464 Intellectual Property 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at 486 ietf-ipr@ietf.org. 488 Acknowledgment 490 Funding for the RFC Editor function is provided by the IETF 491 Administrative Support Activity (IASA).