Modifying RFC5549 VPNv4 over IPv6 next hop handling procedures
draft-litkowski-bess-vpnv4-ipv6-nh-handling-00

Document Type Active Internet-Draft (individual)
Last updated 2019-11-04
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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.
Show full document text