Internet Draft Lou Berger (LabN) Category: Standards Track Ron Bonica (Juniper Networks) Expiration Date: April 24, 2008 Russ White (Cisco Systems) October 24, 2007 BGP/IP VPNs: BGP and CE-Based Virtual Private Networks draft-berger-l3vpn-ip-tunnels-01.txt Status of this Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 24, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo describes a routing architecture that is most applicable to Customer Edge (CE)-based Virtual Private Networks (VPNs). In this architecture, customer devices use BGP to exchange VPN routes with one another. The BGP UPDATES include a new attribute that identifies the endpoint of a tunnel that can be used to reach a particular VPN prefix. The encapsulation strategy described in this memo is more flexible than that described in RFC 4364. In this architecture, the edge router can encapsulate the original datagram twice, as in RFC 4364. In this case, the inner header provides VPN context and the outer header identifies the tunnel between edge routers. Alternatively, the edge router can encapsulate the original datagram only once, with the tunnel providing both VPN context and identifying a tunnel to the remote edge router. Berger, Bonica and White Standards Track [Page 1] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 Contents 1 Introduction .............................................. 3 1.1 Conventions used in this document ......................... 4 2 VPN Route Distribution .................................... 4 2.1 Address Families .......................................... 4 2.2 IP VPN-IPv4 NLRI and IP VPN-IPv6 NLRI Encoding ............ 4 2.2.1 BGP/IP VPN - Network Address of Next Hop .................. 5 2.2.2 BGP/IP VPN Prefix Information ............................. 8 2.3 BGP Capability Negotiation ................................ 10 3 Forwarding ................................................ 10 4 Security Considerations ................................... 11 5 IANA Considerations ....................................... 12 5.1 BGP/IP VPN SAFI ........................................... 12 5.2 BGP/IP VPN Tunnel Types .................................. 12 5.3 BGP/IP VPN Tunnel Parameter Subobject Types .............. 13 6 References ................................................ 13 6.1 Normative References ...................................... 13 6.2 Informative References .................................... 14 7 Acknowledgments ........................................... 15 8 Authors' Addresses ........................................ 15 Full Copyright Statement .................................. 15 Intellectual Property ..................................... 16 Berger, Bonica and White Standards Track [Page 2] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 1. Introduction [RFC4110] provides a taxonomy for Layer 3 Virtual Private Networks (VPNs). All VPNs share the following characteristics: - Customer enclaves are connected to a Service Provider (SP) network - Customer enclaves are assigned to a Virtual Routing and Forwarding (VRF) Instance - Customers can communicate within the VRF - Customers cannot communicate across VRF boundaries - Addressing is unique only within the VRF - VPN routing environments are isolated from one another - VPN routing environments are isolated from the service provider routing environment - Tunnels (MPLS, GRE, IPSec) connect customer enclaves to one another across the SP network [RFC4110] divides VPNs into two classes. These are: - Provider Edge (PE)-based VPNs - Customer Edge (CE)-based VPNs In a PE-based VPN, SP tunnels connect PE routers to one another. BGP/MPLS IP VPNs, see [RFC4364] and [RFC4659], leverages this architecture, using BGP to exchange VPN routes among PE routers. The BGP advertisements specify tunnel endpoint as the BGP next-hop for the VPN route. Therefore, SP interior routers need not carry VPN routes. In a CE-based VPN, tunnels connect CE routers to one another. Therefore, the routing architecture used in BGP/MPLS IP VPNs is not applicable. BGP/MPLS IP VPNs are also not applicable when MPLS is not supported. This memo describes a routing architecture similar to the routing architecture used in BGP/MPLS IP VPNs that is applicable to CE-based VPNs. We refer to the approach described in this document as "BGP/IP VPNs". In this architecture, customer devices use BGP to exchange VPN routes with one another. The BGP UPDATES include a new attribute that identifies the endpoint of a tunnel that can be used to reach a particular VPN prefix. The encapsulation strategy described in this memo is more flexible than that used in BGP/MPLS IP VPNs. In this architecture, the CE router can encapsulate the original datagram twice, as in BGP/MPLS IP VPNs. In this case, the inner header provides VPN context and the outer header identifies the tunnel between CE routers. Alternatively, Berger, Bonica and White Standards Track [Page 3] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 the CE router can encapsulate the original datagram only once, with the tunnel providing both VPN context and identifying a tunnel to the remote CE. 1.1. Conventions used in this document 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]. 2. VPN Route Distribution BGP/IP VPNs use much the same mechanisms as [RFC4364] and [RFC4659] to support VPN route distribution. The specific mechanism differs only in that no MPLS labels are required. This Section is modeled after Section 4 of [RFC4364] and Section 3 of [RFC4659] and borrows from those sources. 2.1. Address Families This document reuses the VPN-IPv4 and VPN-IPv6 address families specified in [RFC4364] and [RFC4659]. Different BGP encoding is used for these families as MPLS labels are not used. This document adds the prefix "IP" to the names of the address families, i.e., "IP VPN- IPv4" and "IP VPN-IPv6", to identify the different encoding. 2.2. IP VPN-IPv4 NLRI and IP VPN-IPv6 NLRI Encoding As with BGP/MPLS IP VPNs, BGP/IP VPN information is carried in the Multiprotocol Reachable and Unreachable Network Layer Reachability Information (NLRIs) introduced in [RFC4760]. Unlike BGP/MPLS IP VPNs, the BGP/IP VPN encoding of the VPN-IPv4 and VPN-IPv6 address families provide tunnel related information (rather than MPLS labels). This difference is reflected in the use of new formats in the "Network Address of Next Hop" and "Network Layer Reachability Information" NLRI fields. In all other respects, including formatting and processing, BGP/IP VPN route distribution is identical to BGP/MPLS VPN route distribution. This includes the encoding of the Route Distinguishers (RD) in prefixes and Route Target (RT) Attributes in extended communities. The use of BGP/IP VPN related NLRI formats is indicated by the SAFI value TBA (by IANA). The address family of a VPN route determines the type of IP VPN NLRI which, as typical, is indicated by the AFI. Berger, Bonica and White Standards Track [Page 4] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 IPv4 VPN routes MUST be encoded in an IP VPN-IPv4 NLRI with an AFI of 1. IPv6 VPN routes MUST be encoded in an IP VPN-IPv6 NLRI with an AFI of 2. With the exception of the "Network Address of Next Hop" and "Network Layer Reachability Information" NLRI fields, both types of NLRIs MUST be encoded as defined in [RFC4364] (for the IP VPN-IPv4 NLRI) and in [RFC4659] (for the IP VPN-IPv4 NLRI). 2.2.1. BGP/IP VPN - Network Address of Next Hop With IP VPN NLRIs, the Network Address of Next Hop NLRI field carries the IP address and related tunnel parameters that should be used to reach a particular VPN route. The IP address is the address to be used by receiving routers as the destination tunnel end-point address. Tunnel parameters indicate the type of tunnel supported by the advertising router for the particular route. Tunnel parameters may optionally indicate tunnel specific information, e.g, destination port or other tunnel identifying information. The format of the Network Address of Next Hop field used in BGP/IP VPN route distribution is: +---------------------------+ | Tunnel Flags (1 octet) | +---------------------------+ | Tunnel Type (1 octet) | +---------------------------+ | Tunnel Address (variable) | +---------------------------+ | Tunnel Params. (variable) | +---------------------------+ The use and meaning of these fields are as follows: Tunnel Flags: (Bit Field) The following flags are defined: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V| Reserved | +-+-+-+-+-+-+-+-+ Version (V): The Version bit is used to indicate the IP version of the Tunnel Address field. The flag MUST be cleared, i.e., zero (0), when the tunnel end-point address carried in the Tunnel Address field is an IPv4 address. The flag MUST be set, Berger, Bonica and White Standards Track [Page 5] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 i.e., one (1), when the Tunnel Address field carries an IPv6 address. Tunnel Type: (Unsigned Integer) This field indicates the type of tunnel that should be used to transport data associated with the advertised VPN route. Note that the mechanisms related to establishment and management of tunnels are outside the scope of this document. The following Type values are defined: Value Type ----- ---------------------------------------- 0 Reserved 1 Generic Route Encapsulation (GRE) [RFC1701] 2 IP-in-IP [RFC2003] 3 IP Authentication Header in the Tunnel-mode (AH) [RFC4301] 4 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [RFC4303] 5 Reserved (contact authors) Tunnel Address: The Tunnel Address field contains the destination tunnel end- point IP address that SHOULD be used to reach the advertised VPN route. The type of address and the size of the field can be determined by examining the V-bit. When the V-bit is not set, i.e., zero (0), the Tunnel Address field MUST contain a 4-octet IPv4 address. When the V-bit is set, i.e., one (1), the Tunnel Address field MUST contain a 16-octet IPv6 address. Tunnel Parameters: The Tunnel Parameters field contains a series of variable- length data items called Tunnel Parameter, or TP, subobjects. Each TP subobject has the following format: +---------------------------+ | TP Type (1 octet) | +---------------------------+ | TP Length (1 octet) | +---------------------------+ | TP Contents (variable) | +---------------------------+ The use and meaning of these fields are as follows: Berger, Bonica and White Standards Track [Page 6] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 Tunnel Parameter (TP) Type: (Unsigned Integer) This field indicates the type of tunnel parameters contained in the TP subobject. Two value ranges are defined. The first range is used for parameters that are independent of any particular tunneling technology and are shared across all Tunnel Type field values. The second range is specific to, and only has meaning in the context of a particular Tunnel Type field values, i.e., identified by the tuple . The value ranges are as followed: Range Use ------- ---------------------------------------- 0-63 Common tunnel parameters (Applies to all Tunnel Types) 64-127 Tunnel Type (technology) specific tunnel parameters 128-255 Reserved TP Type one (1) is defined below in Section 2.2.1.1. Tunnel Parameter (TP) Length: (Unsigned Integer) The TP Length field contains of the total length of the tunnel parameters subobject in octets, including the TP Type and TP Length fields. The TP Length field MUST be equal to or greater than 2. Tunnel Parameter (TP) Contents: The actual information carried in the subobject. Subobjects with TP subobject types that are not recognized by a receiver SHOULD be silently ignored. 2.2.1.1. Alternate Address Tunnel Parameter (AA-TP) Subobject The Alternate Address Tunnel Parameter (AA-TP) Subobject is used to provide an additional destination tunnel end-point IP address. When this subobject is present, the address provided in the subobject along with the address provided in the next hop Tunnel Address field and any other AA-TP Subobjects SHOULD be used as "equal cost" next hops. Multiple AA-TP Subobjects MAY be included in a NLRI Next Hop. The format of the AA-TP Subobject is: Berger, Bonica and White Standards Track [Page 7] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 +---------------------------+ | TP Type (=1) | +---------------------------+ | TP Length (=6 or =18) | +---------------------------+ | AA (variable) | +---------------------------+ The use and meaning of these fields are as follows: TP Type: The AA-TP Subobject may be used with any type of tunnel and MUST use the TP Type of 1. TP Length: Per the definition of TP Length, see above, this field is set to the length of the AA field in octets plus 2. TP Length MUST be set to 6 when the V bit is not set, i.e. zero (0), and MUST be set to 18 when the V bit is set, i.e., one (1). Alternate Address (AA): The Alternate Address (AA) field contains an address of the type identified by the V bits in the Tunnel Flags field. The field MUST contain an IPv4 address when the V bit is not set (0), and an IPv6 address when the V bit is set (1). 2.2.2. BGP/IP VPN Prefix Information BGP/IP VPN Prefix Information parallels the label mapping information used in BGP/MPLS VPNs, and the general definition and processing of BGP/IP VPN Prefix Information follows [RFC3107]. As with label mapping information tunnel, BGP/IP VPN Prefix Information is carried as part of an NLRI in the Multiprotocol Extensions attributes. 2.2.2.1. BGP/IP VPN Prefix Route Information Encoding The Network Layer Reachability information is encoded as one or more triples of the form . The Next Hop Token corresponds to the Network Address of Next Hop field of the NRLI. Prefix contains the reachable VPN route. When a router advertises the same Prefix with multiple NLRI Next Hop fields, the advertiser uses different Next Hop Tokens for each next hop. This allows the router to independently withdraw each advertised route. Berger, Bonica and White Standards Track [Page 8] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 The format of the BGP/IP VPN Prefix Route Information is: +---------------------------+ | Length (1 octet) | +---------------------------+ | NH Token (1 octet) | +---------------------------+ | Prefix (variable) | +---------------------------+ The use and meaning of these fields are as follows: Length: (Unsigned Integer) The Length field indicates the length in bits of the address prefix. The size of the Length and NH Token fields MUST NOT be included. Next Hop (NH) Token: (Unsigned Integer) An identifier that within the scope of the advertising router uniquely identifies the contents of the Network Address of Next Hop field associated with this route. All routes advertised with the same Next Hop field SHOULD have the same NH Token value. Routes advertised with different Next Hop field values MUST have different value NH Tokens. Note, zero (0) is a valid NH Token field value. Prefix: This field contains the IP VPN prefix that is being advertised. Both unicast and multicast prefixes MAY be carried in this field. The format of this field is the same as defined in [RFC4364]. The [RFC4364] definition is based on the following definition from [RFC3107]: "The Prefix field contains address prefixes followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant." Additionally, per [RFC4364], the Prefix field includes an 8 octet RD. The length of the Prefix field can be determined by examining the V-bit. When the V-bit is not set, i.e., zero (0), the Prefix field is a 12 octet quantity which MUST contain an 8-octet RD followed by a 4-octet IPv4 address. When the V-bit is set, i.e., one (1), the Prefix field is a 24-octet quantity which MUST contain an 8-octet RD followed by a 16-octet IPv6 Berger, Bonica and White Standards Track [Page 9] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 address. 2.2.2.2. Advertising Multiple Routes to a Destination A BGP speaker may maintain (and advertise to its peers) more than one route to a given destination. Each of these routes can be advertised using separate NLRIs with different Network Address of Next Hops, or via the AA-TP Subobject defined above in Section 2.2.1.1. When routes are advertised with different NLRI Next Hops, the routes will have different NH Tokens. Routes, with independent NH Tokens, may be independently withdrawn. When the AA-TP Subobject is used, all next hops included in the same advertisement will share the same NLRI Next Hop field and will be covered under the same NH Token and, therefore, can only be withdrawn as a group. 2.3. BGP Capability Negotiation In order for two edge routers to exchange IP VPN-IPv4 and VPN-IPv6 NLRIs, they MUST use BGP Capabilities Negotiation to ensure that they both are capable of properly processing such NLRIs. This is done as specified in [RFC4760] and [RFC3392], by using capability code 1 (multiprotocol BGP), with AFI and SAFI values as specified above, Section 2.2.1 and 2.2.2. 3. Forwarding This Section is modeled after Section 5 of [RFC4364] and Section 4 of [RFC4659] and borrows from those sources. When an edge router receives an IP packet from a CE device, the edge router MUST choose a particular VRF in which to look up the packet's destination address. This choice is typically based on the packet's ingress attachment circuit. The router MUST then look for a best match for the packet's destination IP address within the VRF. If the packet's next hop is reached directly over a VRF attachment circuit (see definition in [RFC4364]) from the processing edge router (i.e., the packet's egress attachment circuit is on the same edge router as its ingress attachment circuit), then the packet MUST be sent on the egress attachment circuit. If the ingress and egress attachment circuits are on the same edge router, but are associated with different VRFs, and if the route that best matches the destination address in the ingress attachment circuit's VRF is an aggregate of several routes in the egress Berger, Bonica and White Standards Track [Page 10] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 attachment circuit's VRF, it may be necessary to look up the packet's destination address in the egress VRF as well. If the packet's next hop is NOT reached through a VRF attachment circuit, then the packet must travel at least one hop through the backbone. The packet thus has a "BGP VPN Next Hop", which will have been advertised per Section 2.2. The packet must then be tunneled to the BGP VPN Next Hop. The packet MUST be encapsulated in a tunnel according to the type specified in the NLRI Next Hop of the advertised route. The encapsulated packet MUST then be forwarded as a standard IP packet. As previously mentioned, the specifics of tunnel establishment are outside the scope of this document. When the packet arrives at the destination tunnel end-point, it will be at the BGP VPN Next Hop. The BGP VPN Next Hop MUST strip the tunnel encapsulation, and MUST identify how the received packet is to be forwarded. The tunnel destination address will typically indicate the outgoing VRF. In this case, the packet's original IP destination address MUST be looked up in a particular VRF before being forwarded to a CE device. In other cases, the tunnel's destination address will determine the packet's egress attachment circuit. In this case, a lookup (e.g., ARP) may still need to be done in order to determine the packet's data link header on that attachment circuit. 4. Security Considerations This section borrows from Section 11 of [RFC4659]. The extensions defined in this document allow [RFC4271] to propagate reachability information about IPv4 and IPv6 VPN routes. Propagation of VPN routes within BGP is already defined in [RFC4364] and [RFC4659]. Security considerations for the transport of IPv4 and IPv6 reachability information using BGP are discussed in [RFC4271] and [RFC2545], respectively, and are equally applicable for the extensions described in this document. The extensions described in this document for offering VPNs over IP tunnels use the same BGP based route distribution approach as the approach described in [RFC4364] and [RFC4659]. Therefore, the same security considerations apply with regards to Control Plane security, and edge router and P device security as described in [RFC4364], Section 13. This document uses IP based tunnel technologies to support data plane transport. Consequently, the security considerations of those tunnel Berger, Bonica and White Standards Track [Page 11] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 technologies apply. This document defines support for GRE [RFC1701], IP-in-IP [RFC2003] and IPsec AH [RFC4301] and ESP [RFC4303]. The security considerations from those documents apply to the data plane aspects of this document. 5. IANA Considerations IANA is requested to administer assignment of new namespaces and new values for namespaces defined in this document and reviewed in this section. 5.1. BGP/IP VPN SAFI Upon approval of this document, the IANA will make the assignment in the Subsequence Address Family Identifiers (SAFI) registry located at http://www.iana.org/assignments/safi-namespace: Value Description Reference ----- ----------- --------- 141* BGP/IP VPN address [This document] (*) Suggested value. 5.2. BGP/IP VPN Tunnel Types Upon approval of this document, the IANA will establish a new registry called the "BGP/IP VPN Tunnel Types registry". This registry should be established with the following initial values. Value Type ----- ---------------------------------------- 0 Reserved 1 Generic Route Encapsulation (GRE) [RFC1701] 2 IP-in-IP [RFC2003] 3 IP Authentication Header in the Tunnel-mode (AH) [RFC4301] 4 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [RFC4303] 5 Reserved Future assignments are to be made using either the IETF Consensus process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Reserved values MUST NOT be reassigned without permission of the authors of this document. Berger, Bonica and White Standards Track [Page 12] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 5.3. BGP/IP VPN Tunnel Parameter Subobject Types Upon approval of this document, the IANA will establish a new registry called the "BGP/IP VPN Tunnel Parameter Subobject Types registry". The assignable values are broken down into the following ranges: Range Use ------- ------------------------------------------------------ 0-63 Common tunnel parameters (Applies to all Tunnel Types) 64-127 Tunnel Type (technology) specific tunnel parameters 128-255 Reserved This registry should be established with the following initial values: Value Tunnel Parameter (TP) Type ----- -------------------------------------------- 0 Reserved 1 Alternate Address Tunnel Parameter Subobject Assignments in the range of 64-127 MUST be made in the context of a particular BGP/IP VPN Tunnel Type, see Section 5.3, i.e., assignments take the form of . Future assignments in the range of 0-127 are to be made using either the IETF Consensus process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments in the range of 128-255 require Standards Action, which may impact how subsequent allocations within this range are to be made. 6. References 6.1. Normative References [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002. [RFC4271] Rekhter, Y., Ed. et al, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. Berger, Bonica and White Standards Track [Page 13] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 [RFC4659] De Clercq, J., et al, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006. [RFC4760] Bates, T. Y., Chandra, R., D. Katz, and , Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 6.2. Informative References [BGP-VPN] Ould-Brahim, H., et al, "BGP/VPN: VPN Information Discovery for Network-based VPNs", Work in progress, July 2000. [RFC1701] Hanks, S., Li, T., Traina, P., "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC4110] Callon, R., Suzuki, M., "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. [RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)" RFC 4303, December 2005. Berger, Bonica and White Standards Track [Page 14] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. 7. Acknowledgments This work has similarities to [BGP-VPN], but does not draw from that work. Several sections of this document are modeled after and use text from [RFC4364] and [RFC4659]. The very useful ASCII drawing tool JavE (www.jave.de) was used to create Figures 1 and 2. 8. Authors' Addresses Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA Email: rbonica@juniper.net Russ White Cisco Systems Email: riw@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Berger, Bonica and White Standards Track [Page 15] Internet-Draft draft-berger-l3vpn-ip-tunnels-01.txt October 24, 2007 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Berger, Bonica and White Standards Track [Page 16] Generated on: Wed Oct 24 15:59:02 EDT 2007