Network Working Group B. Aboba, Ed. INTERNET-DRAFT Elwyn Davies Category: Informational D. Thaler <draft-iab-link-encaps-00.txt> Internet Architecture Board 16 May 2006 Multiple Encapsulation Methods Considered Harmful 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 November 10, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describes architectural and operational issues that arise from link layer protocols supporting multiple Internet Protocol encapsulation methods. IAB Informational [Page 1]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 Table of Contents 1. Introduction .......................................... 3 1.1 Requirements ................................... 3 1.2 Terminology .................................... 3 2. Multiple Encapsulations ............................... 4 2.1 Mitigating Practices ........................... 7 3. Multiple Convergence Sublayers ........................ 8 3.1 Generality ..................................... 8 3.2 Layer Interdependence .......................... 9 3.3 Maintainability and Extensibility .............. 9 3.4 Interaction with Upper Layer Encryption ........ 9 3.5 Interoperability Guidance ...................... 9 3.6 Service Consistency ............................ 10 4. Security Considerations ............................... 11 5. Recommendations ....................................... 11 6. IANA Considerations ................................... 12 7. References ............................................ 12 7.1 Informative References .......................... 12 Acknowledgments .............................................. 14 Appendix A - IAB Members ..................................... 14 Intellectual Property Statement .............................. 14 Disclaimer of Validity ....................................... 15 Copyright Statement .......................................... 15 IAB Informational [Page 2]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 1. Introduction This document describes the architectural and operational issues arising from use of multiple ways of encapsulating IP packets on the same link. While typically a link layer protocol supports only a single Internet Protocol (IP) encapsulation method, this is not always the case. For example, on the same cable it is possible to encapsulate an IPv4 packet using Ethernet [DIX] encapsulation as defined in "A Standard for the Transmission of IP Datagrams over Ethernet Networks" [RFC0894] or IEEE 802 [IEEE-802-1A.190] encapsulation as defined in "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks" [RFC1042]. Historically, a further encapsulation method was used on some Ethernet systems as specified in "Trailer Encapsulations" [RFC0893]. Recently new link types have been defined that support multiple encapsulation methods. For example, IEEE 802.16 [IEEE-802.16] splits the Media Access Control (MAC) layer into a number of sublayers. For the uppermost of these, the standard defines the concept of a service-specific Convergence Sublayer (CS) that can be instantiated in multiple ways, each with its own data frame encapsulation. The two underlying sublayers (the MAC Common Part Sublayer and the Security Sublayer) provide common services for all instantiations of the CS. While [IEEE-802.16] defined support for the ATM CS and the Packet CS, [IEEE-802.16e] added support for eight new Convergence Sublayers. In each case there are multiple choices available for encapsulating IP packets. Issues resulting from support of multiple encapsulation methods are described in Section 2. Additional problems resulting from the use of multiple Convergence Sublayers are described in Section 3. Security issues are described in Section 4. Recommendations are provided in Section 5. 1.1. Requirements 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 [RFC2119]. 1.2. Terminology Broadcast domain The set of all endpoints that receive broadcast frames sent by any endpoint in the set. Link A communication facility or physical medium that can sustain data communications between multiple network nodes, such as an Ethernet IAB Informational [Page 3]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 (simple or bridged). Each link endpoint has a unique link-layer identifier. Link Layer Conceptual layer of control or processing logic that is responsible for maintaining control of the link. The link layer functions provide an interface between the higher-layer logic and the link. The link layer is the layer immediately below IP. 2. Multiple Encapsulation Methods The fundamental issues with multiple encapsulation methods on the same link are described in [RFC1042] and "Requirements for Internet Hosts -- Communication Layers" [RFC1122]. This section summarizes the concerns articulated in those documents and also describes the limitations of approaches suggested to mitigate the problems, including encapsulation negotiation and use of routers. [RFC1042] described the potential issues resulting from joint use of Ethernet and IEEE 802.3 encapsulation on the same physical cable: Interoperation with Ethernet It is possible to use the Ethernet link level protocol [DIX] on the same physical cable with the IEEE 802.3 link level protocol. A computer interfaced to a physical cable used in this way could potentially read both Ethernet and 802.3 packets from the network. If a computer does read both types of packets, it must keep track of which link protocol was used with each other computer on the network and use the proper link protocol when sending packets. One should note that in such an environment, link level broadcast packets will not reach all the computers attached to the network, but only those using the link level protocol used for the broadcast. Since it must be assumed that most computers will read and send using only one type of link protocol, it is recommended that if such an environment (a network with both link protocols) is necessary, an IP gateway be used as if there were two distinct networks. Note that the MTU for the Ethernet allows a 1500 octet IP datagram, with the MTU for the 802.3 network allows only a 1492 octet IP datagram. When multiple IP encapsulation methods are supported on a given link, all hosts typically cannot be assumed to support the same set of encapsulation methods. This in turn implies that the broadcast domain may not include all hosts on the link, necessitating the use IAB Informational [Page 4]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 of a bridge, switch, or router to enable the hosts supporting disparate encapsulation methods to communicate with each other. However, hosts supporting multiple encapsulation methods will still need to determine the encapsulation method used to reach a destination host. As noted in [RFC1122], Section 2.3.3: Furthermore, it is not useful or even possible for a dual-format host to discover automatically which format to send, because of the problem of link-layer broadcasts. To address these issues, "Requirements for Internet Hosts -- Communication Layers" [RFC1122] provided guidance in Section 2.3.3: Every Internet host connected to a 10Mbps Ethernet cable: o MUST be able to send and receive packets using RFC-894 encapsulation; o SHOULD be able to receive RFC-1042 packets, intermixed with RFC-894 packets; and o MAY be able to send packets using RFC-1042 encapsulation. An Internet host that implements sending both the RFC-894 and the RFC-1042 encapsulation MUST provide a configuration switch to select which is sent, and this switch MUST default to RFC- 894. By making Ethernet encapsulation mandatory to implement for both send and receive, [RFC1122] headed off potential interoperability problems. The issues with trailer encapsulation are described in [RFC1122] Section 2.3.1: DISCUSSION The trailer protocol is a link-layer encapsulation technique that rearranges the data contents of packets sent on the physical network. In some cases, trailers improve the throughput of higher layer protocols by reducing the amount of data copying within the operating system. Higher layer protocols are unaware of trailer use, but both the sending and receiving host MUST understand the protocol if it is used. Improper use of trailers can result in very confusing symptoms. Only packets with specific size attributes are encapsulated using trailers, and typically only a small fraction of the packets being exchanged have these attributes. Thus, if a IAB Informational [Page 5]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 system using trailers exchanges packets with a system that does not, some packets disappear into a black hole while others are delivered successfully. IMPLEMENTATION: On an Ethernet, packets encapsulated with trailers use a distinct Ethernet type [RFC893], and trailer negotiation is performed at the time that ARP is used to discover the link- layer address of a destination system. Specifically, the ARP exchange is completed in the usual manner using the normal IP protocol type, but a host that wants to speak trailers will send an additional "trailer ARP reply" packet, i.e., an ARP reply that specifies the trailer encapsulation protocol type but otherwise has the format of a normal ARP reply. If a host configured to use trailers receives a trailer ARP reply message from a remote machine, it can add that machine to the list of machines that understand trailers, e.g., by marking the corresponding entry in the ARP cache. Hosts wishing to receive trailers send trailer ARP replies whenever they complete exchanges of normal ARP messages for IP. Thus, a host that received an ARP request for its IP protocol address would send a trailer ARP reply in addition to the normal IP ARP reply; a host that sent the IP ARP request would send a trailer ARP reply when it received the corresponding IP ARP reply. In this way, either the requesting or responding host in an IP ARP exchange may request that it receive trailers. This scheme, using extra trailer ARP reply packets rather than sending an ARP request for the trailer protocol type, was designed to avoid a continuous exchange of ARP packets with a misbehaving host that, contrary to any specification or common sense, responded to an ARP reply for trailers with another ARP reply for IP. This problem is avoided by sending a trailer ARP reply in response to an IP ARP reply only when the IP ARP reply answers an outstanding request; this is true when the hardware address for the host is still unknown when the IP ARP reply is received. A trailer ARP reply may always be sent along with an IP ARP reply responding to an IP ARP request. "Requirements for Internet Hosts - Communication Layers" [RFC1122] Section 2.3.1 provided the following guidance for use of trailer encapsulation: IAB Informational [Page 6]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 The trailer protocol for link-layer encapsulation MAY be used, but only when it has been verified that both systems (host or gateway) involved in the link-layer communication implement trailers. If the system does not dynamically negotiate use of the trailer protocol on a per-destination basis, the default configuration MUST disable the protocol. Since trailer encapsulation negotiation depends on ARP, it can only be used where all hosts on the link are within the same broadcast domain. Therefore it implicitly assumes that all hosts on the link support standard Ethernet encapsulation [RFC0894]. It did not enable negotiation between Ethernet and IEEE 802 encapsulation, only between standard Ethernet [RFC0894] and trailer [RFC0893] encapsulation. 2.1. Mitigating Practices In order to mitigate problems arising from multiple encapsulation methods, it may be possible to use bridges, switches, or routers, or to attempt to negotiate the encapsulation method to be used. As described below, neither approach is completely satisfactory. The use of bridges, switches, or routers to enable communication between hosts utilizing multiple encapsulation methods is not a panacea. If separate prefixes are used for each encapsulation, then each encapsulation method can be treated as a separate interface with the choice of encapsulation determined from the routing table. However, if the same prefix is used for each encapsulation method, it is necessary to keep state for each destination host. In situations where multiple encapsulation methods are enabled on a single link, negotiation may be supported in order to allow hosts to determine how to encapsulate a packet for a particular destination host. Experience with trailer encapsulation suggests some of the issues that may be encountered in attempting to negotiate encapsulation above the link layer. Since the trailer negotiation mechanism resulted in multiple ARP replies, a similar mechanism could in theory be used to negotiate an encapsulation method by sending negotiation packets over all encapsulation methods supported. However, this results in higher bandwidth overhead, higher latency when establishing communication, and additional complexity in implementations. This issue can be avoided by performing encapsulation negotiation within the link layer. However, unless the link layer allows the negotiation of the encapsulation between any two hosts, then interoperability problems can still result if more than one IAB Informational [Page 7]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 encapsulation is possible on a given link. In general, a host cannot assume that all other hosts on a link support the same set of encapsulation methods, so that unless a link layer protocol only supports point-to-point communication, negotiation of multiple potential encapsulation methods will be problematic. To avoid this problem, it is desirable for link layer encapsulation negotiation to determine a single IP encapsulation, not merely to indicate which encapsulation methods are possible. Even if a single encapsulation is negotiated, problems can still occur if de-multiplexing of ARP, IPv4, IPv6, and any other protocols in use, is not supported at the link layer. While is possible to demultiplex such packets based on the Version field (first four bits on the packet), this assumes that IPv4-only implementations will be able to properly handle IPv6 packets. As a result, a more robust design is to demultiplex protocols in the link layer, such as by assigning a different protocol type, as is done in IEEE 802 media where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6. 3. Multiple Convergence Sublayers In addition to the problems encountered with multiple encapsulation methods, the use of multiple Convergence Sublayers as practiced in [IEEE-802.16] brings with it an additional set of issues. 3.1. Generality Link layer protocols such as [IEEE.802-1A.1990] and [DIX] inherently support the ability to add support for a new packet type without modification to the link layer protocol. As noted in [Generic], the definition of multiple Convergence Sublayers within 802.16 appears to imply that the standard will need to be modified to support new packet types: We are concerned that the 802.16 protocol cannot easily be extendable to transport new protocols over the 802.16 air interface. It would appear that a Convergence Sublayer is needed for every type of protocol transported over the 802.16 MAC. Every time a new protocol type needs to be transported over the 802.16 air interface, the 802.16 standard needs to be modified to define a new CS type. We need to have a generic Packet Convergence Sublayer that can support multi-protocols and which does not require further modification to the 802.16 standard to support new protocols. We believe that this was the original intention of the Packet CS. Furthermore, we believe it is difficult for the industry to agree on a set of CS's that all devices must implement to claim "compliance". IAB Informational [Page 8]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 The use of IP and/or upper layer protocol specific encapsulation methods, rather than a 'neutral' general purpose encapsulation may give rise to a number of undesirable effects explored in the following subsections. 3.2. Layer Interdependence Standardizing IP and/or upper layer specific encapsulation methods in the link layer will almost inevitably lead to interdependencies between the two specifications. Although this might appear to be desirable in terms of providing a highly specific (and hence interoperable) mapping between the capabilities provided by the link layer (e.g., quality of service support) and those that are needed by the upper layer, this sort of capability is probably better provided by a more comprehensive service interface (Application Programming Interface) in conjunction with a single non-specific encapsulation. 3.3. Maintainability and Extensibility If the link layer does not provide a general purpose encapsulation method, deployment of new IP and/or upper layer protocols will be dependent on deployment of the corresponding new encapsulation support in the link layer. IPv6, in particular, provides an extensible header system. An upper layer specific encapsulation method would still have to provide a degree of generality in order to cope with future extensions of IPv6 that might wish to make use of some of the link layer services already provided. 3.4. Interaction with Upper Layer Encryption If an IP or upper layer specific encapsulation method proposes to inspect the contents of the packet being encapsulated (e.g., 802.16 IP CS mechanisms for determining the connection identifier (CID) to use to transmit a packet), the fields available for inspection may be limited if the packet is encrypted before passing to the link layer. 3.5. Interoperability Guidance [IEEE-802.16e] has defined multiple Convergence Sublayers capable of carrying IP traffic. In addition to the Ethernet CS, IPv4 CS and IPv6 CS, ten other Convergence Sublayers are defined. Within [IEEE-802.16e], the Ethernet CS and IPv4 CS are mandatory-to- implement. In situations where multiple CS's are operational and capable of carrying IP traffic, interoperability problems are possible in the absence of clear implementation guidelines. Some of the issues that may arise include: IAB Informational [Page 9]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 ARP Where multiple CS's are operational, it may not be obvious how ARP should be implemented. For example, should an ARP frame be encapsulated over the Ethernet CS, or should alternative mechanisms be used for address resolution, utilizing the IPv4 CS? Data Frame Encapsulation When sending an IP packet, which CS should be used? Where multiple CS's are operational, the issue can be treated as a multi-homing problem, with each CS constituting its own interface. Since a given CS may have associated bandwidth or quality of service constraints, routing metrics could be adjusted to take this into account, allowing the routing layer to choose based on which CS appears more attractive. However there is no guarantee that other hosts on the link will support the same set of CS's, or that if they do, that their routing tables will result in identical preferences. This could lead to interoperability problems or routing asymmetry. For example, consider the effects on Neighbor Discovery: [a] If hosts choose to send Neighbor Discovery traffic on different CS's, it is possible that a host sending a Neighbor Discovery packet will not receive a reply, even though the target host is reachable over another CS. [b] Where hosts all support the same set of CS's, but have different routing preferences, it is possible for a host to send a Neighbor Discovery packet over one CS and receive a reply over another CS. Given these issues, it is strongly recommended that only a single encapsulation be usable in a given circumstance. 3.6. Service Consistency If a link layer protocol provides multiple encapsulation methods, the services offered to the IP and upper layer protocols may differ qualitatively between the different encapsulation methods. For example, the 802.16 [IEEE-802.16] link layer protocol offers both 'native' encapsulation for IPv4 and IPv6 packets, and emulated Ethernet encapsulation. In the native case, the IP layer has direct access to the quality of service (QoS) capabilities of the 802.16 transmission channels, whereas using the Ethernet encapsulation the IP QoS has first to be mapped through the rather more limited capabilities of Ethernet QoS. Consequently, the service offered to an application depends on the encapsulation method employed and may be inconsistent between sessions. This may be confusing for the user and the application. IAB Informational [Page 10]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 4. Security Considerations The use of multiple encapsulation methods does not appear to have significant security implications. An attacker might be able to utilize an encapsulation method which was not in normal use on a link to cause a Denial of Service attack which would exhaust the processing resources of interfaces if packets utilizing this encapsulation were passed up the stack to any significant degree before being discarded. However, the use of encapsulation methods that need to inspect fields in the packet being encapsulated in order to provide service classification might deter the deployment of end-to-end security; this is undesirable. Similarly, if one method is rarely used, that method is potentially more likely to have exploitable implementation bugs. An attacker might be able to force a more cumbersome encapsulation method between two endpoints, even when a lighter weight one is available, hence forcing higher resource consumption on the link and within those endpoints. If different methods have different security properties, an attacker might be able to force a less secure method as an elevation path to get access to some other resource or data. 5. Recommendations The use of multiple encapsulation methods on the same link is problematic, as discussed above. Support of multiple encapsulation methods requires additional implementation complexity which may not be practical for devices with limited resources, and the lack of uniform encapsulation support results in potential interoperability problems. One argument given for support of multiple encapsulation methods on the same link is that one encapsulation may not fit all usage scenarios. For example, it has been argued that IEEE 802 or Ethernet encapsulation of IP result in excessive overhead due to the size of the data frame headers, and that this can adversely affect performance on wireless networks, particularly in situations where support of Voice over IP (VOIP) is required. However, even where these performance concerns are valid, solutions exist that do not require defining multiple IP encapsulation methods. For example, links may support Ethernet frame compression so that Ethernet Source and Destination Address fields are not sent with every packet. IAB Informational [Page 11]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 On balance, we do not believe that the benefits of multiple IP encapsulation methods outweigh the disadvantages. This is a judgment supported by past history as well as by reasoned analysis. Although multiple IP encapsulation methods were defined on Ethernet cabling, recent implementations support only the Ethernet encapsulation of IPv4 defined in [RFC0894]. In order to avoid a repeat of the experience with IPv4, for operation of IPv6 on IEEE 802.3 media, only the Ethernet encapsulation was defined in "A Method for the Transmission of IPv6 Packets over Ethernet Networks" [RFC1972]. To avoid problems resulting from use of multiple IP encapsulation methods: When developing standards for encapsulating IP packets on a link layer technology, it is desirable that only a single encapsulation method should be standardized for each link layer technology; If a link layer protocol offers multiple encapsulation methods for IP packets, it is strongly recommended that only one of these encapsulation methods should be in use on any given link or within a single wireless transmission domain; Encapsulation mechanisms should be neutral with respect to the contents of the packet being encapsulated; Where multiple encapsulation methods are supported on a link, a single encapsulation should be mandatory to implement for send and receive; If multiple encapsulation methods for IP packets on a single link layer technology are deemed to be necessary, care should be taken to match the services available between encapsulation methods as closely as possible; Link layer protocols should enable network packets (IPv4, IPv6, ARP, etc.) to be de-multiplexed in the link layer. 6. IANA Considerations This document has no actions for IANA. 7. References 7.1. Informative References [DIX] Digital Equipment Corporation, Intel Corporation, and Xerox Corporation, "The Ethernet -- A Local Area Network: Data Link Layer IAB Informational [Page 12]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 and Physical Layer (Version 2.0)", November 1982. [Generic] Wang, L. et al, "A Generic Packet Convergence Sublayer (GPCS) for Supporting Multiple Protocols over 802.16 Air Interface", Submission to IEEE 802.16g: CB0216g_05_025r4.pdf, November 2005, <http:// www.ieee802.org/16/netman/contrib/C80216g-05_025r4.pdf>. [IEEE-802.16] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", IEEE Standard 802.16-2004, October 2004. [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE P802.16e, September 2005. [IEEE.802-1A.1990] Institute of Electrical and Electronics Engineers, "Local Area Networks and Metropolitan Area Networks: Overview and Architecture of Network Standards", IEEE Standard 802.1A, 1990. [IEEE.802-1D.1998] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges", IEEE Standard 802.1D, 1998. [IEEE.802-3.1985] Institute of Electrical and Electronics Engineers, "Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Standard 802.3, 1985. [RFC0893] Leffler, S. and M. Karels, "Trailer encapsulations", RFC 893, April 1984. [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984. IAB Informational [Page 13]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988. [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Acknowledgments The authors would like to acknowledge Jeff Mandin, Bob Hinden and Jari Arkko for contributions to this document. 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 Intellectual Property Statement 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 IAB Informational [Page 14]
INTERNET-DRAFT Multiple Encapsulation Methods Harmful 16 May 2006 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. IAB Informational [Page 15]
