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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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" [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.) 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
    1.1.  Requirements notation
2.  Tunneling Requirements
3.  Tunneling Specification for GRE and IP-in-IP
    3.1.  Signaling GRE and IP-in-IP tunnels
        3.1.1.  Syntax of the Address Specific BGP Extended Communities Attribute
        3.1.2.  Usage of the Address Specific BGP Extended Communities Attribute
4.  IANA Considerations
5.  Security Considerations
6.  Normative References
§  Authors' Addresses

1.  Introduction

This document specifies how to use and signal the tunnels required by [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.), "FIB Suppression with Virtual Aggregation", for GRE and IP-in-IP . This document adopts the terminology of [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.). 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Tunneling Requirements

According to [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.), VA has the following tunnel-related requirements. The requirement numbers here (R1 - R5) are cited by [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.).

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 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] (Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute,” February 2006.) and [I‑D.ietf‑l3vpn‑v6‑ext‑communities] (Rekhter, Y., “IPv6 Address Specific BGP Extended Communities Attribute,” December 2008.) 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] (Mohapatra, P. and E. Rosen, “BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute,” June 2008.) 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] (Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute,” February 2006.) and for the IPv6 type field it is 0x40 as defined in [I‑D.ietf‑l3vpn‑v6‑ext‑communities] (Rekhter, Y., “IPv6 Address Specific BGP Extended Communities Attribute,” December 2008.). 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 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] (Mohapatra, P. and E. Rosen, “BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute,” June 2008.) 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] (Mohapatra, P. and E. Rosen, “BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute,” June 2008.).

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.

5.  Security Considerations

There are no new security considerations beyond those already described in [I‑D.francis‑intra‑va] (Francis, P., Xu, X., and H. Ballani, “FIB Suppression with Virtual Aggregation,” February 2009.).

6. Normative References

Authors' Addresses