Network Working Group F. Le Faucheur
Request for Comments: 5549 E. Rosen
Category: Standards Track Cisco Systems
May 2009
Advertising IPv4 Network Layer Reachability Information
with an IPv6 Next Hop
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
Multiprotocol BGP (MP-BGP) specifies that the set of network-layer
protocols to which the address carried in the Next Hop field may
belong is determined by the Address Family Identifier (AFI) and the
Subsequent Address Family Identifier (SAFI). The current AFI/SAFI
definitions for the IPv4 address family only have provisions for
advertising a Next Hop address that belongs to the IPv4 protocol when
advertising IPv4 Network Layer Reachability Information (NLRI) or
VPN-IPv4 NLRI. This document specifies the extensions necessary to
allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address
that belongs to the IPv6 protocol. This comprises an extension of
the AFI/SAFI definitions to allow the address of the Next Hop for
IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the
encoding of the Next Hop in order to determine which of the protocols
the address actually belongs to, and a new BGP Capability allowing
MP-BGP Peers to dynamically discover whether they can exchange IPv4
NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.
Le Faucheur & Rosen Standards Track [Page 1]
RFC 5549 v4 NLRI with v6 NH May 2009
Table of Contents
1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Extension of AFI/SAFI Definitions for the IPv4 Address Family ...4
4. Use of BGP Capability Advertisement .............................5
5. Operations ......................................................7
6. Usage Examples ..................................................7
6.1. IPv4 over IPv6 Core ........................................7
6.2. IPv4 VPN over IPv6 Core ....................................8
7. IANA Considerations .............................................8
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
1. Introduction
Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of
network-layer protocols to which the address carried in the Next Hop
field may belong is determined by the Address Family Identifier (AFI)
and the Subsequent Address Family Identifier (SAFI). A number of
existing AFI/SAFIs allow the Next Hop address to belong to a
different address family than the Network Layer Reachability
Information (NLRI). For example, the AFI/SAFI <25/65> used (as per
[L2VPN-SIG]) in order to perform L2VPN auto-discovery, allows
advertising NLRI that contains the identifier of a Virtual Private
LAN Service (VPLS) instance or that identifies a particular pool of
attachment circuits at a given Provider Edge (PE), while the Next Hop
field contains the loopback address of a PE. Similarly, the AFI/SAFI
<1/132> (defined in [RFC4684]) in order to advertise Route Target
(RT) membership information, allows advertising NLRI that contains
such RT membership information, while the Next Hop field contains the
address of the advertising router.
Furthermore, a number of these existing AFI/SAFIs allow the Next Hop
to belong to either the IPv4 Network Layer Protocol or the IPv6
Network Layer Protocol, and specify the encoding of the Next Hop
information in order to determine which of the protocols the address
actually belongs to. For example, [RFC4684] allows the Next Hop
address to be either IPv4 or IPv6 and states that the Next Hop field
address shall be interpreted as an IPv4 address whenever the length
of Next Hop address is 4 octets, and as an IPv6 address whenever the
length of the Next Hop address is 16 octets.
There are situations such as those described in [RFC4925] and in
[MESH-FMWK] where carriers (or large enterprise networks acting as
Le Faucheur & Rosen Standards Track [Page 2]
RFC 5549 v4 NLRI with v6 NH May 2009
carrier for their internal resources) may be required to establish
connectivity between 'islands' of networks of one address family type
across a transit core of a differing address family type. This
includes both the case of IPv6 islands across an IPv4 core and the
case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP
(MP-BGP) is used to advertise the corresponding reachability
information, this translates into the requirement for a BGP speaker
to advertise Network Layer Reachability Information (NLRI) of a given
address family via a Next Hop of a different address family (i.e.,
IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop).
The current AFI/SAFI definitions for the IPv6 address family assume
that the Next Hop address belongs to the IPv6 address family type.
Specifically, as per [RFC2545] and [RFC3107], when the <AFI/SAFI> is
<2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6
type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the Next Hop
address is assumed to be of IPv6-VPN type.
However, [RFC4798] and [RFC4659] specify how an IPv4 address can be
encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs
to be advertised with an IPv4 Next Hop. [RFC4798] defines how the
IPv4-mapped IPv6 address format specified in the IPv6 addressing
architecture ([RFC4291]) can be used for that purpose when the <AFI/
SAFI> is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4-
mapped IPv6 address format as well as a null Route Distinguisher can
be used for that purpose when the <AFI/SAFI> is <2/128>. Thus, there
are existing solutions for the advertisement of IPv6 NLRI with an
IPv4 Next Hop.
Similarly, the current AFI/SAFI definitions for advertisement of IPv4
NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the
IPv4 address family type. Specifically, as per [RFC4760] and
[RFC3107], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the Next
Hop address is assumed to be of IPv4 type. As per [RFC4364], when
the <AFI/SAFI> is <1/128>, the Next Hop address is assumed to be of
VPN-IPv4 type. There is clearly no generally applicable method for
encoding an IPv6 address inside the IPv4 address field of the Next
Hop. Hence, there is currently no specified solution for advertising
IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop.
This document specifies the extensions necessary to do so. This
comprises an extension of the AFI/SAFI definitions to allow the
address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to
either the IPv4 or the IPv6 protocol, the encoding of the Next Hop
information in order to determine which of the protocols the address
actually belongs to, and a new BGP Capability allowing MP-BGP peers
to dynamically discover whether they can exchange IPv4 NLRI and VPN-
IPv4 NLRI with an IPv6 Next Hop. The new BGP Capability allows
Le Faucheur & Rosen Standards Track [Page 3]
RFC 5549 v4 NLRI with v6 NH May 2009
gradual deployment of the new functionality of advertising IPv4
reachability via an IPv6 Next Hop, without any flag day nor any risk
of traffic black-holing.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Extension of AFI/SAFI Definitions for the IPv4 Address Family
As mentioned earlier, MP-BGP specifies that the set of network-layer
protocols to which the address carried in the Next Hop field may
belong is determined by the Address Family Identifier (AFI) and the
Subsequent Address Family Identifier (SAFI). The following current
AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>,
<1/2>, <1/4>, and <1/128>) only have provisions for advertising a
Next Hop address that belongs to the IPv4 protocol. This document
extends the definition of the AFI/SAFI for advertisement of IPv4 NLRI
and VPN-IPv4 NLRI to extend the set of network-layer protocols to
which the Next Hop address can belong, to include IPv6 in addition to
IPv4.
Specifically, this document allows advertising with [RFC4760] of an
MP_REACH_NLRI with:
o AFI = 1
o SAFI = 1, 2, 4, or 128
o Length of Next Hop Address = 16 or 32
o Next Hop Address = IPv6 address of next hop (potentially followed
by the link-local IPv6 address of the next hop). This field is to
be constructed as per Section 3 of [RFC2545].
o NLRI= NLRI as per current AFI/SAFI definition
This is in addition to the current mode of operation allowing
advertisement of NLRI for <AFI/SAFI> of <1/1>, <1/2> and <1/4> with a
next hop address of IPv4 type and advertisement of NLRI for <AFI/
SAFI> of <1/128> with a next hop address of VPN-IPv4 type.
The BGP speaker receiving the advertisement MUST use the Length of
Next Hop Address field to determine which network-layer protocol the
next hop address belongs to. When the Length of Next Hop Address
field is equal to 16 or 32, the next hop address is of type IPv6.
Le Faucheur & Rosen Standards Track [Page 4]
RFC 5549 v4 NLRI with v6 NH May 2009
Note that this method of using the Length of the Next Hop Address
field to determine which network-layer protocol the next hop address
belongs to (out of the set of protocols allowed by the AFI/SAFI
definition) is the same as used in [RFC4684] and [L2VPN-SIG].
4. Use of BGP Capability Advertisement
[RFC5492] defines a mechanism to allow two BGP speakers to discover
if a particular capability is supported by their BGP peer and thus
whether it can be used with that peer. This document defines a new
capability that can be advertised using [RFC5492] and that is
referred to as the Extended Next Hop Encoding capability. This
capability allows BGP speakers to discover whether, for a given NLRI
<AFI/SAFI>, a peer supports advertisement with a next hop whose
network protocol is determined by the value of the Length of Next Hop
Address field, as specified in Section 3.
A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop
for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use
the Capability Advertisement procedures defined in [RFC5492] with the
Extended Next Hop Encoding Capability to establish whether its peer
supports this for the NLRI AFI/SAFI pair(s) of interest. The fields
in the Capabilities Optional Parameter MUST be set as follows:
o The Capability Code field MUST be set to 5 (which indicates the
Extended Next Hop Encoding capability).
o The Capability Length field is set to a variable value that is the
length of the Capability Value field (which follows).
o The Capability Value field has the following format:
+-----------------------------------------------------+
| NLRI AFI - 1 (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - 1 (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets) |
+-----------------------------------------------------+
| ..... |
+-----------------------------------------------------+
| NLRI AFI - N (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - N (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - N (2 octets) |
+-----------------------------------------------------+
Le Faucheur & Rosen Standards Track [Page 5]