Deployment Guidelines for Edge Peering IPv4-NLRI with IPv6-NH

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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."¶

This Internet-Draft will expire on 11 October 2021.¶

Copyright Notice

Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR-MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP) now plays an important role in the transition of the core from IPv4 to IPv6. Operators can now continue to support legacy IPv4 address family and Sub-Address-Family Virtual Private Network (VPN)-IPv4, and Multicast VPN IPv4 customers.¶

IXP are also facing IPv4 address depletion at their peering points, which are large Layer 2 transit backbones that service providers peer and exchange IPv4 and IPv6 Network Layer Reachability Information (NLRI). Today, these transit exchange points are dual stacked. One proposal to solve this issue is to use [RFC8950] to carry IPv4 (Network Layer Reachability Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering completely using the concept of [RFC5565] softwire mesh framework. So now, with the Multiprotocol Extension for Border Gateway Protocol (MP-BGP) MP-REACH capability exchanged for an IPv4 AFI/SAFI over an IPv6 next hop peer, we can now advertise IPv4(Network Layer Reachability Information) NLRI over IPv6 peering using the [RFC5565] softwire mesh framework.¶

MP-BGP specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). Historically the 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 or VPN-IPv4. [RFC8950] 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. [RFC8950] defines the encoding of the Next Hop to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to discover dynamically whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.¶

This new MP-BGP capability exchange allows the BGP peering session to act as a pure transport to allow the session to carry AFI and SAFI for both IPv4 and IPv6.¶

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 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 the Next Hop address is 4 octets, and as an IPv6 address whenever the length of the Next Hop address is 16 octets.¶

The current specification for carrying IPv4 NLRI of a given address family via a Next Hop of a different address family is now defined in [RFC8950], and 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 to determine which of the protocols the address 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.¶

With the new extensions defined in [RFC8950] supporting NLRI and next hop address family mismatch, the BGP peer session can now be treated as a pure transport and carry both IPv4 and IPv6 NLRI at the Provider Edge (PE) - Customer Edge (CE) over a single IPv6 TCP session. This allows for the elimination of dual stack from the PE-CE peering point, and now enable the peering to be IPv6-ONLY. The elimination of IPv4 on the PE-CE peering points translates into OPEX expenditure savings of point-to-point infrastructure links as well as /31 address space savings and administration and network management of both IPv4 and IPv6 BGP peers. This reduction decreases the number of PE-CE BGP peers by fifty percent, which is a tremendous cost savings for all Enterprises and Service Providers.¶

While the savings exists at the PE-CE peering, on the core side PE to Route Reflector peering carrying <AFI/SAFI> IPv4 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, the cost savings nets to a break even to be the same as with an IPV4 Core carrying IPv6 NLRI IPV6 <2/1>, VPN-IPV6 <2/128>, and Multicasat VPN <2/129>.¶

This document also provides a possible solution for IXP that are facing IPv4 address depletion at these peering points to use BGP-MP capability exchange defined in [RFC8950] to carry IPv4 NLRI in an IPv6 next hop using the [RFC5565] softwire mesh framework concept of IPv4 NLRI edge over an IPv6 core.¶

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. External BGP PE-CE Peering IPv4 and IPv6 NLRI over a single IPv6 Next Hop Peer Interoperability Testing

Today the IPv4 NLRI and IPv6 NLRI are carried over separate BGP sessions based on the address family of the NLRI being transported.¶

The goal of this document is to provide operators interoperability test result data from external BGP PE-CE edge peering between vendors Cisco, Juniper, Arista, Nokia and Huawei. The goal is also to provide critical test results to operators to depict that all the features and functionality of carrying IPv4 NLRI over a separate IPv4 peer that exists today is not only viable but recommended to be carried over a single IPv6 peer along with IPv6 NLRI. Proving to operators that this scenario can be accomplished with no loss of features and functionality using [RFC8950] IPv6 next hop encoding.¶

The test results published from this document provide concrete evidence that this is now the Best Practice for Edge peering. The document will be the de-facto standard for operators to now use a single PE-CE Edge IPv6 peer to carry both IPv4 and IPv6 NLRI.¶

With the use case defined in this document, IPv6 NLRI Unicast SAFI along with now the IPv4 NLRI Unicast SAFI, can now being carried by the single transport style IPv6 next hop peer.¶

