Network Working Group P. Eronen Internet-Draft Nokia Expires: December 7, 2007 June 5, 2007 IPv6 Configuration in IKEv2 draft-eronen-ipsec-ikev2-ipv6-config-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Eronen Expires December 7, 2007 [Page 1] Internet-Draft IPv6 Configuration in IKEv2 June 2007 Abstract When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces. Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Current Limitations . . . . . . . . . . . . . . . . . . . . . 6 3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 6 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 6 3.3. Receiving Multicast Traffic . . . . . . . . . . . . . . . 6 3.4. Interface Identifier Selection . . . . . . . . . . . . . . 6 3.5. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 7 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Main Requirements . . . . . . . . . . . . . . . . . . . . 8 4.2. Desirable Non-Functional Properties . . . . . . . . . . . 8 4.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Solution Sketches . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Virtual Link Properties . . . . . . . . . . . . . . . . . 10 5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. First Sketch . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Eronen Expires December 7, 2007 [Page 2] Internet-Draft IPv6 Configuration in IKEv2 June 2007 1. Introduction and Problem Statement In typical remote access VPN use (client to VPN gateway), the client needs an IP address in the network protected by the security gateway. IKEv2 includes a feature called "configuration payloads" that allows the gateway to dynamically assign a temporary address to the client [IKEv2]. For IPv4, the message exchange would look as follows: Client Gateway -------- --------- HDR(IKE_SA_INIT), SAi1, KEi, Ni --> <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] HDR(IKE_AUTH), SK { IDi, CERT, [CERTREQ], AUTH, [IDr], CP(CFG_REQUEST) = { INTERNAL_IP4_ADDRESS(), INTERNAL_IP4_DNS() }, SAi2, TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> <-- HDR(IKE_AUTH), SK { IDr, CERT, AUTH, CP(CFG_REPLY) = { INTERNAL_IP4_ADDRESS(192.0.1.234), INTERNAL_IP4_DNS(10.11.22.33) }, SAr2, TSi = (0, 0-65535, 192.0.1.234-192.0.1.234), TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } Figure 1: IPv4 configuration The IPv4 case has been implemented by various vendors, and in general works well. IKEv2 also defines almost identical configuration payloads for IPv6: Eronen Expires December 7, 2007 [Page 3] Internet-Draft IPv6 Configuration in IKEv2 June 2007 Client Gateway -------- --------- HDR(IKE_AUTH), SK { IDi, CERT, [CERTREQ], AUTH, [IDr], CP(CFG_REQUEST) = { INTERNAL_IP6_ADDRESS(), INTERNAL_IP6_DNS() }, SAi2, TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF), TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } --> <-- HDR(IKE_AUTH), SK { IDr, CERT, AUTH, CP(CFG_REPLY) = { INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64), INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) }, SAr2, TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5), TSr = (0, 0-65535, 0:0:0:0:0:0:0:0: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } Figure 2: IPv6 configuration In other words, IPv6 is basically treated as IPv4 with larger addresses. As noted in [RFC4718], this does not fully follow the "normal IPv6 way of doing things". The IPsec tunnels are not full- featured "interfaces" in the IPv6 addressing architecture [IPv6Addr] sense. For example, they do not necessarily have link-local addresses, and this may complicate the use of protocols that assume them. This document describes what exactly are the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2-based VPNs to set up full-featured virtual IPv6 interfaces. Eronen Expires December 7, 2007 [Page 4] Internet-Draft IPv6 Configuration in IKEv2 June 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. When messages containing IKEv2 payloads are described, optional payloads are shown in brackets (for instance, "[FOO]"), and a plus sign indicates that a payload can be repeated one or more times (for instance, "FOO+"). Eronen Expires December 7, 2007 [Page 5] Internet-Draft IPv6 Configuration in IKEv2 June 2007 3. Current Limitations This section explores the limitations of the current IPv6 configuration mechanism. The IKEv2 specification does not always fully describe the semantics associated with configuration payloads, only their on-the-wire format. This section assumes the semantics implied by Figure 2. It is possible that many of the limitations described here could be solved by specifying additional semantics for these configuration payloads. 3.1. Multiple Prefixes In Figure 2 only a single IPv6 address (from a single prefix) is assigned. The specification does allow the client to include multiple INTERNAL_IP6_ADDRESS attributes in its request, but the gateway cannot assign more addresses than the client requested. Multiple prefixes are useful for site renumbering, host-based site multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In all of these cases, the gateway has better information on how many different addresses (from different prefixes) the client should be assigned. 3.2. Link-Local Addresses The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 addresses of all types are assigned to interfaces, not nodes. [..] All interfaces are required to have at least one Link-Local unicast address". Currently, the virtual interface created by IKEv2 configuration payloads does not have link-local addresses. This violates [IPv6Addr] and prevents the use of protocols that require link-local addresses, such as [MLDv2]. 3.3. Receiving Multicast Traffic Even if MLD would work, the traffic selectors negotiated in Figure 2 do not allow receiving multicast traffic. 3.4. Interface Identifier Selection In the message exchange shown in Figure 2, the gateway chooses the interface ID used by the client. It is also possible for the client to request a specific interface ID; the gateway then chooses the prefix part. Eronen Expires December 7, 2007 [Page 6] Internet-Draft IPv6 Configuration in IKEv2 June 2007 This approach complicates the use of Cryptographically Generates Addresses [CGA]. With CGAs, the interface ID cannot be calculated before the prefix is known. The client could first obtain a non-CGA address to determine the prefix, and then send a separate CFG_REQUEST to obtain a CGA address with the same prefix. However, this approach requires that the IKEv2 software component provides an interface the component managing CGAs; an ugly implementation dependency that would be best avoided. Similar concerns apply to other cases where the client has some interest in what interface ID is being used, such as Hash-Based Addresses [HBA] and privacy addresses [RFC3041]. Without CGAs and HBAs, VPN clients are not able to fully use IPv6 features such as [SHIM6] or enhanced Mobile IPv6 route optimization [RFC4866]. 3.5. Sharing VPN Access Some VPN clients may want to share the VPN connection with other devices (e.g., from a cell phone to a laptop, or vice versa) via some local area network connection (such as Wireless LAN or Bluetooth). It is to be determined how common this use case would actually be; e.g., how likely it is that security policies would allow this. If sharing of VPN access is done, it is quite obviously easier if you get more than one address (which avoids NAT), and with DHCPv6 prefix delegation [RFC3633] you could even avoid [NDProxy]. Eronen Expires December 7, 2007 [Page 7] Internet-Draft IPv6 Configuration in IKEv2 June 2007 4. Design Goals 4.1. Main Requirements o Client can obtain a whole prefix, and use arbitrary Interface IDs without requiring IKEv2 signaling for each Interface ID. o Client can be assigned multiple prefixes for use on the client- gateway link. The client does not have to know beforehand how many prefixes are needed. o (Optional/To be determined) Client can be assigned multiple prefixes for use on other links; e.g. the client could advertise these prefixes on a local WLAN link. Gateway routes traffic to these prefixes to the client. o The solution should avoid periodic messages over the VPN tunnel. o The solution should avoid Duplicate Address Detection (DAD) over the VPN tunnel. o Multicast works. That is, the client is able to send multicast packets (tunneled to the gateway via unicast), join multicast groups using [MLDv2], and receive multicast packets (tunneled from the gateway to the client via unicast). o Re-authentication works: the client can start a new IKE SA and continue using the same "virtual link" (with same addresses etc.). o Compatibility with other IPsec uses: Configuring a virtual IPv6 link should not prevent the peers from using IPsec/IKEv2 for other uses. o Compatibility with current IPv6 configuration: Although the current IPv6 mechanism is not widely implemented, new solutions should not preclude its use (e.g., by defining incompatible semantics for the existing payloads). o Compatibility with current IPv4 configuration: it should be possible to use the existing IPv4 configuration mechanism within the same IKE_SA. 4.2. Desirable Non-Functional Properties o Clean implementation dependencies. o Re-use existing mechanisms, such as [AUTOCONF] and [DHCPv6] as much as possible; as explained in [IPConfig], creating IKEv2- Eronen Expires December 7, 2007 [Page 8] Internet-Draft IPv6 Configuration in IKEv2 June 2007 specific mechanisms should be avoided. o Avoid the Not Invented Here (NIH) syndrome: There were several proposals how to do IP address configuration in IKEv2, and the IPsec WG chose one of them. Any significant changes should be motivated by real technical needs, not by dislike of the proposal that was chosen. 4.3. Non-Goals Mobile IPv6 already defines how it interacts with IPsec/IKEv2 [RFC4877], and this document is not changing any of that. Eronen Expires December 7, 2007 [Page 9] Internet-Draft IPv6 Configuration in IKEv2 June 2007 5. Solution Sketches 5.1. Link Model Currently, the rest of this section assumes the point-to-point link model [Multilink]. In other words, the connection between the client and the VPN gateway is treated as a virtual point-to-point link, and prefixes assigned to this link are not shared with any other link (other VPN clients connected to the same gateway). Other possibilites (multi-access or NBMA) may need to be considered as well... 5.2. Virtual Link Properties Assigning a new IPv6 address to the client creates a new "virtual" IPv6 interface, and "virtual link" between the client and the gateway. The interface/link is created by some IKEv2 signaling, and it is destroyed once it is no longer used by any IKE_SA. However: o The link is not an IPsec SA; at any time, there can be zero or more IPsec SAs covering traffic on this link. o The link is not a single IKE SA; to support reauthentication, it must be possible to identify the same link in another IKE SA. o It is TBD whether a single IKE SA needs to support multiple virtual links. o The link is not uniquely identified by the IKE peer identities (IDi and IDr) because IDi is often a user identity that can be used on multiple hosts at the same time. o The link is not uniquely identified by the outer IP addresses of the peers (due to NAT Traversal and MOBIKE). o Not all IPsec-protected traffic between the peers is necessarily related to the virtual link (although in the simplest VPN client- to-gateway scenario it will be). 5.3. Discussion Reauthentication / virtual link identifier For reauthentication to work, we need an identifier that uniquely identifies the virtual link when the second IKE_SA is created. Some possible alternatives are the IKE SPIs of the IKE_SA where the virtual link was "created" (assuming we can't have multiple Eronen Expires December 7, 2007 [Page 10] Internet-Draft IPv6 Configuration in IKEv2 June 2007 virtual links within the same IKE_SA), a new identifier given at that time, or any unique prefix assigned to that link. Compatibility with other IPsec uses Compatibility with other IPsec uses probably requires that when a CHILD_SA is created, both peers can determine whether the CHILD_SA applies to the virtual interface (at the end of the virtual link), or the real interfaces IKEv2 messages are being sent over. Otherwise, things like traffic selector narrowing get tricky. The simplest solution would be to add an extra payload to some CREATE_CHILD_SA requests, containing e.g. the virtual link identifier. Prefix assignment Prefixes could be assigned in IKEv2 messages or Router Advertisements sent inside the tunnel. Both would work; both have some advantages. Duplicate Address Detection DAD can be avoided if the prefixes are not shared with any other link, and the VPN gateway does not configure any addresses from those prefixes (similar as in [IPv6PPP]). But how does the client know this is the case? We could specify that using some particular IKE payload always means this; or we could add a flag to some payload. Ingress filtering As with any other link (physical or virtual), the gateway would use ingress filtering to prevent address spoofing. However, if the peer is also a router, the filters can allow other prefixes than those assigned to the virtual link. Should these filters be visible in the traffic selectors negotiated inside IKE? 5.4. First Sketch NOTE: this is still very preliminary, and may change completely! Eronen Expires December 7, 2007 [Page 11] Internet-Draft IPv6 Configuration in IKEv2 June 2007 1) During IKE_AUTH, client sends a new Configuration Payload, INTERNAL_IP6_LINK that contains the Interface ID it will use for the link-local address (other addresses may use other Interface IDs). CP(CFG_REQUEST) = { INTERNAL_IP6_LINK(client_link_local_interface_id) } TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> The gateway replies with its own Interface ID for link-local address, and a new identifier for the virtual link. CP(CFG_REPLY) = { INTERNAL_IP6_LINK(link_id, gateway_link_local_interface_id) } TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) At this point, both peers configure the virtual interface with the link-local addresses. (This step is pretty much based on [IPv6PPP]) 2) The next step is unicast prefix configuration; this is simply RS/RA sent over the IPsec SA (possibly followed by DHCPv6 if RA had the M flag set). 3) Creating and rekeying IPsec SAs: exchange initiator includes N(LINK_ID) notification in the CREATE_CHILD_SA request. The notification data contains the link_id. 4) Reauthentication: when creating a new IKE_SA, client includes the link_id in INTERNAL_IP6_LINK CFG_REQUEST. Eronen Expires December 7, 2007 [Page 12] Internet-Draft IPv6 Configuration in IKEv2 June 2007 6. IANA Considerations This document has no IANA actions. (This may change in future versions of this document.) Eronen Expires December 7, 2007 [Page 13] Internet-Draft IPv6 Configuration in IKEv2 June 2007 7. Security Considerations To be written. (The security consideration should be pretty much the same as for current configuration payloads.) Eronen Expires December 7, 2007 [Page 14] Internet-Draft IPv6 Configuration in IKEv2 June 2007 8. Acknowledgments The author would like to thank Mohan Parthasarathy and Yaron Sheffer for their valuable comments. Many of the challenges associated with IPsec-protected "virtual interfaces" have been identified before: for example, in the context of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some of the limitations of assigning a single IPv6 address were identified in [RFC3314]. Eronen Expires December 7, 2007 [Page 15] Internet-Draft IPv6 Configuration in IKEv2 June 2007 9. References 9.1. Normative References [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 9.2. Informative References [AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2006. [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-shim6-hba-03 (work in progress), June 2007. [IPConfig] Aboba, B. and D. Thaler, "Principles of Internet Host Configuration", draft-aboba-ip-config-01 (work in progress), May 2007. [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [IPv6ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", draft-ietf-ipv6-over-ppp-v2-03 (work in progress), May 2007. [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Eronen Expires December 7, 2007 [Page 16] Internet-Draft IPv6 Configuration in IKEv2 June 2007 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [Multilink] Thaler, D., "Multilink Subnet Issues", draft-iab-multilink-subnet-issues-03 (work in progress), January 2007. [NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project 3GPP) Standards", RFC 3314, September 2002. [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4193, May 2007. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007. [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Eronen Expires December 7, 2007 [Page 17] Internet-Draft IPv6 Configuration in IKEv2 June 2007 Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work in progress), May 2007. [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in progress), October 2002. Eronen Expires December 7, 2007 [Page 18] Internet-Draft IPv6 Configuration in IKEv2 June 2007 Author's Address Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Eronen Expires December 7, 2007 [Page 19] Internet-Draft IPv6 Configuration in IKEv2 June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Eronen Expires December 7, 2007 [Page 20]