Skip to main content

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

Revision differences

Document history

Date By Action
2018-12-20
(System)
Received changes through RFC Editor sync (changed abstract to 'In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the …
Received changes through RFC Editor sync (changed abstract to '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 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. [STANDARDS-TRACK]')
2015-10-14
(System) Notify list changed from softwire-chairs@ietf.org, draft-ietf-softwire-encaps-safi@ietf.org to (None)
2009-04-13
Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-04-13
Cindy Morgan [Note]: 'RFC 5512
' added by Cindy Morgan
2009-04-09
(System) RFC published