Network Working Group X. Xu Internet-Draft Huawei Intended status: BCP P. Francis Expires: August 15, 2009 MPI-SWS February 11, 2009 GRE and IP-in-IP Tunnels for Virtual Aggregation draft-xu-va-tunnels-gre-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The document "FIB Suppression with Virtual Aggregation" Xu & Francis Expires August 15, 2009 [Page 1] Internet-Draft VA GRE Tunnels February 2009 [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for GRE and IP-in-IP tunnels. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. Tunneling Requirements . . . . . . . . . . . . . . . . . . . . 3 3. Tunneling Specification for GRE and IP-in-IP . . . . . . . . . 3 3.1. Signaling GRE and IP-in-IP tunnels . . . . . . . . . . . . 4 3.1.1. Syntax of the Address Specific BGP Extended Communities Attribute . . . . . . . . . . . . . . . . . 4 3.1.2. Usage of the Address Specific BGP Extended Communities Attribute . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Xu & Francis Expires August 15, 2009 [Page 2] Internet-Draft VA GRE Tunnels February 2009 1. Introduction This document specifies how to use and signal the tunnels required by [I-D.francis-intra-va], "FIB Suppression with Virtual Aggregation", for GRE and IP-in-IP . This document adopts the terminology of [I-D.francis-intra-va]. This document covers the behavior for both VA routers and legacy routers. 1.1. Requirements notation 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. Tunneling Requirements According to [I-D.francis-intra-va], VA has the following tunnel- related requirements. The requirement numbers here (R1 - R5) are cited by [I-D.francis-intra-va]. R1: Legacy routers and APRs must be able to detunnel packets addressed to themselves at their BGP NEXT_HOP address. They must be able to signal the tunnel information needed by other routers to initiate these tunneled packets. R2: Border VA routers must be able to detunnel packets targeted to neighboring remote ASBRs. They must be able to forward these packets to the targeted remote ASBR without doing a FIB lookup. They must be able to signal the tunnel information needed by other routers to initiate these tunneled packets. R3: VA routers must be able to initiate tunneled packets targeted to any BGP NEXT_HOP address (i.e. those for APRs, legacy routers, or remote ASBRs). R4: Legacy routers may optionally be able to initiate tunneled packets targeted to any BGP NEXT_HOP address (i.e. those for APRs, legacy routers, or remote ASBRs). The GRE and IP-in-IP tunnels defined in this document do not have this capability. R5: All routers must be able to forward all tunneled packets. 3. Tunneling Specification for GRE and IP-in-IP This documents distinguishes between the terms "tunnel endpoint", and "tunnel target". The tunnel endpoint is the router that detunnels the packet (i.e. strips out the outer header and forwards the no- longer-tunneled packet). The tunnel target, on the other hand, is the BGP NEXT_HOP to which the packet is going. This distinction manifests itself in the case of requirement R2. That is, a local Xu & Francis Expires August 15, 2009 [Page 3] Internet-Draft VA GRE Tunnels February 2009 ASBR (border router) is a VA router, and it advertises a BGP NEXT_HOP of its neighbor remote ASBR. Here, the tunnel endpoint is the local ASBR, and the tunnel target is the remote ASBR. The IP address of the outer header for GRE and IP-in-IP tunnels is always addressed to the tunnel endpoint. If the tunnel endpoint and the tunnel target are the same router (as with the case in requirement R1), then the tunnel type may be GRE or IP-in-IP. If the former, then the Key field may or may not be used. If the tunnel endpoint and the tunnel target are different routers (as is the case in requirement R2), then GRE must be used. Further, the Key field is set to a value that identifies the tunnel target to the tunnel endpoint. For example, suppose a local ASBR with address 1.1.1.1 has two remote ASBR neighbors, with addresses 2.2.2.2 and 3.3.3.3 respectively. The local ASBR would assign two GRE Key values, one for each remote ASBR neighbor. All GRE packets would arrive at 1.1.1.1 (the tunnel endpoint), which would then look at the Key value to determine whether to forward the packet to 2.2.2.2 or 3.3.3.3. Note that no FIB lookup is necessary. 3.1. Signaling GRE and IP-in-IP tunnels To signal the information necessary for routers to initiate tunneled packets (i.e. requirement R3), two BGP attributes are used. The first attribute serves to indicate that the router advertising the attribute can receive tunneled packets, and additionally conveys the tunnel endpoint address. The Address Specific BGP Extended Communities Attribute for IPv4 and IPv6 is used for this purpose ([RFC4360] and [I-D.ietf-l3vpn-v6-ext-communities] respectively). The other BGP attribute is used when the tunnel type is GRE, and is used to convey the GRE Key value and other GRE parameters. For this purpose, the Tunnel Encapsulation Attribute (TEncap-Attribute) defined in [I-D.ietf-softwire-encaps-safi] is used. 3.1.1. Syntax of the Address Specific BGP Extended Communities Attribute The value of the high-order octet for the IPv4 type field is 0x41 as defined in [RFC4360] and for the IPv6 type field it is 0x40 as defined in [I-D.ietf-l3vpn-v6-ext-communities]. The attribute is non-transitive across ASes. The value of the low-order octet for the type field (i.e. the Sub-Type) is (TBD by IANA) for IPv4 and (TBD by IANA) for IPv6. The Global Administrator field is set to the Tunnel Endpoint Address. If the Global Administrator field is set to all zeros, then the Xu & Francis Expires August 15, 2009 [Page 4] Internet-Draft VA GRE Tunnels February 2009 Tunnel Endpoint Address is the same as the BGP NEXT_HOP address. The Local Administrator field is set to zero and ignored upon receipt. If the Tunnel Attribute (TEncap-Attribute) defined in [I-D.ietf-softwire-encaps-safi] is not present, then the encapsulation type is assumed to be IP-in-IP. If the encapsulation type is GRE, then the TEncap-Attribute must be present. It defines the parameters associated with the tunnel as specified in [I-D.ietf-softwire-encaps-safi]. 3.1.2. Usage of the Address Specific BGP Extended Communities Attribute Legacy routers are configured to detunnel IP-in-IP tunnels addressed to them. They must be programmed to attach the Address Specific BGP Extended Communities Attribute to all iBGP updates. The Global Administrator field must be set to either all zeros, or to the address used as the BGP NEXT_HOP address. If it is set to all zeros, then the Tunnel Endpoint Address is assumed to be the same as the BGP NEXT_HOP address. This satisfies requirement R1 for legacy routers. VA routers must include an Address Specific BGP Extended Communities Attribute in all iBGP updates. In all cases where the BGP NEXT_HOP is set to the remote ASBR, the Global Administrator field must be an address of the VA router itself, GRE must be used, and the TEncap- Attribute must be included. The GRE Key field must be set to a value unique for that remote ASBR. If the Key value for a given remote ASBR is modified, then both the old and new Key values must identify the remote ASBR in received packets until the new iBGP updates are fully disseminated. This satisfies requirement R2. If the VA router is an APR, then for tunnels associated with the VP route, where the BGP NEXT_HOP is that of the VA router itself, GRE may or may not be used. If it is used, then the APR must have a way to distinguish tunnels targeted at itself from tunnels targeted to a neighbor remote ASBR. This can be done either by assigning a unique Key value (i.e. one not assigned to a remote ASBR), or by using no Key field at all. This satisfies requirement R1 for VA routers. All VA routers must use the tunnels described in the tunnel attributes to forward packets to resolved BGP NEXT_HOPs (requirement R3). 4. IANA Considerations There are no IANA considerations. Xu & Francis Expires August 15, 2009 [Page 5] Internet-Draft VA GRE Tunnels February 2009 5. Security Considerations There are no new security considerations beyond those already described in [I-D.francis-intra-va]. 6. Normative References [I-D.francis-intra-va] Francis, P., Xu, X., and H. Ballani, "FIB Suppression with Virtual Aggregation", draft-francis-intra-va-00 (work in progress), February 2009. [I-D.ietf-l3vpn-v6-ext-communities] Rekhter, Y., "IPv6 Address Specific BGP Extended Communities Attribute", draft-ietf-l3vpn-v6-ext-communities-01 (work in progress), December 2008. [I-D.ietf-softwire-encaps-safi] Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute", draft-ietf-softwire-encaps-safi-03 (work in progress), June 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. Authors' Addresses Xiaohu Xu Huawei Technologies No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing, Beijing 100085 P.R.China Phone: +86 10 82836073 Email: xuxh@huawei.com Xu & Francis Expires August 15, 2009 [Page 6] Internet-Draft VA GRE Tunnels February 2009 Paul Francis Max Planck Institute for Software Systems Gottlieb-Daimler-Strasse Kaiserslautern 67633 Germany Phone: +49 631 930 39600 Email: francis@mpi-sws.org Xu & Francis Expires August 15, 2009 [Page 7]