This document describes the use case of advertising with IPv4 NLRI over IPv6 Next hop with MP_REACH_NLRI with:¶

• AFI = 1¶
• SAFI = 1¶
• Length of Next Hop Address = 16 or 32¶
• 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].¶

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.¶

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 [RFC6074].¶

4. RFC 8950 updates to RFC 5549

This section describes the updates to [RFC8950] next hop encoding from [RFC5549]. In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is encoded as an IPv6 address with a length of 16 or 32 bytes. This document modifies how the next-hop address is encoded to accommodate all existing implementations and bring consistency with VPNv4oIPv4 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 6.2 of this document). This change addresses Erratum ID 5253 (Err5253). As all known and deployed implementations are interoperable today and use the new proposed encoding, the change does not break existing interoperability.¶

[RFC5549] next hop encoding of MP_REACH_NLRI with:¶

• NLRI= NLRI as per current AFI/SAFI definition¶

Advertising with [RFC4760] MP_REACH_NLRI with:¶

• AFI = 1¶
• SAFI = 128 or 129¶
• Length of Next Hop Address = 16 or 32¶
• NLRI= NLRI as per current AFI/SAFI definition¶

[RFC8950] next hop encoding of MP_REACH_NLRI with:¶

• NLRI= NLRI as per current AFI/SAFI definition¶

Advertising with [RFC4760] MP_REACH_NLRI with:¶

• AFI = 1¶
• SAFI = 128 or 129¶
• Length of Next Hop Address = 24 or 48¶
• Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD set to zero (potentially followed by the link-local VPN-IPv6 address of the next hop with an 8-octet RD is set to zero).¶
• NLRI= NLRI as per current AFI/SAFI definition¶

5. Operational Improvements with Single IPv6 transport peer

As Enterprises and Service Providers migrate their IPv4 core to an MPLS LDPv6 or SRv6 transport, they must continue to be able to support the legacy IPv4 customers. With the new extensions defined in [RFC4760], supporting NLRI and next hop address family mismatch, the BGP peer session can now be treated as a pure transport and carry both IPv4 and IPv6 NLRI at the PE-CE edge. This paves the way to now eliminate dual stacking on all PE-CE peering points to customers making the peering IPv6 only. With this change, all IPv4 and IPv6 NLRI will now be carried over a single BGP session. This also solves the dual stack issue with IXP having to maintain separate peering for both IPv4 and IPv6. From an operations perspective the PE-CE edge peering will be drastically simplified by eliminating of IPv4 peers yielding a reduction of peers by 50 percent. From an operations perspective, prior to elimination of IPv4 peers, an audit is recommended to identify and IPv4 and IPv6 peering incongruencies that may exist and to rectify them. No operational impacts or issues are expected with this change.¶

6. Operational Considerations

With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are some operational considerations in terms of what changes and what does not change.¶

What does not change with a single IPv6 transport peer carrying IPv4 NLRI and IPv6 NLRI below:¶

Routing Policy configuration is still separate for IPv4 and IPv6 configured by capability as previously.¶

Layer 1, Layer 2 issues such as one-way fiber or fiber cut will impact both IPv4 and IPv6 as previously.¶

If the interface is in the Admin Down state, the IPv6 peer would go down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously.¶

Changes resulting from a single IPv6 transport peer carrying IPv4 NLRI and IPv6 NLRI below:¶

Physical interface is no longer dual stacked.¶

Any change in IPv6 address or DAD state will impact both IPv4 and IPv6 NLRI exchange.¶

Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the session is now tied to the transport, which now is only IPv6 address family.¶

Both IPv4 and IPv6 peer now exists under the IPv6 address family configuration.¶

Fate sharing of IPv4 and IPv6 address family from a logical perspective now carried over a single physical IPv6 peer.¶

7. IANA Considerations

There are not any IANA considerations.¶

8. Security Considerations

The extensions defined in this document allow BGP to propagate reachability information about IPv6 routes over an MPLS IPv4 core network. As such, no new security issues are raised beyond those that already exist in BGP-4 and the use of MP-BGP for IPv6. The security features of BGP and corresponding security policy defined in the ISP domain are applicable. For the inter-AS distribution of IPv6 routes according to case (a) of Section 4 of this document, no new security issues are raised beyond those that already exist in the use of eBGP for IPv6 [RFC2545].¶

9. Acknowledgments

Authors' Addresses