Network Working Group J. Arkko Request for Comments: 3316 G. Kuijpers Category: Informational H. Soliman Ericsson J. Loughney J. Wiljakka Nokia April 2003 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts 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 (2003). All Rights Reserved.
AbstractAs the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks.
1. Introduction.....................................................3 1.1 Scope of this Document......................................3 1.2 Abbreviations...............................................4 1.3 Cellular Host IPv6 Features.................................5 2. Basic IP.........................................................5 2.1 RFC1981 - Path MTU Discovery for IP Version 6...............5 2.2 RFC3513 - IP Version 6 Addressing Architecture..............6 2.3 RFC2460 - Internet Protocol Version 6.......................6 2.4 RFC2461 - Neighbor Discovery for IPv6.......................7 2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration..........8 2.6 RFC2463 - Internet Control Message Protocol for the IPv6....8 2.7 RFC2472 - IP version 6 over PPP.............................9 2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification....9 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6.......9 2.10 RFC2711 - IPv6 Router Alert Option.........................10 2.11 RFC3041 - Privacy Extensions for Address Configuration in IPv6 .........................................10 2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)......10 2.13 RFC3484 - Default Address Selection for IPv6...............11 2.14 DNS........................................................11 3. IP Security.....................................................11 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication...12 3.2 RFC2401 - Security Architecture for the Internet Protocol..12 3.3 RFC2402 - IP Authentication Header.........................12 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.........12 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.........12 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV......................................12 3.7 RFC2406 - IP Encapsulating Security Payload (ESP)..........12 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP..........12 3.9 RFC2408 - The Internet Security Association and Key Management Protocol..............................13 3.10 RFC2409 - The Internet Key Exchange (IKE)..................13 3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec.......................................14 3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms...............14 4. Mobility........................................................14 5. Security Considerations.........................................14 6. References......................................................16 6.1 Normative..................................................16 6.2 Informative................................................18 7. Contributors....................................................19 8. Acknowledgements................................................19 Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model.......20 Authors' Addresses.................................................21 Full Copyright Statement...........................................22
of IPv6 functionality for cellular links other than those listed above. Future changes in 3GPP networks that require changes in host implementations may result in updates to this document. There are different ways to implement cellular hosts: - The host can be a "closed 2G or 3G host" with a very compact size and optimized applications, with no possibility to add or download applications that can have IP communications. An example of such a host is a very simple form of a mobile phone. - The host can be an "open 2G or 3G host" with a compact size, but where it is possible to download applications; such as a PDA-type of phone. If a cellular host has additional interfaces on which IP is used, (such as Ethernet, WLAN, Bluetooth, etc.) then there may be additional requirements for the device, beyond what is discussed in this document. Additionally, this document does not make any recommendations on the functionality required on laptop computers having a cellular interface such as a PC card, other than recommending link specific behavior on the cellular link. This document discusses IPv6 functionality as specified when this document has been written. Ongoing work on IPv6 may affect what is needed from future hosts. The reader should also be advised other relevant work exists for various other layers. Examples of this include the header compression work done in the IETF ROHC group, the analysis of the effects of error-prone links to performance in [RFC- 3155], or the TCP work in [RFC-3481]. Transition mechanisms used by cellular hosts are not described in this document and are left for further study.
ESP Encapsulating Security Payload ETSI European Telecommunications Standards Institute IMS IP Multimedia Subsystem GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 cellular hosts) GPRS General Packet Radio Service GSM Global System for Mobile Communications IKE Internet Key Exchange ISAKMP Internet Security Association and Key Management Protocol MT Mobile Terminal, for example, a mobile phone handset. MTU Maximum Transmission Unit PDP Packet Data Protocol SGSN Serving GPRS Support Node TE Terminal Equipment, for example, a laptop attached through a 3GPP handset. UMTS Universal Mobile Telecommunications System WLAN Wireless Local Area Network RFC-1981] may be used. Cellular hosts with a link MTU larger than the minimum IPv6 link MTU (1280 octets) can use Path MTU Discovery in order to discover the real path MTU. The relative overhead of IPv6 headers is minimized through the use of longer packets, thus making better use of the available bandwidth.
The IPv6 specification [RFC-2460] states in Section 5 that "a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery." If Path MTU Discovery is not implemented then the sending packet size is limited to 1280 octets (standard limit in [RFC-2460]). However, if this is done, the cellular host must be able to receive packets with size up to the link MTU before reassembly. This is because the node at the other side of the link has no way of knowing less than the MTU is accepted. RFC-3513] is a mandatory part of IPv6. RFC-2460]. This specification is a mandatory part of IPv6. By definition, a cellular host acts as a host, not as a router. Implementation requirements for a cellular router are not defined in this document. Consequently, the cellular host must implement all non-router packet receive processing as described in RFC 2460. This includes the generation of ICMPv6 error reports, and the processing of at least the following extension headers: - Hop-by-Hop Options header: at least the Pad1 and PadN options - Destination Options header: at least the Pad1 and PadN options - Routing (Type 0) header: final destination (host) processing only - Fragment header - AH and ESP headers (see also a discussion on the use of IPsec for various purposes in Section 3) - The No Next Header value Unrecognized options in Hop-by-Hop Options or Destination Options extensions must be processed as described in RFC 2460.
The cellular host must follow the packet transmission rules in RFC 2460. The cellular host must always be able to receive and reassemble fragment headers. It will also need to be able to send a fragment header in cases where it communicates with an IPv4 host through a translator (see Section 5 of RFC2460). Cellular hosts should only process routing headers when they are the final destination and return errors if the processing of the routing header requires them to forward the packet to another node. This will also ensure that the cellular hosts will not be inappropriately used as relays or components in Denial-of-Service (DoS) attacks. Acting as the destination involves the following: the cellular hosts must check the Segments Left field in the header, and proceed if it is zero or one and the next address is one of the host's addresses. If not, however, the host must implement error checks as specified in Section 4.4 of RFC 2460. There is no need for the host to send Routing Headers. RFC-2461]. This specification is a mandatory part of IPv6. RFC-2461]. In GPRS and UMTS networks, it is very desirable to conserve bandwidth. Therefore, the cellular host should include a mechanism in upper layer protocols to provide reachability confirmation when two-way IP layer reachability can be confirmed (see RFC-2461, Section 7.3.1). These confirmations will allow the suppression of most NUD- related messages in most cases.
Host TCP implementation should provide reachability confirmation in the manner explained in RFC 2461, Section 7.3.1. The common use of UDP in 3GPP networks poses a problem for providing reachability confirmation. UDP itself is unable to provide such confirmation. Applications running over UDP should provide the confirmation where possible. In particular, when UDP is used for transporting RTP, the RTCP protocol feedback should be used as a basis for the reachability confirmation. If an RTCP packet is received with a reception report block indicating some packets have gone through, then packets are reaching the peer. If they have reached the peer, they have also reached the neighbor. When UDP is used for transporting SIP, responses to SIP requests should be used as the confirmation that packets sent to the peer are reaching it. When the cellular host is acting as the server side SIP node, no such confirmation is generally available. However, a host may interpret the receipt of a SIP ACK request as confirmation that the previously sent response to a SIP INVITE request has reached the peer. RFC-2462]. This specification is a mandatory part of IPv6.
As per RFC 2463 Section 2, ICMPv6 requirements must be fully implemented by every IPv6 node. See also Section 3 for an explanation of the use of IPsec for protecting ICMPv6 communications. RFC-2472] must be supported for cellular hosts that implement PPP. RFC-3041] for site- local and global addresses is not affected by the above procedure. The above procedure is only concerned with assigning the interface identifier used for forming link-local addresses, and does not preclude TE from using other interface identifiers for addresses with larger scopes (i.e., site-local and global). RFC-2473] may be supported if needed for transition mechanisms. RFC-2710] must be supported by cellular hosts. MLD requires that MLD messages be sent for link-local multicast addresses (excluding the all-nodes address). The requirement that MLD be run even for link-local addresses aids layer-two devices (e.g., Ethernet bridges) that attempt to suppress the forwarding of link-layer multicast packets to portions of the layer-two network where there are no listeners. If MLD is used to announce the
presence of listeners for all IP multicast addresses (including link-local multicast addresses), layer 2 devices can snoop MLD messages to reliably determine which portions of a network IP multicast messages need to be forwarded to. RFC-2711] must be supported, and its use is required when MLD is used (see Section 2.9) or when RSVP [RFC-2205] is used. RFC-3041] should be supported. RFC 3041, and privacy in general, is important for the Internet. Cellular hosts may use the temporary addresses as described in RFC 3041. However, the use of the Privacy Extension in an environment where IPv6 addresses are short-lived may not be necessary. At the time this document has been written, there is no experience on how long-lived cellular network address assignments (i.e., attachments to the network) are. The length of the address assignments depends upon many factors such as radio coverage, device status and user preferences. Additionally, the use of temporary address with IPsec may lead to more frequent renegotiation for the Security Associations. Refer to Section 5 for a discussion of the benefits of privacy extensions in a 3GPP network. DHCPv6] may be used. DHCPv6 is not required for address autoconfiguration when IPv6 stateless autoconfiguration is used. However, DHCPv6 may be useful for other configuration needs on a cellular host.
RFC-3484] is needed for cellular hosts. RFC-1034], [RFC- 1035], [RFC-1886], and [RFC-3152]. If DNS is used, a cellular host can perform DNS requests in the recursive mode, to limit signaling over the air interface. Both the iterative and the recursive approach should be supported, however, as the specifications require implementation of the iterative approach, and allow the recursive approach as an option. Furthermore, all DNS servers may not support recursive queries, and the security benefits of DNS Security cannot always be achieved with them. RFC-2401] is a fundamental part of IPv6, and support for AH and ESP is described as mandatory in the specifications. The first part of this section discusses the applicability of IP Security and other security mechanisms for common tasks in cellular hosts. The second part, Sections 3.1 to 3.13, lists the specifications related to IPsec and discusses the use of these parts of IPsec in a cellular context. In general, the need to use a security mechanism depends on the intended application for it. Different security mechanisms are useful in different contexts, and have different limitations. Some applications require the use of TLS [RFC-2246], in some situations IPsec is used. It is not realistic to list all possible services here, and it is expected that application protocol specifications have requirements on what security services they require. Note that cellular hosts able to download applications must be prepared to offer sufficient security services for these applications regardless of the needs of the initial set of applications in those hosts. The following sections list specifications related to the IPsec functionality, and discuss their applicability in a cellular context. This discussion focuses on the use of IPsec. In some applications, a different set of protocols may need to be employed. In particular, the below discussion is not relevant for applications that use other security services than IPsec.
RFC-2104] must be supported. It is referenced by RFC 2403 that describes how IPsec protects the integrity of packets. RFC-2401] must be supported. RFC-2402] must be supported. RFC-2403] must be supported. RFC-2404] must be supported. RFC-2405] may be supported. It is, however, recommended that stronger algorithms than DES be used. Algorithms, such as AES, are undergoing work in the IPsec working group. These new algorithms are useful, and should be supported as soon as their standardization is ready. RFC-2406] must be supported. RFC-2408] and [RFC-2409], is not a mandatory part of the IP Security Architecture. Note, however, that in the cellular environment the IP addresses of a host may change dynamically. For this reason the use of manually configured Security Associations is not practical, as the newest host address would have to be updated to the SA database of the peer as well. Even so, it is not clear that all applications would use IKE for key management. For instance, hosts may use IPsec ESP [RFC-2406] for protecting SIP signaling in the IMS [3GPP-ACC] but provide authentication and key management through another mechanism such as UMTS AKA (Authentication and Key Agreement) [UMTS-AKA].
It is likely that several simplifying assumptions can be made in the cellular environment, with respect to the mandated parts of the IP Security DoI, ISAKMP, and IKE. Work on such simplifications would be useful, but is outside the scope of this document. RFC-2408] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8. RFC-2409] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8. Interactions with the ICMPv6 packets and IPsec policies may cause unexpected behavior for IKE-based SA negotiation unless some special handling is performed in the implementations. The ICMPv6 protocol provides many functions, which in IPv4 were either non-existent or provided by lower layers. For instance, IPv6 implements address resolution using an IP packet, ICMPv6 Neighbor Solicitation message. In contrast, IPv4 uses an ARP message at a lower layer. The IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is not easy. For instance, a simple policy of protecting all traffic between two hosts on the same network would trap even address resolution messages, leading to a situation where IKE can't establish a Security Association since in order to send the IKE UDP packets one would have had to send the Neighbor Solicitation Message, which would have required an SA. In order to avoid this problem, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages must not lead to the use of IKE-based SA negotiation. The Redirect message should not lead to the use of IKE-based SA negotiation. Other ICMPv6 messages may use IKE-based SA negotiation as is desired in the Security Policy Data Base. Note that the above limits the usefulness of IPsec in protecting all ICMPv6 communications. For instance, it may not be possible to protect the ICMPv6 traffic between a cellular host and its next hop
router. (Which may be hard in any case due to the need to establish a suitable public key infrastructure. Since roaming is allowed, this infrastructure would have to authenticate all hosts to all routers.) RFC-2410] must be supported. RFC-2451] must be supported if encryption algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA, Blowfish, 3DES. RFC3041] may be used in cellular hosts. However, it should be noted that in the 3GPP model, the network would assign new addresses, in most cases, to hosts in roaming situations and typically, also when the cellular hosts activate a PDP context. This means that 3GPP networks will already provide a limited form of addressing privacy, and no global tracking of a single host is possible through its address. On the other hand, since a GGSN's coverage area is expected to be very large when compared to currently deployed default routers (no handovers between GGSNs are possible), a cellular host can keep an address for a long time. Hence, IPv6 addressing privacy can be used for additional privacy during the time the host is on and in the same
area. The privacy features can also be used to e.g., make different transport sessions appear to come from different IP addresses. However, it is not clear that these additional efforts confuse potential observers any further, as they could monitor only the network prefix part. - The use of various security services such as IPsec or TLS in the connection of typical applications in cellular hosts is discussed in Section 3 and recommendations are given there. - Section 3 also discusses under what conditions it is possible to provide IPsec protection of e.g., ICMPv6 communications. - The airtime used by cellular hosts is expensive. In some cases, users are billed according to the amount of data they transfer to and from their host. It is crucial for both the network and the users that the airtime is used correctly and no extra charges are applied to users due to misbehaving third parties. The cellular links also have a limited capacity, which means that they may not necessarily be able to accommodate more traffic than what the user selected, such as a multimedia call. Additional traffic might interfere with the service level experienced by the user. While Quality of Service mechanisms mitigate these problems to an extent, it is still apparent that DoS aspects may be highlighted in the cellular environment. It is possible for existing DoS attacks that use for instance packet amplification to be substantially more damaging in this environment. How these attacks can be protected against is still an area of further study. It is also often easy to fill the cellular link and queues on both sides with additional or large packets. - Within some service provider networks, it is possible to buy a prepaid cellular subscription without presenting personal identification. Attackers that wish to remain unidentified could leverage this. Note that while the user hasn't been identified, the equipment still is; the operators can follow the identity of the device and block it from further use. The operators must have procedures in place to take notice of third party complaints regarding the use of their customers' devices. It may also be necessary for the operators to have attack detection tools that enable them to efficiently detect attacks launched from the cellular hosts. - Cellular devices that have local network interfaces (such as IrDA or Bluetooth) may be used to launch attacks through them, unless the local interfaces are secured in an appropriate manner. Therefore, local network interfaces should have access control to prevent others from using the cellular host as an intermediary.
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC-1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995. [RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC-2104] Krawczyk, K., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC-2403] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998. [RFC-2404] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within ESP and AH", RFC 2404, November 1998. [RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998. [RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC-2463] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998. [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999. [RFC-2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001. [RFC-3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC-3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [3GPP-ACC] 3GPP Technical Specification 3GPP TS 33.203, "Technical Specification Group Services and System Aspects; 3G Security; Access security for IP-based services (Release 5)", 3rd Generation Partnership Project, March 2002. [3GPP-IMS] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228) [3GPP-IPv6] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects "Architectural requirements" (TS 23.221) [DHCPv6] Bound, J., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in progress. [RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC-2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC-3314] Wasserman, M., Editor, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, RFC 3314, September 2002. [RFC-3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", BCP 71, RFC 3481, February 2003. [UMTS-AKA] 3GPP Technical Specification 3GPP TS 33.102, "Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 4)", 3rd Generation Partnership Project, December 2001.
Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.