{"draft":"draft-ietf-softwire-encaps-safi-05","doc_id":"RFC5512","title":"The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute","authors":["P. Mohapatra","E. Rosen"],"format":["ASCII","HTML"],"page_count":"13","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Softwires","abstract":"In certain situations, transporting a packet from one Border Gateway\r\nProtocol (BGP) speaker to another (the BGP next hop) requires that\r\nthe packet be encapsulated by the first BGP speaker and decapsulated\r\nby the second.  To support these situations, there needs to be some\r\nagreement between the two BGP speakers with regard to the\r\n\"encapsulation information\", i.e., the format of the encapsulation\r\nheader as well as the contents of various fields of the header.\r\n\r\nThe encapsulation information need not be signaled for all\r\nencapsulation types.  In cases where signaling is required\r\n(such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic\r\nRouting Encapsulation (GRE) with key), this document specifies a method\r\nby which BGP speakers can signal encapsulation information to each\r\nother.  The signaling is done by sending BGP updates using the\r\nEncapsulation Subsequent Address Family Identifier (SAFI) and the IPv4\r\nor IPv6 Address Family Identifier (AFI).  In cases where no\r\nencapsulation information needs to be signaled (such as GRE without\r\nkey), this document specifies a BGP extended community that can be\r\nattached to BGP UPDATE messages that carry payload prefixes in order\r\nto indicate the encapsulation protocol type to be used.  [STANDARDS-TRACK]","pub_date":"April 2009","keywords":["[--------]","BGP","Encapsulation","Encap SAFI","Tunnel","Softwire","4over6","6over4"],"obsoletes":[],"obsoleted_by":["RFC9012"],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5512","errata_url":null}