Internet Engineering Task Force J. Bound Internet-Draft NAv6TF Expires: October 8, 2005 S. Chakravorty K. Zhang The MITRE Corporation April 9, 2005 Proposal for a New Flow Label Definition draft-chakravorty-bcc-flowlabel-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 October 8, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The IPv6 header includes a 20-bit Flow Label field. RFC 3697, "IPv6 Flow Label Specification" [1] specified this field and minimum requirements for using the field. This document first identifies several issues related to the current Flow Label specification; then it discusses the limitations of the current specification and the Bound, et al. Expires October 8, 2005 [Page 1] Internet-Draft Proposal for a New Flow Label Definition April 2005 need for extending the definition to accommodate emerging applications and protocols; finally, a new Flow Label specification is proposed that enables more effective usage of this field. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Issues Concerning the Current Flow Label . . . . . . . . . . . 5 4. New Flow Label Specification . . . . . . . . . . . . . . . . . 7 4.1 Implications . . . . . . . . . . . . . . . . . . . . . . . 9 5. An Emerging Usage for the Flow Label Field . . . . . . . . . . 9 6. Benefits of Flexible Label . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Bound, et al. Expires October 8, 2005 [Page 2] Internet-Draft Proposal for a New Flow Label Definition April 2005 1. Introduction The IPv6 header includes a 20-bit Flow Label field. RFC 3697 [1] specified this field and the minimum requirements required for using it. This document identifies several issues related to the current Flow Label specification, it also discusses the limitations of the current specification and the need for expanding the definition to accommodate emerging applications and protocols. Additionally, a new Flow Label definition is proposed that enables more effective use of this field. A Flow Label is defined in [1] to be æa sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow.Æ It may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers. Such handling could comprise non-default quality of service or æreal-timeÆ service. How to identify a flow and assign labels to flows are specified in RFC 3697[1] as follows: - A flow is uniquely identified by the 3-tuple of source address, destination address and a non-zero Flow Label. - All packets belonging to the same flow must be sent with the same source address, destination address, and Flow Label. - Packets that do not belong to a flow carry a Flow Label of zero. - New Flow Labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. - The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). - Nodes keeping dynamic flow state MUST NOT assume packets arriving 120 seconds or more after the previous packet of a flow still belong to the same flow, unless a flow state establishment method supports it. - Source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. It MUST ensure that it does not unintentionally reuse Flow Label values it is currently using or has recently used when creating new flows. - To use Flow Labels for classifying and providing special treatment of traffic, æflow stateÆ needs to be established on all or a subset of IPv6 nodes on the path from the source to the destination(s). The Bound, et al. Expires October 8, 2005 [Page 3] Internet-Draft Proposal for a New Flow Label Definition April 2005 æflow stateÆ should include sufficient information so that pertinent IPv6 nodes can support required flow-based processing. In this document, we propose a modified version of the above specification for the IPv6 Flow Label to add flexibility and ease of use of the Flow Label especially for Quality of Service (QoS) delivery. This specification allows flows to be defined by only the Flow Label once the uniqueness of the Flow Label has been ascertained for a given flow between two or more peering routers. Such assertion can be made by the Flow Label associated with the source and destination addresses, incoming port or some such other methodologies as described in [2]. The Flow Label need not be static or a fixed value between the source and destination, that is, it can be changed enroute provided the original Flow Label is delivered in the packet at the destination. Classifying one or more packets in a flow into a class of packets, called the Forwarding Equivalent Class (FEC) [2], of given characteristics of QoS, security or some other parameter or a combination of parameters, is allowed. The flow state can be established at the start of a flow represented by the Flow Label and one that can relate to an FEC; the corresponding service can then be delivered as expected from the flow. Once a flow state has been established and the packet is bound to an FEC, packet forwarding can then be based on only the Flow Label, see [2]. This specification of Flow Label thus allows changing the label while the packet is enroute from the source to the destination as long as the original label is restored prior to arrival of the packet at the destination. The Flow Label thus enables processing of flows based on Flow Label only once the flow has been uniquely identified by a label and also enables the nodal capability for using label for packet classification as well as packet forwarding. 2. Background During the past decade, Internet QoS framework has been built around the network traffic class based service differentiation and traffic engineering. DiffServ has emerged as a prevalent Internet QoS framework that focuses on providing performance differentiation to different traffic classes. With the æTraffic ClassÆ field in the IPv6 header that maps to IPv4 DiffServ Code Points (DSCPs), IPv6 can readily support the QoS framework with the help of the specification of label provided here. This supports class/priority based traffic treatment. IPv6 protocol thus provides support for both class based Bound, et al. Expires October 8, 2005 [Page 4] Internet-Draft Proposal for a New Flow Label Definition April 2005 or flow based packet classifications as well as specific packet forwarding treatment related to such classifications. As of today, the deployment of per-flow based packet forwarding treatment is rather limited in an IPv6 network. The 20-bit Flow Label field (whether set by the end applications or not) is ignored by most network devices. This presents a significant waste of built-in IPv6 capabilities; the label field could have been effectively used toward enhancing the overall IPv6 protocol functionality if certain measure of flexibility were allowed in its definition and usage. The primary application of IPv6 Flow Label was to facilitate per flow resource allocation and/or packet treatment, so that desirable QoS can be delivered. An IPv6 flow is currently defined on an end-to-end basis between the source and destination. It was designed based on an end-to-end fixed label assignment that would signal special traffic treatment by network devices at the flow level granularity. Thus, using Flow Labels, traffic could be classified into per application flows, possibly even to a finer level, e.g., based on transactions for an application. The Flow Label field was allowed for mapping to known flows such as TCP connections, application streams, etc., but no service models or mechanisms were provided [1]. The IPv6 Flow Label field remained unused and ignored by all for nearly a decade although use of a similar 20-bit label field in Multiprotocol Label Switching (MPLS) protocol for similar purposes received wide implementation support during the same period. 3. Issues Concerning the Current Flow Label With the current Flow Label definition [1], providing for per-flow QoS may be a difficult process. We highlight several issues concerning per-flow QoS support using the Flow Label field. - The static allocation of Flow Labels defining fixed, end-to-end flows in large networks is unwieldy at best. If the specification had allowed for dynamic allocation of Flow Labels as flows were set up and torn down (or progressed over multiple hops), the network administrators and/or users would have had the latitude to use one or more labels (in the same flows) - as and when necessary and for different purposes. The static characteristic of the Flow Label allocation end-to-end and its 3-tuple association with source and destination addresses (which are also static end-to-end) renders the view that the Flow Label is there to extend the address space into the Flow Label field. Conversely, one could use the source and Bound, et al. Expires October 8, 2005 [Page 5] Internet-Draft Proposal for a New Flow Label Definition April 2005 destination addresses in conjunction with the Traffic Class field to provide the same services without using the Flow Label at all. There is no need for a separate static 20-bit field, that has to be used end-to-end, on top of the 256 bits of address space to identify a flow. - Specific flow state establishment methods and the related service models are out of scope in the current label specification [1]. Devoid of a methodology for establishing a flow or for provisioning services using established flows meant the Flow Label specification is incomplete and possibly inadequate toward providing implementation and deployment direction for efficient use of the label. - As the Flow Label field carries a static, fixed label generated by a source host, for a flow to receive requested treatment in the network, a signaling protocol such as the Label Distribution Protocol (LDP) (used in MPLS) or Resource Reservation Protocol (RSVP) must be used to distribute the label binding (packet classification) information (for this source-based packet classification) to all other nodes in the network. The current Flow Label specification [1] does not provide any mechanism for propagating label binding information into the network which makes the current Flow Label specification difficult to implement. - To ensure that flows can be identified uniquely in the network, the 3-tuple of Flow Label, Source and Destination addresses is used to define a flow. Given the large address field used by the IPv6 protocol, the memory requirements for maintaining a flow state that includes two 128-bit addresses and a 20-bit Flow Label (for a total of 276 bits) can be significant when tens of thousands of flows are in operation in a network node. Moreover, the operations used for flow look-ups may also be processing intensive involving multiple memory fetches per flow in 32-bit or 64-bit machines. This is not desirable for small or portable devices with limited memory and processing power. - In IPv6 packets that must traverse errorùprone or unreliable links, errors may inadvertently change the Flow Label bits. As the static Flow Label is to be used end-to-end, the errors may result in flows that can not be matched to any flow (packet) treatment profile. The current specification of Flow Label does not address how errored packets need to be handled or if they can be processed at all in the error-prone links. Furthermore, errored packets in TCP streams will fail checksums at the destination host resulting in unnecessary retransmissions and possible congestion. (On the other hand, flexible Flow Label as proposed in this document only has local significance and as such has limited vulnerability.) Bound, et al. Expires October 8, 2005 [Page 6] Internet-Draft Proposal for a New Flow Label Definition April 2005 - The fixed label MUST be delivered unchanged to the destination nodes; this even applies to the zero Flow Label which is used for labeling packets that are not part of any flow (for nodes that do not support Flow Label based flows). It is not clear how this requirement contributes any useful functionality. This constitutes an ideal mechanism for man-in-the-middle attacks. What is needed to derail an end-to-end statically defined flow is to simply insert all zeroes in the Flow Label field thus making the flow a 'non-flow'. The flow meant for QoS delivery becomes meaningless and could potentially be harmful to a mission. - Scalability is another issue with the static, fixed Flow Label assignment. Static assignments are not considered by their very nature scalable. For instance, the projected depletion of the fixed address space in IPv4 has resulted in the adoption of IPv6 (for its huge address space). Flexibility in the assignment of values to a bit field as and when needed is considered in general a good idea. This is true for the Flow Label as well. To summarize, the current IPv6 Flow Label is little used; its current specification is confusing. Absent an associated mechanism for label binding distribution, the specification provides little in way of functionalities for the IPv6 protocol. Its application in providing flow based QoS has not been defined, its implementation by network devices may prove to be expensive and may introduce issues concerning proper use of the available resources. Its use in the error-prone media is questionable. It is vulnerable to the man-in-the-middle attacks. Finally, the current specification is too restrictive to allow its wide-spread use; the static allocation of the Flow Label raises questions regarding its scalability. It is safe to assume that emerging applications will find it difficult to take advantage of the current Flow Label specification. 4. New Flow Label Specification This document proposes limited modification to the current specification of the Flow Label. In this new specification, the 20-bit Flow Label in the IPv6 header is used by a host or network node to label one or more packets of a flow. In this configuration the label still comprises 20-bits - same as in the original specification [1], however, an all-zero label can be used for identifying a specific flow such as for the least significant, default class of service in the differentiated service architecture. Bound, et al. Expires October 8, 2005 [Page 7] Internet-Draft Proposal for a New Flow Label Definition April 2005 Packet classification uses only the Flow Label to identify which flow a particular packet belongs to. The use of other information in the packet header or network node can also be used when necessary to identify a flow for rendering label binding significance to a flow. For example, the source and/or destination addresses in the former case and physical port address in the latter would be examples of such information. The Flow Label has local significance - the scope of this could be limited to a single hop or extended to a whole network domain. A flow using a unique label can be initiated at a host or any node in a network. Similarly, a flow can be terminated at the adjacent downstream node in case of a single-hop flow or can continue for several hops depending on the extent of use of the original label binding. Packets in a flow are processed in a flow-specific manner by the nodes that have been set up with flow-specific state. The Flow Label set by the flow source node MUST be delivered unchanged to the flow destination node(s). The source node can be a host or a node that generates a flow; this node can be different from the source host (as identified by the source address in the packet header) and the destination node can be a host or node that terminates a flow and can be different from the destination host (as identified by the destination address in the packet header). This specification follows the original specification [1] in that nodes keeping dynamic flow state MUST NOT assume packets arriving 120 seconds or more after the previous packet of a flow still belong to the same flow, unless a flow state establishment method in use defines a longer flow state lifetime or the flow state has been explicitly refreshed within the lifetime duration. The use of the Flow Label field does not necessarily signal any requirement on packet reordering. If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet. To extend the capabilities of the Flow Label, it is proposed that one bit, the most significant bit (MSB) bit, be specified as follows. In the following figure, the MSB bit consists of a Label Type (L) subfield. The following values are defined for this subfield for a node receiving a packet from an upstream node or host: Bound, et al. Expires October 8, 2005 [Page 8] Internet-Draft Proposal for a New Flow Label Definition April 2005 - 0 hex: this packet is the first packet of a new flow - 1 hex: this packet is not the first packet of a new flow +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flow Label with subfield (L) The binary value of the MSB will make flow merging easier in 6LSA network [2]. To support 6LSA framework (described below in Section 5) and for greater scalability of usage, the current fixed Flow Label specification is extended to allow flexibility in labeling packets. Labels are not static end-to-end as such the specification accommodates label swapping in the network nodes. Such a non-static label is hereafter called ôflexible labelö or flexible label assignment. In the flexible label assignment, labels can be swapped in the network nodes of a given network in a 6LSA domain so long as the original label is reinserted before the flow arrives at the destination. 4.1 Implications The proposed modification of the Flow Label field in the IPv6 datagram header has no impacts on hosts and routers that do not currently support IPv6 Flow Label processing. For other systems, this modification requires to reduce the label size from 20 bits to 19 bits. This reduces the number of flows from about a million to about half of that. However, one-half million flows should be adequate for per-hop QoS delivery in any size network. 5. An Emerging Usage for the Flow Label Field An architectural framework, called IPv6 Label Switching Architecture (6LSA) has been proposed [2] to demonstrate how the specification presented in this document can be used. The architecture allows network nodes to generate labels locally. The label is then used to specify flows, bind them to FECs and forward packets at high speed over the label-derived LSPs. The architecture includes swapping of labels in a network node, that Bound, et al. Expires October 8, 2005 [Page 9] Internet-Draft Proposal for a New Flow Label Definition April 2005 is, the outgoing label replaces the incoming label as the packet traverses a node. The outgoing label represents the LSP from this node to the downstream node. The original label is reinstated in the packet in the 6LSA egress router. This architecture is meant to provide means for traffic engineering for QoS delivery. In this model, Flow Label can be changed in a packet stream. A flow, called pseudo-flow (to avoid conflict with the current definition [1]), gets identified with a Flow Label as it is created for each hop, that is, flows have hop-by-hop significance for a given session and required QoS. To support IPv6 based label switching, that is, swapping of incoming label with the outgoing label (the latter mapped to a given FEC) in the network node is allowed. The label switching is used to set up label switched paths (LSPs) similar to the MPLS LSPs over which packets are forwarded after they are bound to a Forwarding Equivalent Class (FEC). By using the IPv6 Flow Label value for packet forwarding (and classification as necessary if not provided by the Traffic Class), this architecture avoids the link overhead associated with label distribution that is needed to tie the IPv6 address to a Flow Label. This layer 3 use of Flow Label for packet forwarding also allows router peering in layer 3 unlike other contemporary virtual circuit protocols. The 6LSA framework [2] is a good example that highlights the needs to broaden the current definition of the IPv6 Flow Label field. It is possible that more applications like 6LSA will emerge that can take advantage of the field. 6. Benefits of Flexible Label The flexible label has many benefits, an abridged version is provided here. The 6LSA example [2] shows how these benefits can be realized. - Supporting a per-hop label assignment mechanism enables high-speed packet processing through short 20-bit label switching instead of extremely large 3-tuple, 276-bit flow (identifier) or 128-bit address look-ups. This could signficantly reduce delays for all delay-sensitive real-time and near-real-time traffic thereby considerably enhancing QoS delivery. - In mobile ad-hoc networks, such as in the military networks, the use of label for packet forwarding provides for fast and flexible networking for mobile nodes. Once a flow has been set up through any one of several selected methods such as through association of the Bound, et al. Expires October 8, 2005 [Page 10] Internet-Draft Proposal for a New Flow Label Definition April 2005 Flow Label in the first (lead) packet with IPv6 addresses or physical port or through some other means, all susequent packets in the flow can be forwarded using the Flow Label. This helps packet forwarding based soley on the Flow Label and in small, bandwidth constrained networks this could help eliminate the transmission of the packet header with each packet beyond the ingress node for packets that are next-to-lead packets [2]. (This concept is in its early stage of evaluation at this time.) The process if adopted will save bandwidth considerably in ad-hoc, mobile links in addition to providing considerable savings in memory (enormously reduced bit space), bandwidth (significantly reduced packet header overhead) and processing (fewer fetches and smaller bit field). - Labels demarcate per hop label switched paths. Per-hop label assignment is more robust than end-to-end because the Flow Labels are assigned hop-by-hop which helps prevent errors from propagating along the communications path. - Per hop label assignment allows for using datagram transmission where QoS requirements can be relaxed or cannot be enforced for various reasons. This adds another dimension to the use of flexible label. The packets can still carry the labels but processsing of packets will not be label based but on conventional routing algorithms. This could be employed on one or more hops by apriori design, signaling or ad-hoc configuration control using network managment tools. - The flexible label allows ready integration of flows with a local QoS mechanism as available in a node that can make use of the label - a node is not dependent on a centrally administered label binding or packet classification mechanism - this is good for scalability. Typically, inelastic or preferred elastic class of service rwquires individual flows to receive preferred treatment. One wat to achieve this preferred treat ment could through individual Traffic Class markings and flow-label based forwarding treament of such marked packets through managed contrl of available resources. - Allowing local label generation helps eliminate signaling for distributing labels and save network resources. - Flexible labeling is efficient because it eliminates lower layer peering and allows peering between network nodes in layer 3. Flow Label control plane mechanisms can be tied to one or more layer 3 control plane mechanisms such as an IGP, RSVP, etc., - the latter helps avoid N2 (n-squared) problems of below-layer 3 virtual circuits. Bound, et al. Expires October 8, 2005 [Page 11] Internet-Draft Proposal for a New Flow Label Definition April 2005 - In mobile ad-hoc networks where links go up and down randomly and frequently, the end-to-end model of flow establishment and maintenance is not practical or advisable. The flexible flow labeling that allows per flow set ups and tear downs, or opting out of flows where flows are not needed is more desirable . - The Flow Label as specified here can potentially be used for VPNs (this is to be addressed in future work). To summarize, the flexible label as presented in this new Flow Label specification allows flow labeling dynamically on an as-and-where needed basis. It is not done statically and on an end-to-end basis as the current specification does. Flows so definied are not tied to the flow's source-destination nodal pair but can be specified for any pair of nodes - nodes connecting by as hort a link as one hop. The label binding can be totally independent from one hop to another. Packets can be forwarded using only the label in a flow once the flow has been set up using this label. There is no restriction as to how a label is bound to an FEC. It is significant that a flow label is not only used for packet classification but also for packet forwarding. Packet forwarding using only the label thus can provide significant savings in memory, processing and potentially, bandwidth usage - all of which are very important for mobile networks in which the nodes are limited by size, weight and power factors and links by available bandwidth. The difference between packet forwarding by flow label and packet forwarding by destination address is that the latter has little or no mapping to QoS delivery or secured path based delivery, is generally shortest path based, generally requires route look up (often in the back plane), is not fast and is not session specific. The new definition presented here extends the original Flow Label definition to other purposes such as VPNs (the specification is work in progress) enhancing both the efficiency and functionality of the IPv6 protocol. 7. Security Considerations Since this is related to 6LSA, the considerations here are identical to those for 6LSA [2]. The flexible Flow Label allows security association. If the security association (SA) partners are outside the 6SLA, then there is no effect of this specification on 6LSA whether the mode of operation is in the transport mode or in the tunnel mode. In the transport mode of SA, only the packet payload is subject to encryption or authentication, so the IPv6 packet header features are Bound, et al. Expires October 8, 2005 [Page 12] Internet-Draft Proposal for a New Flow Label Definition April 2005 not affected and the 6LSA being a transport mechanism that sets up 6LSPs and provides specific FEC-driven forwarding treatment, there is no impact on the 6LSA or impact on SA operation by the 6SLA or this specification of the label. In the tunnel mode of SA, the SA requires an outer wrapper IPv6 packet. The sending gateway wraps the whole IPv6 packet including the content. The receiving gateway performs the checksum on the outer wrapper packet, unwraps the packet and then verifies the checksum of the inner packet through end-to-end SA. If the outer wrapper packet conveys the Flow Label value of the inner packet, then here also, there is no impact on the 6LSA based transport of the secure packets or vice versa. The Authentication Header (AH) is used in IPv6 for authentication of individual packets to prevent common Internet-based attacks such as IP address spoofing and session hijacking. The computation of cryptographically secure checksum over the payload as well as some fields of the IPv6 and extension headers has to take place between the SA partners. This computation does not include the Flow Label field in the packet header. This maintains label transparency in the 6SLA. Authentication can be either in the transport mode or in the tunnel mode. The 6SLA security considerations that apply to Encrypted Security Payload (ESP) header comprise encryption modes that are categorized as transport mode or tunnel mode. In the transport mode, no encryption of the Flow Label field is performed, so the value is carried through the 6SLA. In the tunnel mode, the issues are the same as stated here above. In both cases, the characteristics of the flexible label is identical to fixed label, 8. Acknowlegements The authors deeply appreciate general advice and encouragement received from inside and outside of Mitre. 9. Disclaimer The affiliation of the authors with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITREÆs concurrence with, or support for, the positions, opinions or viewpoints expressed by the author. 10. References Bound, et al. Expires October 8, 2005 [Page 13] Internet-Draft Proposal for a New Flow Label Definition April 2005 [1] J. Rajahalme, et al., IPv6 Flow Label Specification, RFC 3697, March 2004. [2] S. Chakravorty, IPv6 Label Switching Architecture (6LSA), IETF ID ædraft-chakravorty-6lsa-01.txtÆ, July 2004. [3] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998. Authors' Addresses Jim bound NAv6TF P.O. Box Hollis, NH 22102 USA EMail: Jim.bound@hp.com Sham Chakravorty The MITRE Corporation 1575 Colshire Dr. McLean, VA 22102 USA EMail: schakra@mitre.org Kevin Zhang The MITRE Corporation 7515 Colshire Dr. McLean, VA 22102 USA EMail: kzhang@mitre.org Bound, et al. Expires October 8, 2005 [Page 14] Internet-Draft Proposal for a New Flow Label Definition April 2005 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 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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bound, et al. Expires October 8, 2005 [Page 15]