Network Working Group B. Aboba, Ed. INTERNET-DRAFT Elwyn Davies Category: Informational Internet Architecture Board <draft-iab-net-transparent-03.txt> 22 February 2007 Reflections on Internet Transparency 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 August 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). All Rights Reserved. Abstract This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. IAB Informational [Page 1]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 Table of Contents 1. Introduction .......................................... 3 2. Additional Transparency Issues ........................ 5 2.1 Application Filtering ........................... 5 2.2 Quality of Service .............................. 6 2.3 Application Layer Gateways ...................... 7 2.4 IPv6 Address Restrictions ....................... 8 2.5 DNS Namespace Mangling .......................... 9 2.6 Load Balancing and Redirection .................. 10 3. Security Considerations ............................... 11 4. IANA Considerations ................................... 11 5. References ............................................ 11 5.1 Informative References .......................... 11 Acknowledgments .............................................. 13 Appendix A - IAB Members ..................................... 14 Authors' Addresses ........................................... 14 Full Copyright Statement ..................................... 15 Intellectual Property ........................................ 15 IAB Informational [Page 2]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 1. Introduction In the past, the IAB has published a number of documents relating to Internet transparency and the end-to-end principle, and other IETF documents have also touched on these issues as well. These documents articulate the general principles on which the Internet architecture is based, as well as the core values which the Internet community seeks to protect going forward. This document reaffirms those principles, describes the concept of "oblivious transport" as developed in the DARPA NewArch project [NewArch] and addresses a number of new transparency issues. A network that does not filter or transform the data that it carries may said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility which is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success. "Architectural Principles of the Internet" [RFC1958] Section 2 describes the core tenets of the Internet architecture: However, in very general terms, the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network. The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web. This connectivity requires technical cooperation between service providers, and flourishes in the increasingly liberal and competitive commercial telecommunications environment. "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture" [RFC3724] Section 4.1.1 describes some of the desirable consequences of this approach: One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes. The counterargument - that many end nodes are now essentially closed boxes which are not updatable and that most users don't want to update them anyway - does not apply to all nodes and all users. Many end nodes are still user configurable and a sizable percentage of users are "early adopters," who are willing to put up with a certain amount of technological grief in order to try out a new idea. And, even for IAB Informational [Page 3]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 the closed boxes and uninvolved users, downloadable code that abides by the end-to-end principle can provide fast service innovation. Requiring someone with a new idea for a service to convince a bunch of ISPs or corporate network administrators to modify their networks is much more difficult than simply putting up a Web page with some downloadable software implementing the service. Yet even while the Internet has greatly expanded both in size and in application diversity, the degree of transparency has diminished. "Internet Transparency" [RFC2775] notes some of the causes for the loss of Internet transparency and analyzes their impact. This includes discussion of Network Address Translators (NATs), firewalls, application level gateways (ALGs), relays, proxies, caches, split Domain Name Service (DNS), load balancers, etc. [RFC2775] also analyzes potential future directions that could lead to the restoration of transparency. Section 6 summarizes the conclusions: Although the pure IPv6 scenario is the cleanest and simplest, it is not straightforward to reach it. The various scenarios without use of IPv6 are all messy and ultimately seem to lead to dead ends of one kind or another. Partial deployment of IPv6, which is a required step on the road to full deployment, is also messy but avoids the dead ends. While full restoration of Internet transparency through the deployment of IPv6 remains a goal, the Internet's growing role in society, the increasing diversity of applications and the continued growth in security threats has altered the balance between transparency and security. While transparency provides great flexibility, it also makes it easier to deliver unwanted as well as wanted traffic. Unwanted traffic is increasingly cited as a justification for limiting transparency. The growing role of the Internet in society has altered the balance between transparency and security, and the diverse goals of the interested parties make these tradeoffs inherently complex. Since many of the fundamental forces that have led to a reduction in the transparency of the IPv4 Internet also may play a role in the IPv6 Internet, the transparency of the IPv6 Internet is not pre- ordained, but rather represents an ideal whose maintenance will require significant ongoing effort. As noted in [NewArch], the technical cooperation which once characterized the development of the Internet has increasingly given way to a tussle between the interests of subscribers, vendors, IAB Informational [Page 4]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 providers and society at large. Oblivious transport may be desired by developers seeking to deploy new services; providers may desire to block unwanted traffic in the core before it impacts subscribers; vendors and providers may wish to enable delivery of "value added" services in the network that enable them to differentiate their offerings; subscribers may be sympathetic to either point of view, depending on their interests; society at large may wish to block "offensive" material and monitor traffic that shows criminal intent. While there is no architectural "fix" that can restore oblivious transport while satisfying the interests of all parties, it is possible for providers to provide subscribers with information about the nature of the services being provided. Subscribers need to be aware of whether they are receiving oblivious transport, and if not, how the service affects their traffic. Since the publication of the previously cited IAB statements, new technologies have been developed, and views on existing technology have changed. In some cases, these new technologies impact oblivious transport, and subscribers need to be aware of the implications for their service. 2. Additional Transparency Issues 2.1. Application Filtering Since one of the virtues of the Internet architecture is the ease with which new applications can be deployed, practices which restrict the ability to deploy new applications have the potential to reduce innovation. One such practice is the filtering of applications without customer consent. While provider filtering may be useful to address security issues such as attacks on provider infrastructure or denial of service attacks, greater flexibility is provided by allowing filtering to be determined by the customer. Typically this would be implemented at the edges, such as within provider access routers (e.g. outsourced firewall services), customer premise equipment (e.g. access firewalls), or on hosts (e.g. host firewalls). Deployment of filtering at the edges provides customers with the flexibility to choose which applications they wish to block or allow, whereas filtering in the core may not permit hosts to communicate even when the communication would conform to the appropriate use policies of the administrative domains to which those hosts belong. In practice, application filtering is difficult to successfully implement without customer consent, since over time developers will tend to re-engineer filtered protocols so as to avoid the filters. IAB Informational [Page 5]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 Thus over time, application filtering is likely to result in interoperability issues or unnecessary complexity. These costs come without the benefit of effective filtering since many application protocols began to use HTTP as a transport protocol after application developers observed that firewalls allow HTTP traffic while dropping packets for unknown protocols. In addition to architectural concerns, application filtering also raises issues of disclosure and end user consent. As pointed out in "Terminology for Describing Internet Connectivity" [RFC4084] services advertised as providing "Internet connectivity" differ considerably in their capabilities, leading to confusion. The document defines terminology relating to Internet connectivity, including "Web connectivity", "Client connectivity only, without a public address", "Client only, public address", "Firewalled Internet Connectivity", and "Full Internet Connectivity". With respect to "Full Internet Connectivity", [RFC4084] Section 2 notes: Filtering Web proxies, interception proxies, NAT, and other provider-imposed restrictions on inbound or outbound ports and traffic are incompatible with this type of service. Servers ... are typically considered normal. The only compatible restrictions are bandwidth limitations and prohibitions against network abuse or illegal activities. [RFC4084] Section 4 describes disclosure obligations that apply to all forms of service limitation, whether applied on outbound or inbound traffic: More generally, the provider should identify any actions of the service to block, restrict, or alter the destination of, the outbound use (i.e., the use of services not supplied by the provider or on the provider's network) of applications services. In essence, [RFC4084] calls for providers to declare the ways in which the service provided departs from oblivious transport. Since the lack of oblivious transport within transit networks will also affect transparency, this also applies to providers over whose network the subscriber's traffic may travel. 2.2. Quality of Service Deployment of Quality of Service (QoS) technology has potential implications for Internet transparency since the QoS experienced by a flow can make the Internet more or less oblivious to that flow. Specifically, QoS classes such as "default" [RFC2474] or "lower effort" [RFC3662] may experience higher random loss rates than others IAB Informational [Page 6]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 such as "assured forwarding" [RFC2597]. Conversely, bandwidth- limited QoS classes such as "expedited forwarding" [RFC3246] may experience systematic packet loss if they exceed their assigned bandwidth. Other QoS mechanisms such as load balancing may have side-effects such as re-ordering of packets, which may have serious impact on perceived performance. Thus, while QoS support is highly desirable in order for real time services to coexist with elastic services, it is not without impact on packet delivery. The disclosure and consent obligations referred to in [RFC4084] Section 4 also apply to QoS mechanisms. Since the publication of [RFC4084], the varieties and types of "bandwidth limitations" have expanded. In some cases, these restrictions may go beyond simple average or peak bandwidth limitations. QoS implementations that reduce the ability to deploy new applications on the Internet are similar in effect to other transparency barriers. Since arbitrary or severe bandwidth limitations can make an application unusable, the introduction of application-specific bandwidth limitations is equivalent to application filtering from a user's standpoint. When used to restrict the ability to deploy new applications, QoS mechanisms are incompatible with "Full Internet Connectivity" as defined in [RFC4084]. For example, using QoS mechanisms to discriminate against traffic not matching a set of services or addresses has a similar effect to deployment of a highly restrictive firewall. Requiring an authenticated RSVP reservation [RFC2747][RFC3182] for a flow to avoid severe packet loss has a similar effect to deployment of authenticated firewall traversal. As with application filtering, there may be valid uses for customer-imposed QoS restrictions. For example, a customer may wish to limit the bandwidth consumed by peer- to-peer file sharing services, so as to limit the impact on mission critical applications. 2.3. Application Layer Gateways (ALGs) The IAB has devoted considerable attention to Network Address Translation (NAT), so that there is little need to repeat that discussion here. However, with the passage of time, it has become apparent that there are problems inherent in the deployment of Application Layer Gateways (ALGs) (frequently embedded within firewalls and devices implementing NAT). [RFC2775] Section 3.5 states: If the full range of Internet applications is to be used, NATs IAB Informational [Page 7]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 have to be coupled with application level gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be updated whenever a new address-dependent application comes along. In practice, NAT functionality is built into many firewall products, and all useful NATs have associated ALGs, so it is difficult to disentangle their various impacts. With the passage of time and development of NAT traversal technologies such as IKE NAT-T [RFC3947], Teredo [RFC4380] and STUN [RFC3489] it has become apparent that ALGs represent an additional barrier to transparency. In addition to posing barriers to the deployment of new applications not yet supported by ALGs, ALGs may create difficulties in the deployment of existing applications as well as updated versions. For example, in the development of IKE NAT-T, additional difficulties were presented by "IPsec Helper" ALGs embedded within NATs. It should be stressed that these difficulties are inherent in the architecture of ALGs, rather than merely an artifact of poor implementations. No matter how well an ALG is implemented, over time barriers to transparency will emerge, so that the notion of a "transparent ALG" is a contradiction in terms. In particular, DNS ALGs present a host of issues, including incompatibilities with DNSSEC that prevent deployment of a secure naming infrastructure even if all the endpoints are upgraded. For details, see "Reasons to Move NAT-PT to Historic Status" [NATPT] Section 3. 2.4. IPv6 Address Restrictions [RFC2775] Section 5.1 states: Note that it is a basic assumption of IPv6 that no artificial constraints will be placed on the supply of addresses, given that there are so many of them. Current practices by which some ISPs strongly limit the number of IPv4 addresses per client will have no reason to exist for IPv6. Any limits on the number of IPv6 addresses usable on a link provides an incentive for the deployment of NAT with IPv6. The introduction of NAT for IPv6 would represent a barrier to transparency, and therefore is to be avoided if at all possible. 2.4.1. Allocation of IPv6 Addresses by Providers In order to encourage deployments of IPv6 to use oblivious transport, it is important that IPv6 networks of all sizes be supplied with a IAB Informational [Page 8]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 prefix sufficient to enable allocation of addresses and sub-networks for all the hosts and links within their network. Initial address allocation policy suggested allocating a /48 prefix to "small" sites which should handle typical requirements. Any changes to allocation policy should take into account the transparency reduction that will result from further restriction. For example, provider provisioning of a single /64 without support for prefix delegation or (worse still) a longer prefix, would represent a restriction on the availability of IPv6 addresses that could encourage the deployment of IPv6 NAT. 2.4.2. IKEv2 Issues with IPv6 address assignment mechanisms in IKEv2 [RFC4306] are described in [IKEv2Clar]: IKEv2 also defines configuration payloads for IPv6. However, they are based on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doing things"... In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery. IKEv2 provides for the assignment of a single IPv6 address, using the INTERNAL_IP6_ADDRESS attribute. If this is the only attribute supported for IPv6 address assignment, then only a single IPv6 address will be available. The INTERNAL_IP6_SUBNET attribute enables the host to determine the sub-networks accessible directly through the secure tunnel created; it could potentially be used to assign one or more prefixes to the IKEv2 initiator that could be used for address creation. However, this does not enable the host to obtain prefixes that can be delegated. The INTERNAL_IP6_DHCP attribute provides the address of a DHCPv6 server, potentially enabling use of DHCPv6 prefix delegation [RFC3633] to obtain additional prefixes. However, in order for implementers to utilize these options in an interoperable way, clarifications to the IKEv2 specification appear to be needed. 2.5. DNS Namespace Mangling In "IAB Technical Comment on the Unique DNS Root" [RFC2826] the technical arguments for a unique root were presented. One of the premises in [RFC2826] is that a common namespace and common semantics applied to these names, is needed for effective communication between two parties. The document argues that this principle can only be met when one unique root is being used and when the domains are maintained by single owners or maintainers. IAB Informational [Page 9]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 Because [RFC4084] targets only on IP service terms and does not talk about namespace issues, it does not refer to [RFC2826]. We stress that for proper IP service the use of a unique root for the DNS namespace is essential. Since the publication of [RFC2826] there have been reports of providers implementing recursive nameservers and/or DNS forwarders that replace answers that indicate that a name does not exist in the DNS hierarchy with a name and an address record that hosts a web service that is supposed to be useful for end-users. The effect of this modification is similar to placement of a wildcard in top-level domains. Although wildcard labels in top-level domains lead to problems that are described elsewhere (such as "The Role of Wildcards in the Domain Name System" [RFC4592]) they do not strictly violate the DNS protocol. This is not the case where modification of answers takes place in the middle of the path between authoritative servers and the stub resolvers that provide the answers to applications. [RFC2826] section 1.3 states: Both the design and implementations of the DNS protocol are heavily based on the assumption that there is a single owner or maintainer for every domain, and that any set of resources records associated with a domain is modified in a single-copy serializable fashion. In particular the DNSSEC protocol described in "Protocol Modifications for the DNS Security Extensions" [RFC4035] has been designed to verify that DNS information has not been modified between the moment they have been published on an authoritative server and the moment the validation takes place. Since that verification can take place at the application level, any modification by a recursive forwarder will cause validation failures, disabling the improved security DNSSEC is intended to provide. 2.6. Load Balancing and Redirection In order to provide information that is adapted to the locale from which a request is made or to provide a speedier service, techniques have been deployed which result in packets being redirected or taking a different path dependent on where the request originates. For example, requests may be distributed among servers using "reverse NAT" (which modifies the destination rather than the source address); responses to DNS requests may be altered; HTTP "gets" may be re- directed; or specific packets may be diverted onto overlay networks. IAB Informational [Page 10]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 Provided these services are well-implemented they can provide value; however, transparency reduction or service disruption can also result: [1] The use of "reverse NAT" to balance load among servers supporting IPv6 would adversely affect the transparency of the IPv6 Internet. [2] DNS re-direction is typically based on the source address of the query, which may not provide information on the location of the host originating the query. As a result, a host configured with the address of a distant DNS server could find itself pointed to a server near the DNS server, rather a server near to the host. HTTP re-direction does not encounter this issue. [3] If the packet filters that divert packets onto overlay networks are misconfigured, this can lead to packets being misdirected onto the overlay and delayed or lost if the far end cannot return them to the global Internet. [4] The use of anycast needs to be carefully thought out so that service can be maintained in the face of routing changes. 3. Security Considerations Several transparency issues discussed in this document (NATs, transparent proxies, DNS namespace mangling) weaken existing end-to- end security guarantees and interfere with the deployment of protocols that would strengthen end-to-end security. 4. IANA Considerations This document has no actions for IANA. 5. References 5.1. Informative References [IKEv2Clar] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", Internet draft (work in progress), draft-eronen-ipsec-ikev2-clarifications-09.txt, May 2006. [NATPT] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Historic Status", Internet draft (work in progress), draft-ietf- v6ops-natpt-to-historic-00.txt, February 2007. [NewArch] Clark, D. et al., "New Arch: Future Generation Internet Architecture", IAB Informational [Page 11]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001. [RFC3246] Davie, B., Charny, A., Bennett, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3662] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort Per- Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003. [RFC3724] Kempf, J. and R. Austein, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004. IAB Informational [Page 12]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 [RFC3947] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", RFC 4084, May 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP", RFC 4380, February 2006. [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. Acknowledgments The authors would like to acknowledge Phil Roberts, Brian Carpenter, Pekka Savola, Spencer Dawkins, Jari Arkko and Carl Malamud for contributions to this document. IAB Informational [Page 13]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 2007 Appendix A - IAB Members at the time of this writing Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Elwyn B. Davies Consultant Soham, Cambs UK Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com IAB Informational [Page 14]
INTERNET-DRAFT Reflections on Internet Transparency 22 February 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). IAB Informational [Page 15]
