The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute
RFC 5512

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                       P. Mohapatra
Request for Comments: 5512                                      E. Rosen
Category: Standards Track                            Cisco Systems, Inc.
                                                              April 2009

   The BGP Encapsulation Subsequent Address Family Identifier (SAFI)
               and the BGP Tunnel Encapsulation Attribute

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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

   In certain situations, transporting a packet from one Border Gateway
   Protocol (BGP) speaker to another (the BGP next hop) requires that
   the packet be encapsulated by the first BGP speaker and decapsulated
   by the second.  To support these situations, there needs to be some
   agreement between the two BGP speakers with regard to the
   "encapsulation information", i.e., the format of the encapsulation
   header as well as the contents of various fields of the header.

   The encapsulation information need not be signaled for all
   encapsulation types.  In cases where signaling is required (such as
   Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing
   Encapsulation (GRE) with key), this document specifies a method by
   which BGP speakers can signal encapsulation information to each
   other.  The signaling is done by sending BGP updates using the
   Encapsulation Subsequent Address Family Identifier (SAFI) and the
   IPv4 or IPv6 Address Family Identifier (AFI).  In cases where no
   encapsulation information needs to be signaled (such as GRE without

Mohapatra & Rosen           Standards Track                     [Page 1]
RFC 5512    BGP Encapsulation SAFI and Tunnel Encapsulation   April 2009

   key), this document specifies a BGP extended community that can be
   attached to BGP UPDATE messages that carry payload prefixes in order
   to indicate the encapsulation protocol type to be used.

Table of Contents

   1. Introduction ....................................................2
   2. Specification of Requirements ...................................4
   3. Encapsulation NLRI Format .......................................4
   4. Tunnel Encapsulation Attribute ..................................5
      4.1. Encapsulation sub-TLV ......................................6
      4.2. Protocol Type Sub-TLV ......................................7
      4.3. Color Sub-TLV ..............................................8
           4.3.1. Color Extended Community ............................8
      4.4. Tunnel Type Selection ......................................8
      4.5. BGP Encapsulation Extended Community .......................9
   5. Capability Advertisement .......................................10
   6. Error Handling .................................................10
   7. Security Considerations ........................................10
   8. IANA Considerations ............................................10
   9. Acknowledgements ...............................................11
   10. References ....................................................12
      10.1. Normative References .....................................12
      10.2. Informative References ...................................12

1.  Introduction

   Consider the case of a router R1 forwarding an IP packet P.  Let D be
   P's IP destination address.  R1 must look up D in its forwarding
   table.  Suppose that the "best match" route for D is route Q, where Q
   is a BGP-distributed route whose "BGP next hop" is router R2.  And
   suppose further that the routers along the path from R1 to R2 have
   entries for R2 in their forwarding tables, but do NOT have entries
   for D in their forwarding tables.  For example, the path from R1 to
   R2 may be part of a "BGP-free core", where there are no BGP-
   distributed routes at all in the core.  Or, as in [MESH], D may be an
   IPv4 address while the intermediate routers along the path from R1 to
   R2 may support only IPv6.

   In cases such as this, in order for R1 to properly forward packet P,
   it must encapsulate P and send P "through a tunnel" to R2.  For
   example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc.,