Network Working Group J. Wiljakka, Ed. Request for Comments: 4215 Nokia Category: Informational October 2005 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology. The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. 1. Introduction ....................................................2 1.1. Scope of This Document .....................................3 1.2. Abbreviations ..............................................3 1.3. Terminology ................................................5 2. Transition Mechanisms and DNS Guidelines ........................5 2.1. Dual Stack .................................................5 2.2. Tunneling ..................................................6 2.3. Protocol Translators .......................................6 2.4. DNS Guidelines for IPv4/IPv6 Transition ....................6 3. GPRS Transition Scenarios .......................................7 3.1. Dual Stack UE Connecting to IPv4 and IPv6 Nodes ............7 3.2. IPv6 UE Connecting to an IPv6 Node through an IPv4 Network ....................................................8
3.2.1. Tunneling Inside the 3GPP Operator's Network ........9 3.2.2. Tunneling Outside the 3GPP Operator's Network ......10 3.3. IPv4 UE Connecting to an IPv4 Node through an IPv6 Network ...................................................10 3.4. IPv6 UE Connecting to an IPv4 Node ........................11 3.5. IPv4 UE Connecting to an IPv6 Node ........................12 4. IMS Transition Scenarios .......................................12 4.1. UE Connecting to a Node in an IPv4 Network through IMS ....12 4.2. Two IPv6 IMS Connected via an IPv4 Network ................15 5. About 3GPP UE IPv4/IPv6 Configuration ..........................15 6. Summary and Recommendations ....................................16 7. Security Considerations ........................................17 8. References .....................................................17 8.1. Normative References ......................................17 8.2. Informative References ....................................18 9. Contributors ...................................................20 10. Authors and Acknowledgements ..................................20 3GPP-23.060], in which the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology. This document analyzes the transition scenarios that may come up in the deployment phase of IPv6 in 3GPP packet data networks. The 3GPP network architecture is described in [RFC3314], and relevant transition scenarios are documented in [RFC3574]. The reader of this specification should be familiar with the material presented in these documents. The scenarios analyzed in this document are divided into two categories: general-purpose packet service scenarios, referred to as GPRS scenarios in this document, and IP Multimedia Subsystem (IMS) scenarios, which include Session Initiation Protocol (SIP) considerations. For more information about IMS, see [3GPP-23.228], [3GPP-24.228], and [3GPP-24.229]. GPRS scenarios are the following: - Dual Stack User Equipment (UE) connecting to IPv4 and IPv6 nodes - IPv6 UE connecting to an IPv6 node through an IPv4 network - IPv4 UE connecting to an IPv4 node through an IPv6 network - IPv6 UE connecting to an IPv4 node
- IPv4 UE connecting to an IPv6 node IMS scenarios are the following: - UE connecting to a node in an IPv4 network through IMS - Two IPv6 IMS connected via an IPv4 network The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In the scenarios, the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.
B2BUA Back-to-Back User Agent CSCF Call Session Control Function (in 3GPP Release 5 IMS) DNS Domain Name System EDGE Enhanced Data rates for GSM Evolution GGSN Gateway GPRS Support Node (default router for 3GPP User Equipment) GPRS General Packet Radio Service GSM Global System for Mobile Communications HLR Home Location Register IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 IPv6-only part of the network ISP Internet Service Provider NAT Network Address Translation NAPT-PT Network Address Port Translation - Protocol Translation NAT-PT Network Address Translation - Protocol Translation PCO-IE Protocol Configuration Options Information Element PDP Packet Data Protocol PPP Point-to-Point Protocol SDP Session Description Protocol SGSN Serving GPRS Support Node SIIT Stateless IP/ICMP Translation Algorithm SIP Session Initiation Protocol UE User Equipment, e.g., a UMTS mobile handset UMTS Universal Mobile Telecommunications System WCDMA Wideband Code Division Multiple Access
RFC4213] - tunneling [RFC4213] - protocol translators [RFC2766], [RFC2765] In addition, DNS recommendations are given. The applicability of different transition mechanisms to 3GPP networks is discussed in sections 3 and 4. RFC4213]. If we consider the 3GPP GPRS core network, dual stack implementation in the Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack and public (global) IP addresses can
typically access both IPv4 and IPv6 services without additional translators in the network. However, it is good to remember that private IPv4 addresses and NATs [RFC2663] have been used and will be used in mobile networks. Public/global IP addresses are also needed for peer-to-peer services: the node needs a public/global IP address that is visible to other nodes. RFC4213]. Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where the tunnel endpoints are not configured, i.e., the links are created dynamically. RFC2766] using Stateless IP/ICMP Translation [RFC2765] is an example of such a mechanism. Translators may be needed in some cases when the communicating nodes do not share the same IP version; in others, it may be possible to avoid such communication altogether. Translation can take place at the network layer (using NAT-like techniques), the transport layer (using a TCP/UDP proxy), or the application layer (using application relays). RFC3901] for more information.
RFC3574] are analyzed here. In all of the scenarios, the UE is part of a network where there is at least one router of the same IP version, i.e., the GGSN, and the UE is connecting to a node in a different network. 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 4) IPv6 UE connecting to an IPv4 node 5) IPv4 UE connecting to an IPv6 node Section 3.2 for more details). Note that this is transparent to the UE. Although the UE is dual stack, the UE may find itself attached to a 3GPP network in which the Serving GPRS Support Node (SGSN), the GGSN, and the Home Location Register (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP contexts. This may happen in early phases of IPv6 deployment, or because the UE has "roamed" from a 3GPP network that supports IPv6 to one that does not. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to
communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism. The tunneling mechanism may require public IPv4 addresses, but there are tunneling mechanisms and deployment scenarios in which private IPv4 addresses may be used, for instance, if the tunnel endpoints are in the same private domain, or the tunneling mechanism works through IPv4 NAT. One deployment scenario uses a laptop computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and an IPv4 PDP context is activated. The tunneling mechanism depends on the laptop computer's support of tunneling mechanisms. Another deployment scenario is performing IPv6-in-IPv4 tunneling in the UE itself and activating an IPv4 PDP context. Closer details for an applicable tunneling mechanism are not analyzed in this document. However, a simple host-to-router (automatic) tunneling mechanism can be a good fit. There is not yet consensus on the right approach, and proposed mechanisms so far include [ISATAP] and [STEP]. Especially ISATAP has had some support in the working group. Goals for 3GPP zero-configuration tunneling are documented in [zeroconf]. This document strongly recommends that the 3GPP operators deploy basic IPv6 support in their GPRS networks. That makes it possible to lessen the transition effects in the UEs. As a general guideline, IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. Public IPv4 addresses are often a scarce resource for the operator, and usually it is not possible for a UE to have a public IPv4 address (continuously) allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive, and difficult to maintain.
public Internet, or any other dual stack node within the operator's IP network. The encapsulation (uplink) and decapsulation (downlink) can be handled by the same network element. Typically, the tunneling handled by the network elements is transparent to the UEs and IP traffic looks like native IPv6 traffic to them. For the applications and transport protocols, tunneling enables end-to-end IPv6 connectivity. IPv6-in-IPv4 tunnels between IPv6 islands can be either static or dynamic. The selection of the type of tunneling mechanism is a policy decision for the operator/ISP deployment scenario, and only generic recommendations can be given in this document. The following subsections are focused on the usage of different tunneling mechanisms when the peer node is in the operator's network or outside the operator's network. The authors note that where the actual 3GPP network ends and which parts of the network belong to the ISP(s) also depend on the deployment scenario. The authors are not commenting on how many ISP functions the 3GPP operator should perform. However, many 3GPP operators are ISPs of some sort themselves. ISP networks' transition to IPv6 is analyzed in [RFC4029].
RFC2766]) in the local network (not recommended as a general solution), 2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 TCP relay configured for a couple of ports only [RFC3142]) or application proxies (e.g., HTTP proxy, SMTP relay) in the local network, or 3. the use of specific-purpose mechanisms (as described above in 2) in the foreign network; these are indistinguishable from the IPv6-enabled services from the IPv6 UE's perspective and are not discussed further here. For many applications, application proxies can be appropriate (e.g., HTTP proxies, SMTP relays, etc.) Such application proxies will not be transparent to the UE. Hence, a flexible mechanism with minimal manual intervention should be used to configure these proxies on IPv6 UEs. Application proxies can be placed, for example, on the GGSN external interface ("Gi"), or inside the service network.
The authors note that [NATPTappl] discusses the applicability of NAT-PT, and [NATPTexp] discusses general issues with all forms of IPv6-IPv4 translation. The problems related to NAT-PT usage in 3GPP networks are documented in Appendix A. Sections 4.1 and 4.2. 1) UE connecting to a node in an IPv4 network through IMS 2) Two IPv6 IMS connected via an IPv4 network For DNS recommendations, we refer to Section 2.4. As DNS traffic is not directly related to the IMS functionality, the recommendations are not in contradiction with the IPv6-only nature of the IMS.
Still, it is difficult to estimate how many non-upgradable legacy IPv4 nodes need to communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed. As the IMS is exclusively IPv6 [3GPP-23.221], for many of the applications in the IMS, some kind of translators may need to be used in the communication between the IPv6 IMS and the legacy IPv4 hosts in cases where these legacy IPv4 hosts cannot be upgraded to support IPv6. This section gives a brief analysis of the IMS interworking issues and presents a high-level view of SIP within the IMS. The authors recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem will be specified as soon as possible as a task within the SIP-related Working Groups in the IETF. The issue of the IPv4/IPv6 interworking in SIP is somewhat more challenging than many other protocols. The control (or signaling) and user (or data) traffic are separated in SIP calls, and thus, the IMS, the transition of IMS traffic from IPv6 to IPv4, must be handled at two levels: 1. Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface) 2. the user data traffic (Mb-interface) In addition, SIP carries an SDP body containing the addressing and other parameters for establishing the user data traffic (the media). Hence, the two levels of interworking cannot be made independently. Figure 1 shows an example setup for IPv4 and IPv6 interworking in IMS. The "Interworking Unit" comprises two internal elements a dual stack SIP server and a transition gateway (TrGW) for the media traffic. These two elements are interconnected for synchronizing the interworking of the SIP signaling and the media traffic.
+-------------------------------+ +------------+ | +------+ | | +--------+ | | |S-CSCF|---| |SIP Serv| |\ | | +------+ | | +--------+ | \ -------- +-|+ | / | | | | | | | | | +------+ +------+ | | + | -| |- | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | | +------+ +------+ | |+----------+| / ------ | |-----------------------------------|| TrGW ||/ +--+ | IPv6 | |+----------+| IPv4 UE | | |Interworking| | IP Multimedia CN Subsystem | |Unit | +-------------------------------+ +------------+ Figure 1: UE using IMS to contact a legacy phone On reception of an INVITE, the SIP server reserves an IP address and a port from the TrGW both for IPv4 and IPv6. Then, the SIP server acts as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the INVITE to insert the transition gateway in the middle of the media flow between the two endpoints. When performing its B2BUA role, the SIP server acts as a UA (User Agent) toward both the IMS and the IPv4 host. Consequently, the SIP server needs to support all the extensions that apply to the session, which are listed in the Require header fields of the SIP messages. This approach has a number of important drawbacks, however. The biggest drawback is that the rewriting of the SDP in the SIP signaling prevents securing the SDP payload between the two endpoints. In addition, it breaks the end-to-end negotiation of SIP extensions required for each session. Therefore, the extensions to be used in a particular session are limited by the extensions supported by the SIP server acting as a B2BUA. That is, the introduction of a new extension requires upgrading not only the UAs but the B2BUAs as well. This analysis clearly shows that a new solution for IPv4-IPv6 interworking in SIP networks is needed. The ability to convey multiple alternative addresses in SDP session descriptions [RFC4091] represents a step in this direction. Given the problems related to the use of B2BUAs, it is recommended that the SIP-related Working Groups quickly work on a solution to overcome the drawbacks of this approach.
Section 3.2. and similar tunneling solutions are applicable also in this scenario. OMA-CP] to configure the GPRS settings. The user can, for example, visit the operator WWW page and subscribe the GPRS Access Point settings to his/her UE and receive the settings via Short Message Service (SMS). After the user has accepted the settings and a PDP context has been activated, he/she can start browsing. The Access Point settings can also be typed in manually or be pre-configured by the operator or the UE manufacturer. DNS server addresses typically also need to be configured in the UE. In the case of IPv4 type PDP context, the (IPv4) DNS server addresses can be received in the PDP context activation (a control plane mechanism). A similar mechanism is also available for IPv6: so- called Protocol Configuration Options Information Element (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use [RFC3736] (or [RFC3315]) and [RFC3646] for receiving DNS server addresses. Active IETF work on DNS discovery mechanisms is ongoing and might result in other mechanisms becoming available over time. The DNS server addresses can also be received over the air (using SMS) [OMA-CP] or typed in manually in the UE. When accessing IMS services, the UE needs to know the Proxy-Call Session Control Function (P-CSCF) IPv6 address. Either a 3GPP- specific PCO-IE mechanism or a DHCPv6-based mechanism ([RFC3736] and [RFC3319]) can be used. Manual configuration or configuration over
the air is also possible. IMS subscriber authentication and registration to the IMS and SIP integrity protection are not discussed here. zeroconf] for more details. - Tunneling mechanisms can be used in 3GPP networks, and only generic recommendations are given in this document. More details can be found, for example, in [RFC4029]. - The authors recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem be specified as soon as possible as a task within the SIP-related Working Groups in the IETF.
V6SEC]; however, these are not specific to 3GPP transition and are therefore out of the scope of this memo. This memo recommends the use of a relatively small number of techniques. Each technique has its own security considerations, including: - native upstream access or tunneling by the 3GPP network operator, - use of routing protocols to ensure redundancy, - use of locally deployed specific-purpose protocol relays and application proxies to reach IPv4(-only) nodes from IPv6-only UEs, or - a specific mechanism for SIP signaling and media translation. The threats of configured tunneling are described in [RFC4213]. Attacks against routing protocols are described in the respective documents and in general in [ROUTESEC]. Threats related to protocol relays have been described in [RFC3142]. The security properties of SIP internetworking are to be specified when the mechanism is specified. In particular, this memo does not recommend the following technique, which has security issues, not further analyzed here: - NAT-PT or other translator as a general-purpose transition mechanism [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002. [3GPP-23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements (Release 5)", December 2002. [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", December 2002. [3GPP-24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP multimedia call control based on SIP and SDP; Stage 3 (Release 5)", December 2002. [3GPP-24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001. [RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, June 2002. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, September 2004. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005. [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005. [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, September 2005. [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S. and H. Wang, "NAT-PT Applicability", Work in Progress, October 2003. [NATPTexp] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", Work in Progress, July 2005. [ROUTESEC] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", Work in Progress, April 2004. [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress, January 2004.
[V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security Considerations", Work in Progress, February 2004. [zeroconf] Nielsen, K., Morelli, M., Palet, J., Soininen, J., and J. Wiljakka, "Goals for Zero-Configuration Tunneling in 3GPP", Work in Progress, October 2004. [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003. [OMA-CP] OMA Client Provisioning: Provisioning Architecture Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile Alliance, 12-Nov-2002. Section 4.1).
Margaret Wasserman, ThingMagic <email@example.com> Juha Wiljakka, Nokia <firstname.lastname@example.org> The authors would like to give special thanks to Spencer Dawkins for proofreading. The authors would like to thank Heikki Almay, Gabor Bajko, Gonzalo Camarillo, Ajay Jain, Jarkko Jouppi, David Kessens, Ivan Laloux, Allison Mankin, Jasminko Mulahusic, Janne Rinne, Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur, and Rod Van Meter for their valuable input.
NATPTappl] discusses the applicability of NAT-PT in more detail. [NATPTexp] discusses general issues with all forms of IPv6-IPv4 translation. 3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface would raise concerns on the overall network reliability. In addition, IPv6 users are expected to use delay-sensitive applications provided by IMS. Hence, there is a need to minimize forwarding delays within the IP backbone. Furthermore, due to the unprecedented number of connections handled by the default routers (GGSN) in 3GPP networks, a network design that forces traffic to go through a single node at the edge of the network (typical NAPT-PT configuration) is not likely to scale. Translation mechanisms should allow for multiple translators, for load sharing and redundancy purposes. To minimize the problems associated with NAPT-PT, the following actions can be recommended: 1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to IPv4" case). 2. Ensure (if possible) that NAPT-PT does not become a single point of failure.
3. Allow for load sharing between different translators. That is, it should be possible for different connections to go through different translators. Note that load sharing alone does not prevent NAPT-PT from becoming a single point of failure.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.