Internet Engineering Task Force J. Bound Internet-Draft NAv6TF Expires: October 8, 2005 S. Chakravorty D. Chirieleison The MITRE Corporation April 9, 2005 Binding Packets to FECs in 6LSA draft-chakravorty-bcc-fec-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 IETF Internet Draft "IPv6 Label Switching Architecture (6LSA)" [6LSA] [2] proposes using the IPv6 Flow Label field to switch packets through an IPv6 subnetwork. The use of these IPv6 Label Switched Paths (6LSPs) can provide means for traffic engineering and potentially increase the speed of packets traversing a routed network Bound, et al. Expires October 8, 2005 [Page 1] Internet-Draft Binding Packets to FECs in 6LSA April 2005 with no increase in bandwidth. The 6LSA draft defines two processes: 1) grouping packets with identical forwarding behavior into a Forwarding Equivalence Class (FEC), 2) forwarding all packets belonging to an FEC along the same path. The assignment of packets to an FEC is called binding. The purpose of this document is to expand on these two processes, discussing specific methods of performing the required functions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. FEC Construction . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Manual Configuration . . . . . . . . . . . . . . . . . . . 7 4.2 Network Management . . . . . . . . . . . . . . . . . . . . 7 4.3 Pseudoflow . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 Label Distribution Protocol . . . . . . . . . . . . . . . 9 5. Binding IPv6 Packets to an FEC . . . . . . . . . . . . . . . . 9 5.1 Manual Configuration . . . . . . . . . . . . . . . . . . . 10 5.2 Algorithmic Binding . . . . . . . . . . . . . . . . . . . 11 5.3 FEC Binding using SNMP . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.1 Use of SNMP . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Use of Label Distribution Protocols . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Bound, et al. Expires October 8, 2005 [Page 2] Internet-Draft Binding Packets to FECs in 6LSA April 2005 1. Introduction The IETF Internet Draft "IPv6 Label Switching Architecture (6LSA)" [6LSA] [2] proposes using the IPv6 Flow Label field to switch packets through an IPv6 subnetwork. The use of these IPv6 Label Switched Paths (6LSPs) can provide means for traffic engineering and potentially increase the speed of packets traversing a routed network with no increase in needed bandwidth. Label switching in 6LSA, as in MPLS, enables setting up of labeled paths that can represent different service classes and ensure that traffic of different such classes flows over these paths. Label switching may have speed advantages over traditional routing. This advantage will likely be greater in IPv6 since its address fields are 128 bits long. Next-hop determination using the 20 bit label proposed in 6LSA should be considerably more efficient than a 128 bit routing table lookup. The basic 6LSA draft defines two processes: 1) grouping packets with identical forwarding behavior into a Forwarding Equivalence Class (FEC), 2) forwarding all packets belonging to an FEC along the same path. The assignment of packets to an FEC is called binding. The purpose of this document is to expand on these two processes, discussing specific methods of performing the required functions. Terminology as introduced in the 6LSA draft is reviewed in Section 2 below. Section 3 presents some background information on the 6LSA design. Section 4 discusses ways to construct FECs. Section 5 describes how packets might be bound to a certain FEC. Section 6 covers security considerations. 2. Terminology It is intended that this document use the same terminology as the 6LSA draft [2]. This section repeats the relevant definitions from that document. 6LSA domain a contiguous set of nodes that perform 6LSA routing and forwarding operations and are in one routing or admin domain 6LSA egress node a 6LSA edge node in its role of handling traffic as the traffic leaves 6LSA domain 6LSA ingress node a 6LSA edge node in its role of handling traffic as the traffic enters a 6LSA domain Bound, et al. Expires October 8, 2005 [Page 3] Internet-Draft Binding Packets to FECs in 6LSA April 2005 6LSP a label switched path through a pair or more 6LSRs 6LSR IPv6 label switching router that is capable of forwarding IPv6 packets based on certain FEC attributes label the IPv6 Flow Label which is carried in the IPv6 packet header and may represent the packet's FEC Flow Label the 20-bit label in the IPv6 header used for identifying flows label switching a fast forwarding operation allowing streamlined forwarding of packets by using labels to identify classes of data packets which are treated indistinguishably when forwarding label switched hop the hop between two 6LSA nodes, on which forwarding is done using labels label switched path a virtual path through which all packets in a flow are routed across a routing or administrative domain 3. Background Packets receiving identical forwarding treatment are said to belong to the same FEC. For example, within a given router, packets that are sent to the same next-hop over the same link with the same quality-of-service (QoS) would belong to the same FEC because the router treats each packet in exactly the same manner. An FEC could be identified by a tag or label. Thus if an incoming packet is labeled as belonging to a certain FEC, a forwarding decision can be made without reference to the packet's destination or to the routing table. In MPLS, a shim header is needed for the network layer header to carry this label. A shim header is not required in 6LSA; the Flow Label is the label. Each router must inform its (upstream) neighbor of the label value to use to represent each FEC. In MPLS, The label-to-FEC mapping is passed by means of a label distribution protocol such as LDP [RFC 3036] or RSVP-TE[RFC 3209]. Once label-to-FEC mappings have been established for each hop along a given path, unlabeled packets arriving at the first-hop (ingress) 6LSR are classified or bound to an FEC. This classification can be Bound, et al. Expires October 8, 2005 [Page 4] Internet-Draft Binding Packets to FECs in 6LSA April 2005 based on a variety of characteristics including destination address, source address, Traffic Class, TCP/UDP port, etc. At each subsequent hop, the forwarding decision can be made solely by examining the incoming label without further reference to the packet's header or contents. The 6LSA uses the Flow Label field in the IPv6 header to represent the FEC of the packet. Constraints on using the IPv6 Flow Label field are described in RFC 3697, IPv6 Flow Label Specification [RFC 3697]. Among other considerations, this document requires that the Flow Label be passed unchanged from source to destination. The 6LSA Label Switching Routers (6LSRs), however, should be free to make use of this field. If the source host has left the field set to zero, an egress 6LSR, when it forwards a packet to a non-6LSA router, can set the Flow Label back to zero thus restoring it to its original state. In the 6LSA architecture, each port on a 6LSR would be configured as an "edge" (ingress/egress) port or a "network" port. These routers could include non-6LSR ports as well, but such configurations are beyond the scope of this document. Packets eligible for 6LSA treatment that arrive at an edge port of a 6LSR are bound to an FEC. The FEC is represented by a non-zero value inserted in the IPv6 Header Flow Label field. Of course if a packet arriving at a 6LSR ingress port is to be forwarded out another edge (egress) port on the same 6LSR, the Flow Label field need not be changed. Therefore the 6LSA switching technique applies only to packets being forwarded out network ports on the 6LSR. This also provides the flexibility of IP routing as well as label switching of packets. Because of the requirement to maintain the integrity of the Flow Label field, the 6LSA switching technique can only be applied to packets arriving at an edge port with their Flow Label field set to zero. In future work on 6LSA, more generalized treatment of packets that arrive with non-zero Flow Label will be presented. In the simplest design, we assume that the network can be configured so that only the former packets with zero label arrive at 6LSR edge ports. More involved techniques for separating and marking 6LSA-eligible packets arriving at edge ports are discussed in Section 5. A packet arriving at a network port on a 6LSR must either have a 0 Flow Label field (indicating the first packet in a new flow), have its Flow Label field set by the upstream (previous-hop) router as an indication of the packet's FEC (for the current router), or be marked in some way as ineligible for 6LSA-treatment. If the packet is eligible for 6LSA treatment and is being forwarded out an edge (egress) port, the Flow Label is set to zero. If an eligible packet Bound, et al. Expires October 8, 2005 [Page 5] Internet-Draft Binding Packets to FECs in 6LSA April 2005 is being forwarded out a network port, the Flow Label field is unchanged if it is zero (indicating a new flow to the next-hop) or set to the value corresponding to the packet's FEC at the next-hop LSR. The remainder of this document will focus on two questions: 1) How does a 6LSR construct FECs? 2) How does a 6LSR bind packets to an FEC? 4. FEC Construction For the purposes of this discussion, an FEC is viewed as a list of one or more addresses or prefixes with their associated Traffic Class value for QoS or precedence. Packets destined for any of the addresses/prefixes in the list (with the specified QoS if applicable) will be forwarded in exactly the same way, e.g., they will be sent out the same port with the same data link encapsulation, and the same outgoing label. The simplest instance of an FEC is a single IPv6 address with default forwarding precedence. A significantly more complicated FEC might be a list of all routing table entries with the same next-hop. The forwarding treatment for a set of packets is represented by a forwarding data structure. This structure contains the required forwarding information including: 1) PacketÆs next-hop 2) Outgoing interface 3) Outgoing label 4) Data link encapsulation 5) Precedence or outbound queuing information. In general, IPv6 packets will arrive at a 6LSR network port with a non-zero label in the header (unless it is the first packet in the flow). In order to determine the proper forwarding treatment for the packet the 6LSR will consult a switching table which maps inbound labels to the appropriate forwarding data structure. The forwarding structure will define how to send the packet to its next hop including what outbound label to use if the outgoing port is not an edge port. Multiple switching table entries can refer to the same forwarding data structure. Similarly, a single incoming label can map to multiple forwarding entries to permit load balancing. Bound, et al. Expires October 8, 2005 [Page 6] Internet-Draft Binding Packets to FECs in 6LSA April 2005 There are several methods that might be used to populate the forwarding data structure list and switching table. Those that will be discussed here are: 1) Manual configuration 2) Network management (SNMP) 3) Inference from incoming packets 4) Label distribution protocol 4.1 Manual Configuration Fixed paths through a 6LSA domain (tunnels) can be pre-computed and loaded into a 6LSR by manual or semi-automatic means. For example, a configuration file containing the switching table could be downloaded into a device from a central distribution point. While not very practical for large systems in large networks, this approach might be useful in certain cases. The syntax of the commands needed to configure the device are of course implementation dependent and have to be consistent with the overall command structure of the device. 4.2 Network Management With the definition of appropriate MIBs, SNMP could be used to set up the forwarding data structures and the switching table for a 6LSR. Again, this technique would be most useful for setting up tunnels through a 6LSA domain with fairly static links. The information that would have to be supplied to the router would include the contents of the forwarding data structure for each FEC being configured using the MIB as well as one or more switching table entries mapping an incoming label to that data structure. Information contained in the forwarding data structure would have to be sufficient to accomplish forwarding to the next-hop 6LSR. This would include outgoing port, outgoing label and data link encapsulation if required. Each of these data structure elements could be defined by an entry in a MIB table. Likewise, the contents of the switching table could be specified by entries in a second MIB table. An example of a MIB for configuring MPLS LSPs is presented in ôMultiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Baseö (RFC 3813). The MIB(s) necessary to implement this approach in the 6LSA will be defined in a separate document. Bound, et al. Expires October 8, 2005 [Page 7] Internet-Draft Binding Packets to FECs in 6LSA April 2005 4.3 Pseudoflow If the FECs are limited to a single element consisting of one address, the incoming label can be distributed piggy-backed onto a data packet. With this approach, a 6LSR forwarding packets out a network port selects an unused label from its own label space. The label space can be per-platform or per-port (if the next-hop router can unambiguously determine the label space of the packet it receives, e.g., on a point-to-point link). The chosen label is added to the forwarding data structure as the outgoing label for the FEC and is also inserted into the Flow Label field of the outgoing packet. The packet is then forwarded per the information contained in the forwarding data structure, i.e., along the routed path. When the packet is received at the next-hop router, that 6LSR can locate its own forwarding data structure for the packet by means of the packetÆs destination address. The label in the incoming packet is used to create the switching table entry associating that label with the forwarding data structure. The forwarding treatment for succeeding packets can then be determined directly through a table lookup using the incoming label as an index. (In future work on 6LSA, it will be shown how only the label can be used for forwarding packets instead of the whole IP Header with each packet.) Similarly, if the FEC is limited to specific Traffic Class values, the incoming labels or one generated locally in the router could be mapped to the Traffic Class. Other ways to infer the FECs would be from the values in specific Extension Header fields. Details of such methods will be presented in future work. As explained in the 6LSA draft, the receiving router would typically set up a forwarding data structure when the lead packet for the flow to a particular destination first appears. According to the specification, the lead packet for the flow should arrive at a 6LSR port with a zero label. The zero label is in general a signal that a new flow has arrived. If, however, the lead packet is lost and the first packet to arrive has a label, the router can set up the forwarding entry for the flow at that time using the accompanying Flow Label. With the arrival of the first labeled packet for the flow, the 6LSR can set up the table entry associating the input label with the forwarding data structure. The reason that the FEC is in general limited to a single address is that the upstream 6LSR which assigns the label has no knowledge of how the next-hop 6LSR will forward the packet. For example, if the upstream 6LSR were to assign the same label to all packets destined for a particular prefix, the next-hop 6LSR would have to check the routing table each time it receives a packet with that label in order to assure that the forwarding rules Bound, et al. Expires October 8, 2005 [Page 8] Internet-Draft Binding Packets to FECs in 6LSA April 2005 for the entire prefix are identical. 4.4 Label Distribution Protocol This is the approach taken initially by MPLS. Several special protocols have been defined to distribute MPLS labels including LDP, Constrained Routing LDP [RFC 3212], and RSVP-TE. Regardless of the process used to set up the 6LSA switching table, any two adjacent 6LSRs must agree on the meaning of the labels they exchange. In particular, the label on an incoming packet must unambiguously define the forwarding behavior for the recipient of the packet. The local configuration and network management approaches mentioned above use an external agency to make adjacent routers aware of the labels' meaning. The label distribution protocol approach allows one router to simply inform its neighbor what a label means. In LDP, for example, two MPLS routers establish a session between themselves. One of the routers can then send a Label Mapping message to its peer informing the peer of the incoming label that will map to one of the sending router's FECs. This message would correspond to one entry in the Incoming Label Map (ILM) since it relates an incoming label to the Next Hop Label Forwarding Entry (NHLFE) that defines the forwarding behavior for the FEC. One of the existing label distribution protocols could be used between two 6LSRs with a minimum of modification to the protocol. This specification allows use of one or more label distribution protocols to provide FEC values to the 6LSR domain. 5. Binding IPv6 Packets to an FEC The process of binding IPv6 packets to FECs involves examination of the packet header and/or contents for the characteristics that determine membership in a certain FEC. In general, that requires specification of a set of rules that determine the appropriate FEC assignment for various types of packets. Packets should be bound to an FEC at 6LSR edge (ingress) ports. There may be several approaches to the establishment of the binding rules. Three are discussed here: Bound, et al. Expires October 8, 2005 [Page 9] Internet-Draft Binding Packets to FECs in 6LSA April 2005 1) Manual Configuration 2) Algorithmic Binding 3) Network Management 5.1 Manual Configuration Binding rules can be established by manual means either through a Command Line Interface (CLI) or by using an externally generated configuration file. The syntax of the FEC binding portion of the CLI or configuration file would have to be implementation-dependent in order to be consistent with the other router functions. As an example, consider a very simple packet classification scheme. There are two levels of service, priority and standard. Packets originating from a pre-configured set of addresses are given priority service. All others receive standard service. Also assume a very simple policing function, e.g., no more than 10% of incoming packets (over some pre-defined time period) may be given priority service. Packets exceeding this limit are given standard service. The packet classification and traffic conditioning operations described above are performed at a 6LSR edge port. For incoming packets to be eligible for 6LSA forwarding, the IPv6 Flow Label field in packets appearing at a 6LSR edge port may be set to zero. Packets with non-zero Flow Labels may be given default treatment. Thus, at the edge port, packets are divided into 3 groups: 1) Priority 6LSA packets 2) Standard 6LSA packets 3) Non-6LSA packets In this example, a 6LSA network is considered to be a ôDifferentiated Services Domainö in the sense of the applicable RFC ôDefinition of the Differentiated Series Field (DS Field) in the IPv4 and IPv6 Headersö[RFC 2474]. In this specification, a Differentiated Services Domain is defined as ôa contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashionö. Packets must enter and exit the domain through a 6LSR edge port. Within the domain, packets are forwarded between ônetworkö ports of 6LSRs. Once a packet is classified, the edge port can exercise its Differentiated Services (DS) marking function by setting the Traffic Bound, et al. Expires October 8, 2005 [Page 10] Internet-Draft Binding Packets to FECs in 6LSA April 2005 Class byte (DS Field) to the appropriate value. Once a packet is marked, downstream 6LSRs will know the correct forwarding behavior with respect to precedence. Also, downstream 6LSRs will know to leave the Flow Labels of non-6LSA packets unchanged. For Priority and Standard class 6LSA packets, the edge router can assign an outgoing label based on destination and precedence. As the marked packets arrive at successive 6LSR network ports, their forwarding class can be obtained from the Traffic Class byte in the header. The outgoing label (for outbound network ports) is assigned based on destination and Traffic Class so. This achieves the goal of having forwarding behavior solely defined by incoming label. The CLI or configuration file command syntax must be adequate to specify a variety of parameters including but not limited to: 1) Number of QoS/precedence levels 2) Differentiated Services Code Point (DSCP) or Traffic Class for each service level 3) Traffic policing parameters 4) Label assignment criteria 5.2 Algorithmic Binding The algorithm(s) for assigning packets to FECs can be coded into the 6LSR edge port packet handling software at the time it is designed. This code segment might consist of one or more filters that examine incoming packets for certain characteristics, e.g., TCP/UDP port number. The presence or absence of these characteristics would result in the packet being assigned to certain predetermined FECs. A simple example would be the case where FECs consist of single destination addresses. Edge port behavior could be coded such that each time a packet arrives for a new destination, a new FEC is created. An unused label is chosen to represent this FEC and the packet is forwarded. The obvious disadvantage of this approach is its inflexibility. Network managers would not be able to change the assignment of packets to FECs. In some cases, however, the added overhead and complexity of providing a more flexible approach might not be justified. Bound, et al. Expires October 8, 2005 [Page 11] Internet-Draft Binding Packets to FECs in 6LSA April 2005 5.3 FEC Binding using SNMP The algorithm(s) for assigning packets to FECs can be coded into the 6LSR edge port packet handling software at the time it is designed. This code segment might consist of one or more filters that examine incoming packets for certain characteristics, e.g., TCP/UDP port number. The presence or absence of these characteristics would result in the packet being assigned to certain predetermined FECs. A simple example would be the case where FECs consist of single destination addresses. Edge port behavior could be coded such that each time a packet arrives for a new destination, a new FEC is created. An unused label is chosen to represent this FEC and the packet is forwarded. The obvious disadvantage of this approach is its inflexibility. Network managers would not be able to change the assignment of packets to FECs. In some cases, however, the added overhead and complexity of providing a more flexible approach might not be justified. 6. Security Considerations Security considerations for the use of the Flow Label switching method itself are discussed in the architecture document [6LSA]. To summarize, for Security Associations operating in the transport mode, only the packet payload is encrypted and hence fields in the IPv6 header, i.e., the Flow Label field, are not affected. In the tunnel mode, the IPv6 packet is encapsulated in an outer packet which includes a new header. In this case, the Flow Label is not accessed until the packet reaches the end point of the Security Association and is unwrapped. Hence the 6LSA has no impact on security in this mode either. Techniques for setting up forwarding entries and FEC bindings have been described in this document. Those techniques involving network protocols have the same security considerations as the protocols themselves. Specific cases are outlined below. 6.1 Use of SNMP SNMP has been discussed as a possible approach to defining FECs and FEC bindings. If this technique is used, the MIBs (yet to be defined) could be used to set up 6LSPs that deliver traffic to improper destinations. This situation is discussed in the document that defines the FTN MIB [RFC 3814]. The authors of this document encourage the use of SNMPv3 which has security features built in to avoid unauthorized Set operations on MIB tables. Bound, et al. Expires October 8, 2005 [Page 12] Internet-Draft Binding Packets to FECs in 6LSA April 2005 6.2 Use of Label Distribution Protocols This document has discussed the use of a label distribution protocol for defining label-to-FEC mappings in 6LSRs. Specific security considerations would depend on the details of the protocol selected. An example of the security consequences resulting from the use of such protocols can be found in the LDP specification [RFC 3036]. This document points out that the security requirements of label distribution protocols are the same as those of routing protocols. The LDP specification states further that "To avoid label spoofing attacks, it is necessary to ensure that labeled data packets are labeled by trusted LSRs and that the labels placed on the packets are properly learned by the labeling LSRs." 7. References 1. Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997 2. [6LSA] Chakravorty, S., IPv6 Label Switching Architecture (6LSA), draft-chakravorty-6lsa-01.txt, January 2005. 3. [RFC 3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, LDP Specification, RFC 3036, January 2001. 4. [RFC 3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, December 2001. 5. [RFC 3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, IPv6 Flow Label Specification, RFC 3697, March 2004. 6. [RFC 3212] Jamoussi, B., et. al, Constraint-Based LSP Setup using LDP, RFC 3212, January2 002. 7. [RFC 2474] 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. 8. [RFC 3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB), RFC 3814, June 2004. 9. [RFC 3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813, June 2004. Bound, et al. Expires October 8, 2005 [Page 13] Internet-Draft Binding Packets to FECs in 6LSA April 2005 8. Acknowlegements The authors deeply appreciates Mitre management support for implementation of this protocol. 9. Disclaimer The authors' affiliation with HP and the MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply either HP's or MITREÆs concurrence with, or support for, the positions, opinions or viewpoints expressed by the authors. 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 Don Chirieleison The MITRE Corporation 7515 Colshire Dr. McLean, VA 22102 USA EMail: donc@mitre.org Bound, et al. Expires October 8, 2005 [Page 14] Internet-Draft Binding Packets to FECs in 6LSA 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]