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]