BESS Working Group S. Litkowski
Internet-Draft S. Agrawal
Intended status: Informational Cisco
Expires: May 7, 2020 K. Patel
Arrcus
S. Zhuang
Huawei
November 4, 2019
Modifying RFC5549 VPNv4 over IPv6 next hop handling procedures
draft-litkowski-bess-vpnv4-ipv6-nh-handling-00
Abstract
RFC4364 and RFC4659 define respectively BGP extensions to provide
VPN-IPv4 and VPN-IPv6 services. When defined RFC5549 has brought up
an inconsistency in how the next hop is encoded when a VPN-IPv4 NLRI
carries an IPv6 next hop compared to RFC4364 and RFC4659. For some
reasons, existing and deployed implementations of RFC5549 haven't
followed the specification and are using an VPN-IPv6 next hop as in
RFC4364 and RFC4659. Moving these implementations to be compliant
with RFC5549 may break existing network deployments. This document
proposes a modification of RFC5549 to enable compliancy of these
implementations. These document also proposes additional
modifications of RFC5549 to address missing points.
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.
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
Litkowski, et al. Expires May 7, 2020 [Page 1]
Internet-Draft vpnv4-ipv6-nh-handling November 2019
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 May 7, 2020.
Copyright Notice
Copyright (c) 2019 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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Requested modifications . . . . . . . . . . . . . . . . . . . 3
2.1. Modifying next hop encoding . . . . . . . . . . . . . . . 3
2.2. Handling of VPN IPv4 multicast SAFI . . . . . . . . . . . 4
3. Deployment considerations . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Problem statement
[RFC4364] and [RFC4659] define respectively BGP extensions to provide
VPN-IPv4 and VPN-IPv6 services.
[RFC4364] defines only VPN-IPv4 carried with an IPv4 next hop. For
historical reasons, as per Section 4.3.2 of [RFC4364], the next hop
address is encoded as a VPN-IPv4 address with an RD of 0. The
expected next hop length value is 12 bytes. As stated in
Section 4.3.2 of [RFC4364], the justification of using a VPN-IPv4
address in the next hop field came from [RFC2858] which required the
next hop address to be in the same address family as the Network
Layer Reachability Information.
Litkowski, et al. Expires May 7, 2020 [Page 2]
Internet-Draft vpnv4-ipv6-nh-handling November 2019
[RFC4659] defines VPN-IPv6 carried over with either an IPv4 or IPv6
next hop. When IPv4 transport is used, the next hop is encoded as a
VPN-IPv6 address with an RD set to 0 followed by the IPv4-mapped IPv6
address of the advertising BGP speaker. The expected next hop length
is 24 bytes. When IPv6 transport is used, the next hop is encoded as
one or two VPN-IPv6 address(es) still using an RD set to 0.
Section 3.2.1.1 of [RFC4659] clearly states: "the BGP speaker SHALL
advertise a Next Hop Network Address field containing a VPN-IPv6
address (...) This is potentially followed by another VPN-IPv6
address".
[RFC5549] specifies, among other, the extensions to allow advertising
VPN-IPv4 NLRI with an IPv6 protocol next hop. In such a case the
next hop of the NLRI is encoded as one or two IPv6 addresses.
[RFC5549] does not use VPN-IPv6 addresses but regular IPv6 addresses
(no RD) in the next hop field. Refer to Section 4 and Section 6.2 of
[RFC5549] for more details. As a consequence, [RFC5549] brings an
inconsistency in how the next hop is encoded for VPN SAFIs compared
to [RFC4364] and [RFC4659].
While, from a pure specification point of view, this inconsitency
between next hop encodings does not create any issue, several
existing implementations are using a consistent encoding of the next
hop using VPN-IPvx format (using RD set to 0) for all the cases
listed above. Authors have looked at nine implementations including
the major ones deployed in the market, and all these implementations
are encoding the next hop using a VPN-IPv4 format (with RD set to 0),
except two which does not support [RFC5549] at all. Although these
multiple implementations are not compliant with [RFC5549], modifying
these implementations may create backward compatibility issues as
well as operation pain for operators who have deployed.
In addition, [RFC5549] only deals with VPN-IPv4 unicast address-
family (AFI=1, SAFI=128), but does not handle the case of the VPN-
IPv4 multicast address family (AFI=1, SAFI=129).
This document proposes a modification of [RFC5549] for the VPN-IPv4
family to address these problems.
2. Requested modifications
2.1. Modifying next hop encoding
While authors agree that nowadays using a VPN-IP address in a BGP
next hop field does not make any sense, to accomodate running codes,
deployments and bring consistency with legacy, authors propose
[RFC5549] next hop encoding rules to be modified when IPVPN SAFIs are
used.
Litkowski, et al. Expires May 7, 2020 [Page 3]
Internet-Draft vpnv4-ipv6-nh-handling November 2019
This document proposes to add the following text as part of Section 4
of [RFC5549]:
o When the AFI=1 and when the SAFI is an IPVPN SAFI (128 or 129), a
BGP speaker MUST encode the next hop as VPN-IPv6 address(es) with
an RD set to zero.
To accomodate this text, the example provided in Section 6.2 of
[RFC5549] must also be modified as follows:
o Section 6.2 title must be changed to "IPv4 VPN unicast over IPv6
Core"
o OLD TEXT:
The MP_REACH_NLRI is encoded with:
+ AFI = 1
+ SAFI = 128
+ Length of Next Hop Network Address = 16 (or 32)
+ Network Address of Next Hop = IPv6 address of Next Hop
+ NLRI = IPv4-VPN routes
o NEW TEXT:
The MP_REACH_NLRI is encoded with:
+ AFI = 1
+ SAFI = 128
+ Length of Next Hop Network Address = 24 (or 48)
+ Network Address of Next Hop = IPv6 address of Next Hop
encoded as a VPN-IPv6 address with RD set to 0
+ NLRI = IPv4-VPN routes
2.2. Handling of VPN IPv4 multicast SAFI
VPN IPv4 multicast SAFI (AFI=1, SAFI=129) must be handled in the same
way as the VPN IPv4 unicast SAFI (AFI=1, SAFI=128).
Litkowski, et al. Expires May 7, 2020 [Page 4]
Internet-Draft vpnv4-ipv6-nh-handling November 2019
This document proposes to modify [RFC5549] as follows to accomodate
this change:
o Section 3:
OLD TEXT:
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.
NEW TEXT:
The following current AFI/SAFI definitions for the IPv4 NLRI or
VPN-IPv4 NLRI (<1/1>, <1/2>, <1/4>, <1/128>, and <1/129>) only
have provisions for advertising a Next Hop address that belongs
to the IPv4 protocol.
o Section 3:
OLD TEXT:
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.
NEW TEXT:
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> and <1/129> with a next hop address
of VPN-IPv4 type.
o Section 3 line "SAFI = 1, 2, 4, or 128" must be changed to "SAFI =
1, 2, 4, 128, or 129".
o Section 4 line "NLRI SAFI = 1, 2, 4, or 128" must be changed to
"NLRI SAFI = 1, 2, 4, 128, or 129".
o A Section 6.3 named "IPv4 VPN multicast over IPv6 Core" may be
added to provide an example with the following text:
Litkowski, et al. Expires May 7, 2020 [Page 5]
Internet-Draft vpnv4-ipv6-nh-handling November 2019
The extensions defined in this document may be used for support of
IPv4 VPNs for multicast over an IPv6 backbone. In this application,
PE routers would advertise VPN-IPv4 multicast NLRI in the MP_REACH_NLRI
along with an IPv6 Next Hop.
The MP_REACH_NLRI is encoded with:
o AFI = 1
o SAFI = 129
o Length of Next Hop Network Address = 24 (or 48)
o Network Address of Next Hop = IPv6 address of Next Hop encoded
as a VPN-IPv6 address with RD set to 0
o NLRI = IPv4-VPN routes
During BGP Capability Advertisement, the PE routers would include the
following fields in the Capabilities Optional Parameter:
o Capability Code set to "Extended Next Hop Encoding"
o Capability Value containing <NLRI AFI=1, NLRI SAFI=129, next hop
AFI=2>
3. Deployment considerations
As most of the vendors and deployments today are already implementing
the VPN-IPv6 address in the next hop field, interoperability in these
deployments will not be broken when modifying [RFC5549]. Even if
authors have polled multiple vendors including all the major players
of the market, there is still a possibility that an existing
implementation strictly follows [RFC5549] as it is today. While it
should be unlikely, it could happen. In case such a situation exists
today, this compliant implementation is not interoperable with most
of the implementations of the market and code changes are required
(at one side or the other) to get the interoperability. It should be
noted that no interoperability issue has been brought to vendors by
customers or during interoperability testing between vendors at EANTC
for example. By modifying [RFC5549] as we propose, this hypothetical
compliant implementation will not be compliant anymore and will
require code change to become compliant. This code change can simply
be a knob on a per-neighbor basis to accomodate the behavior of the
neighbor without breaking any hypothetical deployment between RFC5549
compliant implementations.
Litkowski, et al. Expires May 7, 2020 [Page 6]
Internet-Draft vpnv4-ipv6-nh-handling November 2019
As IETF is driven by running code, authors think that changing the
existing standard to accomodate running codes and deployments will
help the overall industry without causing damages. In case a
compliant implementation exists today (but again it is really
unlikely), this implementation can add a knob to provide new
compliancy and interoperability. This approach will require fewer
code changes within the whole industry and then keep most of the
existing deployments more stable.
4. Security Considerations
This document does not introduce any additional security issue
compared to [RFC4364],[RFC4659] and [RFC5549].
5. Acknowledgements
6. IANA Considerations
IANA has no action.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<https://www.rfc-editor.org/info/rfc4659>.
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
RFC 5549, DOI 10.17487/RFC5549, May 2009,
<https://www.rfc-editor.org/info/rfc5549>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Litkowski, et al. Expires May 7, 2020 [Page 7]
Internet-Draft vpnv4-ipv6-nh-handling November 2019
7.2. Informative References
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858,
DOI 10.17487/RFC2858, June 2000,
<https://www.rfc-editor.org/info/rfc2858>.
Authors' Addresses
Stephane Litkowski
Cisco
Email: slitkows@cisco.com
Swadesh Agrawal
Cisco
Email: swaagrawa@cisco.com
Keyur Patel
Arrcus
Email: keyur@arrcus.com
Shunwan Zhuang
Huawei
Email: zhuangshunwan@huawei.com
Litkowski, et al. Expires May 7, 2020 [Page 8]