idnits 2.17.1 draft-xia-mipshop-mpls-tunnel-00.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 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. 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 == Line 388 has weird spacing: '...e field conta...' -- 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 (April 4, 2008) is 5859 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: 'RFC3209' is defined on line 445, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-11 == Outdated reference: A later version (-04) exists of draft-muhanna-netlmm-grekey-option-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Expires: October 6, 2008 Huawei USA 5 April 4, 2008 7 MPLS Tunnel Support for Proxy Mobile IPv6 8 draft-xia-mipshop-mpls-tunnel-00.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 October 6, 2008. 35 Abstract 37 The Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic 38 between a Local Mobility Anchor(LMA) and a Mobile Access Gateway 39 (MAG) to be tunneled using IPv6, IPv4 or IPv4-UDP encapsulation 40 headers. In this document, Multiprotocol Label Switching (MPLS) 41 tunneling is proposed as an alternative tunnel technology which is 42 used between a MAG and a LMA. MPLS is now become more and more 43 popular, and MPLS support is an important function for edge and core 44 routers. Integrating MPLS and Proxy IP Mobility can leverage Proxy 45 IP Mobility deployment in the industry. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Overview of MPLS . . . . . . . . . . . . . . . . . . . . . . . 4 52 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 53 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 7 54 5.1. Operational Summary . . . . . . . . . . . . . . . . . . . 7 55 5.2. Extensions to Binding Cache Entry . . . . . . . . . . . . 8 56 6. MAG Considerations . . . . . . . . . . . . . . . . . . . . . . 8 57 6.1. Operational Summary . . . . . . . . . . . . . . . . . . . 8 58 6.2. Extensions to Binding Update List Entry . . . . . . . . . 9 59 7. New Option . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7.1. Virtual Pipe Label Option . . . . . . . . . . . . . . . . 9 61 8. MIPv4 Applicability . . . . . . . . . . . . . . . . . . . . . 10 62 9. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 10 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 67 12.2. Informative references . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . . . 14 71 1. Introduction 73 The Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] allows a Mobile 74 Node(MN)'s IPv4 and IPv6 traffic between a Local Mobility Anchor(LMA) 75 and a Mobile Access Gateway (MAG) to be tunneled using IPv6, IPv4 or 76 IPv4-UDP encapsulation headers. Generic Routing Encapsulation (GRE) 77 tunneling is also introduced in [I-D.muhanna-netlmm-grekey-option]. 79 MPLS is now become more and more popular due to it's powerful support 80 of engineering, Virtual Private Network (VPN) and so on. Almost all 81 mainstream edge and core routers are equipped with MPLS 82 functionality. As a natural tunnel technology, it is possible for 83 the LMA and the MAG to tunnel packets between each other. 84 Integrating MPLS and Proxy IP Mobility can leverage Proxy Mobility 85 deployment in the industry. 87 The extensions defined in this document allow the MAG and the LMA to 88 distribute MPLS labels using Proxy Binding Update (PBU) and Proxy 89 Binding Acknowledgement(PBA) exchange. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 The terminology in this document is based on the definitions in 98 [I-D.ietf-netlmm-proxymip6], in addition to the ones specified in 99 this section. 101 Downstream Traffic: . The traffic in the tunnel between the LMA and 102 the MAG, heading towards the MAG and tunneled at the LMA. 103 Upstream Traffic: The traffic in the tunnel between the MAG and the 104 LMA, heading towards the LMA and tunneled at the MAG. 106 LSR: A router which supports MPLS is known as a "Label Switching 107 Router", or LSR. 109 MPLS domain: a contiguous set of nodes which operate MPLS routing 110 and forwarding and which are also in one Routing or Administrative 111 Domain. In this document, LMA,MAG and the core routers belong to 112 the same MPLS domain. 114 MPLS edge node: a MPLS node that connects a MPLS domain with a node 115 which is outside of the domain, either because it does not run 116 MPLS, and/or because it is in a different domain. Note that if an 117 LSR has a neighboring host which is not running MPLS, that LSR is 118 a MPLS edge node. In Proxy Mobile IPv6 scenario, LMA and MAG are 119 MPLS edge nodes 121 MPLS egress node: a MPLS edge node in its role in handling traffic 122 as it leaves a MPLS domain. In this document, the MAG is a MPLS 123 egress node for downstream traffic, while the LMA is a MPLS egress 124 node for upstream traffic. 126 MPLS ingress node: a MPLS edge node in its role in handling traffic 127 as it enters an MPLS domain. In this document, the LMA is a MPLS 128 ingress node for downstream traffic, while MAG is a MPLS ingress 129 node for upstream traffic. 131 Virtual Pipe (VP): as illustrated in Figure 2, MNs belong to 132 different operators, and virtual pipes are used for 133 differentiating operators' traffic. MPLS labels are used for 134 identifying VPs. A virtual pipe is unidirectional. A virtual 135 pipe which is used for conveying traffic from the LMA to the MAG 136 is called a downstream VP, otherwise a virtual pipe is called an 137 upstream VP. 139 3. Overview of MPLS 141 The following section provides a brief overview of MPLS. It is 142 intended as background information so that the solution in this 143 document can then be presented in detail in the following sections. 144 MPLS protocol cluster comprises many contents, and only operations 145 related to the document are introduced here. 147 [RFC3031] specifies the architecture for MPLS and [RFC3032] describes 148 MPLS label stack encoding. In these specifications, a shim layer 149 called label stack is introduced, and the shim layer appears after 150 the data link layer headers, but before any network layer headers. 151 The label stack can include one or more labels. Each label is 152 represented by 4 octets as illustrated in Figure 1. 154 0 1 2 3 155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 157 | Label | Exp |S| TTL | Stack 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 160 Label: Label Value, 20 bits 161 Exp: Experimental Use, 3 bits 162 S: Bottom of Stack, 1 bit 163 TTL: Time to Live, 8 bits 165 Figure 1: Encoding the Label Stack 167 In typical IP forwarding, a label is pushed to IP packets in a MPLS 168 ingress node, while the label is popped in a MPLS egress node. The 169 labeled packets are transmitted from the ingress node to the egress 170 node through a series of LSRs. The labels using for switching is 171 often distributed by Label Distribution Protocol (LDP) [RFC5036] 173 4. Protocol Overview 175 Suppose it is desired to transport traffic from the MAG serving as an 176 ingress LSR to the LMA serving as an egress LSR, across an 177 intervening MPLS network. We assume that there is a Label Switched 178 Path (LSP) from the MAG to the LMA through LDP or other protocols. 179 That is, we assume that the MAG can cause a packet to be delivered to 180 LMA by pushing some label onto the packet and sending the result to 181 one of its adjacencies. Call this label the "tunnel label", and the 182 corresponding LSP the "tunnel LSP". How to build the tunnel LSP is 183 beyond the scope of the document, please refer to [RFC5036] for 184 further understanding. 186 The tunnel LSP merely gets packets from the MAG to LMA; the 187 corresponding label doesn't tell the LMA what to do with the payload. 188 there must be a label, which becomes visible to the LMA, that tells 189 the LMA how to treat the received packet. Call this label the "VP 190 label". In this draft, new options are defined for distributing VP 191 labels between the MAG and the LMA. 193 So when the MAG sends a packet to the LMA, it first pushes a VP label 194 on its label stack, and then pushes on a tunnel label. The tunnel 195 label gets the MPLS packet from the MAG to the LMA or vice versa; the 196 VP label is not visible until the MPLS packet reaches the LMA or the 197 MAG. LMA's proscessing of the packet is based on the VP label. 199 As a example, Figure 2 illustrates a LMA providing mobility service 200 to MNs that are from different operators and are assigned IPv4 201 addresses from overlapping private address space. In this example, 202 MN-1 and MN-2 are visiting from Operator-A, and MN-3 and MN-4 are 203 visiting from Operator-B. In this scenario, the MAG and the LMA must 204 be able distinguish the flows belonging to a given operator from the 205 flows belonging to some other operators. The MAG and the LMA agree 206 upon VPs for identifying the flows belonging to each operator. 208 +------------+ 209 | Operator-A | 210 | 10.x.0.0/16| 211 +------------+ 212 / 213 +----+ +----+ / 214 | | ============================ | | / 215 MN-1---| | / \ | | / VP-1 216 | M | / ------Flows with VP-1----- \ | L | / Traffic 217 MN-2---| A |--| |-| M |- 218 | G | \ ------Flows with VP-2----- / | A | \ VP-2 219 MN-3---| | \ / | | \ Traffic 220 | | ============================= | | \ 221 MN-4---| | PMIPv6 tunnel LSP | | \ 222 +----+ +----+ \ 223 \ 224 +------------+ 225 | Operator-B | 226 | 10.x.0.0/16| 227 +------------+ 229 Figure 2: VP Label Using for Differentiating Traffic 231 As per the base Proxy Mobile IPv6 specification 232 [I-D.ietf-netlmm-proxymip6], the tunnel transport between the MAG and 233 the LMA can be IPv6, IPv4 or IPv4-UDP. When MPLS tunneling is 234 introduced, two layer labels are inserted before IP packet payload. 235 The tunnel label assures the reachability between the MAG and the 236 LMA, while the VP label is used for differentiating traffic such as 237 IPv4, IPv6 and so on. Just as illustrated in Figure 3, the MAG 238 pushes labels before IP packets while the LMA popes labels for 239 upstream traffic. Otherwise, the LMA pushes labels before IP labels 240 while the MAG pops labels for downstream traffic. 242 +---------------------------+ 243 | Tunnel Label | 244 | | 245 +---------------------------+ 246 | VP Label | 247 | | 248 +---------------------------+ +---------------------------+ 249 | Payload Packet | ====> | Payload Packet | 250 | (IPv4 or IPv6) | | | 251 +---------------------------+ +---------------------------+ 253 Figure 3: MPLS Encapsulation 255 5. Local Mobility Anchor Considerations 257 5.1. Operational Summary 259 Upon receiving a PBU with the Virtual Pipe Label Option defined in 260 Section 7.1, the LMA records the label as a downstream VP label in 261 the Bind Cache Entry of the MN if the LMA accepts the binding update 262 message. The label is used for any IP traffic destined to the MN. 264 Based on the MN's profile and IP address, the LMA assigns a label for 265 identifying upstream traffic of the MN. The fields of label are 266 illustrated in Figure 1. The label value field is allocated by the 267 LMA for identifying upstream traffic from the MN; The experimental 268 field is set to zero; S bit is set to 1 to indicate this is the VP 269 label of the two layers label stack; TTL is set to 1 to indicate that 270 the LMA and the MAG are only one hop away from VP label processing 271 perspective. How to allocate label value is out of the scope. The 272 label is distributed to the MAG through Virtual Pipe Label Option in 273 the PBA message. 275 Once an IP packet destined to the MN arrives, the LMA processes as 276 follows: 277 1. Locating a Binding Cache Entry based on MN's IP address. 278 2. Fetching the downstream VP label, and padding it in front of IP 279 packet. 280 3. Identifying the tunnel label based on MN's Proxy CoA. 281 4. Encapsulating the packet with the two-layer labels, and sending 282 it out according to MPLS procedure described in [RFC3031]. 284 Once an IP packets originated from the MN arrives, typically the LMA 285 has the following process steps: 287 1. Popping the tunnel label. 288 2. Striping the VP label and forwarding the packets to a 289 corresponding operator. 291 5.2. Extensions to Binding Cache Entry 293 Every LMA has an Binding Cache Entry (BCE) for each currently 294 attached MN, as explained in [I-D.ietf-netlmm-proxymip6]. For 295 supporting this specification, the conceptual BCE data structure must 296 be extended with the following new additional fields related to MPLS 297 label for tagging the MN's tunneled traffic. 298 o A flag indicating whether MPLS tunneling is enabled for the MN's 299 traffic. 300 o The downstream VP label used for differentiating downstream 301 traffic by different operators. 303 6. MAG Considerations 305 6.1. Operational Summary 307 Once a MN enters a Proxy Mobile IPv6 domain and attaches to an access 308 link, the MAG on that access link, after identifying the mobile node 309 and acquiring its identity, will determine if the mobile node is 310 authorized for the network-based mobility management service. If the 311 network determines that the network-based mobility management service 312 needs to be offered to that MN, the MAG sends a Proxy Binding Update 313 message to the LMA with the Virtual Pipe Label Option defined in 314 Section 7.1. The label is recorded as a downstream VP label in a 315 Bind Cache Entry of the LMA. The fields of label are illustrated in 316 Figure 1. The label value field is allocated by the MAG for 317 identifying downstream traffic to the MN; The experimental field is 318 set to zero; S bit is set to 1 to indicate this is the VP label of 319 the two layers label stack; TTL is set to 1 to indicate that the LMA 320 and the MAG are only one hop away from VP label processing 321 perspective. How to allocate label value is out of the scope. 323 After receiving a Proxy Binding Acknowledgment with the Virtual Pipe 324 Label Option defined in Section 7.1, the MAG records the label as a 325 upstream VP label. 327 Once an IP packets originated from the MN arrives, the LMA processes 328 as follows . 329 1. Locating a Binding Update List Entry based on MN's IP address. 330 2. Fetching the upstream label, and the label is as an VP label. 331 3. Identifying the tunnel label based on LMA's IP address. 333 4. Encapsulating the packet with the two layers label, and sending 334 it out according to MPLS procedure described in [RFC3031]. 336 Once an IP packets destined to the MN arrives, typically the MAG has 337 the following process steps: 338 1. Popping the tunnel label. 339 2. Striping the VP label and forwarding the packets to the MN. 341 6.2. Extensions to Binding Update List Entry 343 Every MAG has a Binding Update List Entry for each currently attached 344 MN, as explained in [I-D.ietf-netlmm-proxymip6]. For supporting this 345 specification, the conceptual Binding Update List data structure MUST 346 be extended with the following new additional fields related to MPLS 347 label for tagging the MN's tunneled traffic. 348 o A flag indicating whether MPLS tunneling is enabled for the MN's 349 traffic flows. 350 o The upstream VP label used for differentiating upstream traffic by 351 different operators. 353 7. New Option 355 This section defines extensions to the [I-D.ietf-netlmm-proxymip6]. 357 7.1. Virtual Pipe Label Option 359 The option is used in the PBU and PBA messages exchanged between the 360 MAG and the LMA. The option is used in the PBU distributing VP 361 labels for downstream traffic, and it is used in the PBA conveying VP 362 labels for upstream traffic. 364 0 1 2 3 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | Reserved | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | VP-Label | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Type 374 376 Length 378 8-bit unsigned integer indicating the length in octets of 379 the option, excluding the type and length fields. 381 Reserved 383 This field is reserved for future use. The value MUST be 384 initialized to 0 by the sender and MUST be ignored by the 385 receiver. 387 VP-Label 388 four-byte field containing MPLS label. 390 Figure 4: Virtual Pipe Label Option 392 8. MIPv4 Applicability 394 The main idea is applicable MIPv4 in case a foreign agent is a tunnel 395 endpoint. New MIPv4 options should be defined to distribute VP 396 labels. It will be elaborated in a separate document in the future . 398 9. IANA consideration 400 This document defines a new Option, the Virtual Pipe Label Option, 401 described in Section 7. This option is carried in the Mobility 402 Header. The type value for this option needs to be assigned from the 403 same numbering space as allocated for the other mobility options 404 defined in the Mobile IPv6 specification [RFC3775]. 406 10. Security Considerations 408 There is a security consideration inherited from the MPLS 409 architecture. A MPLS label has its meaning by virtue of an agreement 410 between the LSR (MAG or LMA here) that puts the label in the label 411 stack (the "label writer"), and the LSR(MAG or LMA here) that 412 interprets that label (the "label reader"). However, the label stack 413 does not provide any means of determining who the label writer was 414 for any particular label. If labeled packets are accepted from 415 untrusted sources, the result may be that packets are routed in an 416 illegitimate manner. 418 In this document, the PBU and the PBA are piggybacked with label 419 distribution information. IPsec is mandatory to be used between the 420 LMA and the MAG for confidentiality protection on the PBU and PBA 421 messages. 423 11. Acknowledgements 425 The author would like to thank Young Lee and John Kaippallimalil for 426 their review. 428 12. References 430 12.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 436 Label Switching Architecture", RFC 3031, January 2001. 438 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 439 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 440 Encoding", RFC 3032, January 2001. 442 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 443 Specification", RFC 5036, October 2007. 445 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 446 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 447 Tunnels", RFC 3209, December 2001. 449 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 450 in IPv6", RFC 3775, June 2004. 452 12.2. Informative references 454 [I-D.ietf-netlmm-proxymip6] 455 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 456 and B. Patil, "Proxy Mobile IPv6", 457 draft-ietf-netlmm-proxymip6-11 (work in progress), 458 February 2008. 460 [I-D.muhanna-netlmm-grekey-option] 461 Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 462 "GRE Key Option for Proxy Mobile IPv6", 463 draft-muhanna-netlmm-grekey-option-01 (work in progress), 464 October 2007. 466 Authors' Addresses 468 Frank Xia 469 Huawei USA 470 1700 Alma Dr. Suite 500 471 Plano, TX 75075 473 Phone: +1 972-509-5599 474 Email: xiayangsong@huawei.com 476 Behcet Sarikaya 477 Huawei USA 478 1700 Alma Dr. Suite 500 479 Plano, TX 75075 481 Phone: +1 972-509-5599 482 Email: sarikaya@ieee.org 484 Full Copyright Statement 486 Copyright (C) The IETF Trust (2008). 488 This document is subject to the rights, licenses and restrictions 489 contained in BCP 78, and except as set forth therein, the authors 490 retain all their rights. 492 This document and the information contained herein are provided on an 493 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 494 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 495 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 496 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 497 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Intellectual Property 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed to 504 pertain to the implementation or use of the technology described in 505 this document or the extent to which any license under such rights 506 might or might not be available; nor does it represent that it has 507 made any independent effort to identify any such rights. Information 508 on the procedures with respect to rights in RFC documents can be 509 found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use of 514 such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository at 516 http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at 522 ietf-ipr@ietf.org.