[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                               Cristallo, De Clercq
Internet Draft                                                   Alcatel
Expires December 2000                                          June 2002




                          BGP Tunnel Attribute
                <draft-cristallo-bgp-tunnel-attr-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. 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.



2. Abstract

   This document proposes the Tunnel Attribute, which may be used by a
   given BGP Speaker to indicate whether it expects to receive all,
   some, or none of its traffic through a tunnel and the types of tunnel
   that may be used.

3. Introduction

   Several IETF proposals require the establishement of tunnels
   ([NGTRANS-BGP], [PPVPN]). There is currently no mechanism for the
   automatic configuration of these tunnels while the drafts [NGTRANS-
   BGP] and [IPsec-2547], for example, require the use of a BGP
   attribute to achieve a similar behavior. The above mentionned
   proposals being all based on BGP, the BGP protocol appears as a key
   component for the automatic establishement and configuration of these
   tunnels. The aim of this draft is to provide a BGP-based mechanism
   for the automatic configuration and establishment of tunnels. This
   draft proposes a new BGP attribute, the Tunnel Attribute, that will
   be used by BGP speakers to specify the types of tunnel that may be
   used for the transmission of traffic towards certain destination.

4. Tunnel Attribute



Cristallo, et al.        Expires December 2002                  [Page 1]


Internet Draft   draft-cristallo-bgp-tunnel-attr-00.txt        June 2002


   The TUNNEL Attribute is an optional non-transitive attribute which
   conveys tunneling-related information associated to the routes
   described in the NLRI field or in the MP_REACH_NLRI field [BGP-MP] of
   the BGP Update message. The Type Code of the Tunnel Attribute is
   TBD_IANA and is subject to the IANA considerations section of this
   draft.

   The TUNNEL Attribute contains one or several Tunnel Type values, each
   encoded on one octet. The Tunnel Type specifies the type of tunnel
   that may be used by the BGP peer that receives the route, in order to
   transfer traffic toward the set of destinations specified in the NLRI
   field or in the MP_REACH_NLRI field of the Update message. When
   several Tunnel Type values are specified, the receiver of the message
   chooses one of these values for the transmission of the traffic. The
   following types have been identified so far:

     - 0x00: No Tunnel Type specified
     - 0x01: IP in IP
     - 0x02: GRE
     - 0x03: IPSec
     - 0x04: MPLS
     - 0x05: L2TP

   Tunnel Type 0x00 SHOULD not be included in a list with other types
   different from 0x00. If a list contains type 0x00 and other types,
   the receiver SHOULD ignore the other types.

5. Operation

   A given BGP speaker may use the Tunnel Attribute to indicate whether
   it expects to receive all, some, or none of its traffic through a
   tunnel and to specify the corresponding encapsulation that may be
   used for the transmission of traffic towards the set of destinations.
   The Tunnel Attribute May contain one or several Tunnel Types, each
   encoded on one octet.

   A BGP speaker receiving a route that does not have the Tunnel
   Attribute MAY add this attribute to the Update Message when
   propagating it to its peers. In this case, tunnels will only be
   established between itself and its peers.

   A BGP speaker receiving a route with the Tunnel Attribute which does
   not recognize the attribute MUST NOT install the route (Normal
   processing of an unrecognized non-transitive attribte [BGP4]). The
   reason is that the originator of the route wants to receive its
   traffic only via one of the specified types of tunnel.

   A BGP speaker receiving a route with a recognized Tunnel Attribute
   may delete, modify or leave it unchanged when propagating the Update
   Message to its peers.

   In addition, a BGP speaker that recognizes the Tunnel Attribute in a
   route received from a peer may choose any particular value from the
   list of Tunnel Types specified by the peer, and establish a tunnel of



Cristallo, et al.        Expires December 2002                  [Page 2]


Internet Draft   draft-cristallo-bgp-tunnel-attr-00.txt        June 2002


   that type for transmission of traffic toward these destinations. As
   explained in section 6 hereafter, thanks to the negociation of
   capabilities [BGP-CAP], the list of tunnel types specified by the
   peer contains only types that are supported by both peers. The tunnel
   endpoint MUST be the BGP NEXT_HOP specified in the Update message.
   Several cases are possible:


   - Tunnel Type is 0x00: The originator of the route wants to receive
     its traffic through a tunnel, but does not want to specify the
     type, or just means that it supports any type of Tunnel. Actually,
     in this case, the choice of the value of the Tunnel Type is made by
     the receiver of the BGP Update message with the Tunnel Attribute.
     The receiver will pick one of the values that are supported by both
     speakers, as negociated at connection setup (see Section 6).

   - The list of Tunnel Types contains one or several types different
     from 0x00: The receiver chooses one of the specified values, estab-
     lishes a tunnel of that type and uses the corresponding encapsula-
     tion for transmission of traffic towards the specified set of des-
     tinations.

   If a BGP speaker receives an Update message without the Tunnel Attri-
   bute, the BGP speaker should send the traffic to the announced desti-
   nations according to a configured or default encapsulation.


6. Use of Capabilities Advertisement with BGP-4

   A BGP speaker that uses the Tunnel Attribute SHOULD use the Capabili-
   ties Advertisement procedures, as defined in [BGP-CAP], so that it
   might be able to determine if it can use such an attribute with a
   particular peer.

   The use and meaning of these fields are as follows:

   - The Capability Code is a one octet field that unambiguously identi-
     fies individual capabilities.

   - The Capability Length is a one octet field that contains the length
     of the Capability Value field in octets.

   - The Capability Value field is a variable length field that contains
     one or several Tunnel Type values, as defined in section 4 of this
     draft, each encoded on one octet. These are the tunnel types that
     the peer support a-priori. The use and meaning of this field is
     different from the Tunnel Attribute. The later specifies for which
     destinations a particular type of tunnel should be used, while the
     Capabilities Attribute specifies a set of Tunnel Types that the
     peer recognizes and supports.

   If a BGP speaker that supports the Tunnel Attribute determines that
   its peer doesn't, the speaker may send a NOTIFICATION message to the
   peer, and terminate peering. The Error Subcode in the message is set



Cristallo, et al.        Expires December 2002                  [Page 3]


Internet Draft   draft-cristallo-bgp-tunnel-attr-00.txt        June 2002


   to Unsupported Capability.

   If a BGP speaker that supports the Tunnel Attribute determines that
   its peer also supports it, the speaker will check the Tunnel Types
   specified in the Value field of the Capabilities Attribute. Only the
   Tunnel Types that are supported by both speaker could be used later
   on when the connection will be established. In case no Tunnel Type is
   supported by both peers, the Tunnel Attribute should never be
   exchanged between the peers.

   Thanks to this negociation phase, the list of Tunnel Types specified
   by a BGP speaker will only contain values that are also supported by
   the peer.

7. Examples


   - Example 1: Consider the simple example below. Site A and Site D are
     from the same corporation and make use of private addresses, while
     Sites B and E make use of public addresses. For this reason,
     traffic between site A and site D must be sent in a Tunnel, a GRE
     Tunnel for example. R3 sends to R4 routing information for Site A
     and Site B. R3 adds a Tunnel Attribute with value 0x02 in the
     Update Message sent to R4 and relative to Site A. R3 will not add
     the Tunnel Attribute in the message relative to Site B. R4 MUST
     encapsulate traffic toward Site A in an GRE Tunnel and SHOULD for-
     ward traffic to Site B in a configured or default encapsulation.
     The behavior for the traffic in the reverse direction is analogu-
     ous.

      +------------+                      +------------+
      |            |                      |            |
      |   Site A   R1                    R5   Site D   |
      |            |\                    /|            |
      +------------+ \  +------------+  / +------------+
                      \ |            | /
                       R3   Site C   R4
                      / |            | \
      +------------+ /  +------------+  \ +------------+
      |            |/                    \|            |
      |   Site B   R2   <============>   R6   Site E   |
      |            |      GRE Tunnel      |            |
      +------------+  for dest in Site A  +------------+


   - Example 2: In [NGTRANS-BGP], BGP speakers announce IPv6 routes to
     each other with BGP-MP [BGP-MP], over an IPv4 network. The IPv6
     traffic needs to be encapsulated first before traversing the IPv4
     network. Normally the used encapsulation must be configured at both
     BGP speakers. The Tunnel Attribute proposed in this draft allows
     for signalling and thus less configuration effort.






Cristallo, et al.        Expires December 2002                  [Page 4]


Internet Draft   draft-cristallo-bgp-tunnel-attr-00.txt        June 2002


      +------------+
      |            |
      |   IPv6    R1
      |            |\
      +------------+ \  +------------+     +------------+
                      \ |            |     |            |
                       R3   IPv4     R4---R5   IPv6     |
                      / |            |     |            |
      +------------+ /  +------------+     +------------+
      |            |/
      |   Site B   R2   <============>
      |            |      GRE Tunnel
      +------------+  between the IPv6 sites


   - Example 3: In [IPsec-2547], BGP peering PE routers that normally
     use MPLS to forward VPN traffic to each-other, require the possi-
     blity to signal to each other that certain traffic should be tun-
     neled through IPSec instead of through MPLS.

8. IANA Considerations

   The Type Code of the TUNNEL Attribute (Section 4) will be assigned by
   IANA.

9. Security Considerations

   This additional BGP4 attribute specification does not change the
   underlying security issues inherent in the existing BGP-4 protocol
   specification [RFC2385].

10. Acknowledgements

   The authors would like to thanks the authors of the [NGTRANS-BGP] and
   [IPsec-2547] drafts, who first suggested the use of a BGP Tunnel type
   attribute.

11. References


[BGP4]    "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, Y. Rekhter
          and T. Li, March 1995.

[BGP-MP]  "Multiprotocol Extensions for BGP-4", RFC 2858, T. Bates, R.
          Chandra, D. Katz and Y. Rekhter, June 2000.

[NGTRANS-BGP]
          "Connecting IPv6 Islands across IPv4 Clouds with BGP", draft-
          ietf-ngtrans-bgp-tunnel-04.txt, Work In Progress, De J.
          Clercq, G. Gastaud, T. Nguyen, D. Ooms, S. Prevost and F. Le
          Faucheur, January, 2002

[IPsec-2547]
          "Use of PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-



Cristallo, et al.        Expires December 2002                  [Page 5]


Internet Draft   draft-cristallo-bgp-tunnel-attr-00.txt        June 2002


          2547-01.txt, Work In Progress, E. Rosen, J. De Clercq, O.
          Paridaens, Y. T'Joens and C. Sargor, February 2002

[PPVPN]   "Using BGP as an Auto-Discovery Mechanism for Network-based
          VPNs", draft-ietf-ppvpn-bgpvpn-auto-02.txt, Work In Progress,
          Hamid Ould-Brahim, Bryan Gleeson, Peter Ashwood-Smith, Eric C.
          Rosen, Yakov Rekhter, Luyuan Fang, Jeremy De Clercq, Riad Har-
          tani, Tissa Senevirathne, January 2002

[RFC2385] "Protection of BGP sessions via the TCP MD5 Signature Option",
          RFC 2385, A. Heffernan, August 1998.

[BGP-CAP] "Capabilities Advertisement with BGP-4", RFC 2842, Chandra,
          R., Scudder, J., May 2000.

11. Authors Addresses

   Cristallo Geoffrey
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerp, Belgium
   E-mail: geoffrey.cristallo@alcatel.be

   Jeremy De Clercq
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   E-mail: Jeremy.De_Clercq@alcatel.be































Cristallo, et al.        Expires December 2002                  [Page 6]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/