One document matched: draft-mpls-ipv6-only-gap-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC3107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3107.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY RFC3811 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3811.xml">
<!ENTITY RFC3812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3812.xml">
<!ENTITY RFC3813 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3813.xml">
<!ENTITY RFC3815 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3815.xml">
<!ENTITY RFC4023 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4023.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC4220 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4220.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4379 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC4447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4447.xml">
<!ENTITY RFC4558 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4558.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC4659 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4659.xml">
<!ENTITY RFC4664 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4664.xml">
<!ENTITY RFC4761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4761.xml">
<!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml">
<!ENTITY RFC4798 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4798.xml">
<!ENTITY RFC4802 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4802.xml">
<!ENTITY RFC4817 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4817.xml">
<!ENTITY RFC4875 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4875.xml">
<!ENTITY RFC4884 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4884.xml">
<!ENTITY RFC4950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4950.xml">
<!ENTITY RFC4990 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4990.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC5082 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5085 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5085.xml">
<!ENTITY RFC5088 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5088.xml">
<!ENTITY RFC5089 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5089.xml">
<!ENTITY RFC5268 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5268.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5329 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5329.xml">
<!ENTITY RFC5420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5420.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC5520 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5520.xml">
<!ENTITY RFC5521 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5521.xml">
<!ENTITY RFC5837 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5837.xml">
<!ENTITY RFC5884 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5884.xml">
<!ENTITY RFC5885 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5885.xml">
<!ENTITY RFC5886 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5886.xml">
<!ENTITY RFC6006 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6006.xml">
<!ENTITY RFC6074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6074.xml">
<!ENTITY RFC6119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6119.xml">
<!ENTITY RFC6388 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6388.xml">
<!ENTITY RFC6445 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6445.xml">
<!ENTITY RFC6512 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6512.xml">
<!ENTITY RFC6540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6540.xml">
<!ENTITY RFC6624 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6624.xml">
<!ENTITY RFC6829 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6829.xml">
<!ENTITY I-D.ietf-mpls-ldp-ipv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-ipv6.xml">
<!ENTITY I-D.ietf-l2vpn-evpn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l2vpn-evpn.xml">
<!ENTITY I-D.manral-mpls-rfc3811bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.manral-mpls-rfc3811bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-mpls-ipv6-only-gap-00" ipr="trust200902">
<!--nnn category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters-->
<title abbrev="v6-only-mpls">Gap Analysis for Operating IPv6-only MPLS
Networks</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Wesley George" initials="W" role="editor"
surname="George">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20111</code>
<country>US</country>
</postal>
<phone>+1-703-561-2540</phone>
<email>wesley.george@twcable.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Carlos Pignataro" initials="C" surname="Pignataro">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<!-- Reorder these if your country does things differently -->
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>
<phone/>
<email>cpignata@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rajiv Asati" initials="R" surname="Asati">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7025 Kit Creek Road</street>
<!-- Reorder these if your country does things differently -->
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>
<phone/>
<email>rajiva@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Kamran Raza" initials="K" surname="Raza">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>2000 Innovation Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Ottawa</city>
<region>ON</region>
<code>K2K-3E8</code>
<country>CA</country>
</postal>
<phone/>
<email>skraza@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ronald Bonica" initials="R" surname="Bonica">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>2251 Corporate Park Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone/>
<email>rbonica@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rajiv Papneja" initials="R" surname="Papneja">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<!-- Reorder these if your country does things differently -->
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>US</country>
</postal>
<phone/>
<email>rajiv.papneja@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dhruv Dhody" initials="D" surname="Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<!-- Reorder these if your country does things differently -->
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>US</country>
</postal>
<phone/>
<email>dhruv.dhody@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Vishwas Manral" initials="V" surname="Manral">
<organization>Hewlett-Packard, Inc.</organization>
<address>
<postal>
<street>19111 Pruneridge Ave.</street>
<!-- Reorder these if your country does things differently -->
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>
<phone/>
<email>vishwas.manral@hp.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="1" month="July" year="2013"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document reviews the MPLS protocol suite in the context of IPv6
and identifies gaps that must be addressed in order to allow
MPLS-related protocols and applications to be used with IPv6-only
networks. This document is not intended to highlight a particular
vendor's implementation (or lack thereof) in the context of IPv6-only
MPLS functionality, but rather to focus on gaps in the standards
defining the MPLS suite.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IPv6 is an integral part of modern network deployments. At the time
when this document was written, the majority of these IPv6 deployments
were using dual-stack implementations, where IPv4 and IPv6 are supported
equally on many or all of the network nodes, and single-stack primarily
refers to IPv4-only devices. Dual-stack deployments provide a useful
margin for protocols and features that are not currently capable of
operating solely over IPv6, because they can continue using IPv4 as
necessary. However, as IPv6 deployment and usage becomes more pervasive,
and IPv4 exhaustion begins driving changes in address consumption
behaviors, there is an increasing likelihood that many networks will
need to start operating some or all of their network nodes either as
primarily IPv6 (most functions use IPv6, a few legacy features use
IPv4), or as IPv6-only (no IPv4 provisioned on the device). This
transition toward IPv6-only operation exposes any gaps where features,
protocols, or implementations are still reliant on IPv4 for proper
function. To that end, and in the spirit of <xref target="RFC6540">RFC
6540's</xref> recommendation that implementations need to stop requiring
IPv4 for proper and complete function, this document reviews the MPLS
protocol suite in the context of IPv6 and identifies gaps that must be
addressed in order to allow MPLS-related protocols and applications to
be used with IPv6-only networks. This document is not intended to
highlight a particular vendor's implementation (or lack thereof) in the
context of IPv6-only MPLS functionality, but rather to focus on gaps in
the standards defining the MPLS suite.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Use Case">
<t>From a purely theoretical perspective, ensuring that MPLS is fully IP
version-agnostic is the right thing to do. However, it is sometimes
helpful to understand the underlying drivers that make this work
necessary to undertake, especially at a time when IPv6-only networking
is still fairly uncommon. This section will discuss some drivers. It is
not intended to be a comprehensive discussion of all potential use
cases, but rather a discussion of at least one use case so that this is
not seen as solving a purely theoretical problem.</t>
<t>IP convergence is continuing to drive new classes of devices to begin
communicating via IP. Examples of such devices could include set top
boxes for IP Video distribution, cell tower electronics (macro or micro
cells), infrastructure Wi-Fi Access Points, and devices for machine to
machine (M2M) or Internet of Things applications. In some cases, these
classes of devices represent a very large deployment base, on the order
of thousands or even millions of devices network-wide. The scale of
these networks, coupled with the increasingly overlapping use of <xref
target="RFC1918">RFC 1918</xref> address space within the average
network, and the lack of globally-routable IPv4 space available for
long-term growth begins to drive the need for many of the endpoints in
this network to be managed solely via IPv6. Even if these devices are
carrying some IPv4 user data, it is often encapsulated in another
protocol such that the communication between the endpoint and its
upstream devices can be IPv6-only without impacting support for IPv4 on
user data. Depending on the MPLS features required, it is plausible to
assume that the (existing) MPLS network may need to be extended to these
devices.</t>
<t>Additionally, as the impact of IPv4 exhaustion becomes more acute,
more and more aggressive IPv4 address reclamation measures will be
justified. Measures that were previously seen as too complex or as
netting too few addresses for the work required may become more
realistic as the cost for obtaining new IPv4 addresses increases. More
and more networks are likely to adopt the general stance that IPv4
addresses need to be preserved for revenue-generating customers so that
legacy support for IPv4 can be maintained as long as possible. As a
result, it may be appropriate for some or all of the network
infrastructure, including MPLS LSRs and LERs, to have its IPv4 addresses
reclaimed and transition toward IPv6-only operation.</t>
</section>
<section title="Gap Analysis">
<t>This gap analysis aims to answer the question, "what breaks when one
attempts to use MPLS features on a network of IPv6-only devices?" The
assumption is that some endpoints as well as PE routers, P routers
***(or LSR and LER)??*** only have IPv6 transport available, and need to
support the full suite of MPLS features defined as of the time of this
document's writing at parity with the support on an IPv4 network. This
is necessary whether they are enabled via LDP <xref target="RFC5036">RFC
5036</xref>, RSVP-TE <xref target="RFC5420">RFC 5420</xref>, GRE <xref
target="RFC4023">RFC 4023</xref>, or L2TPv3 <xref target="RFC4817">RFC
4817</xref>. It is important when evaluating these gaps to distinguish
between user data and control plane data, because while this document is
focused on IPv6-only operation, it is quite likely that some amount of
the user payload data being carried in the IPv6-only MPLS network will
still be IPv4.</t>
<section title="MPLS Control Plane">
<t/>
<section title="LDP">
<t>Label Distribution Protocol (LDP) <xref target="RFC5036">RFC
5036</xref> defines a set of procedures for distribution of labels
between label switch routers that can use the labels for forwarding
traffic. While LDP was designed to use an IPv4 or dual-stack IP
network, it has a number of deficiencies that prohibit it from
working in an IPv6-only network. <xref
target="I-D.ietf-mpls-ldp-ipv6">LDP-IPv6</xref> highlights some of
the deficiencies when LDP is enabled in IPv6 only or dual-stack
networks, and specifies appropriate protocol changes. These
deficiencies are related to LSP mapping, LDP identifiers, LDP
discovery, LDP session establishment, next hop address and LDP TTL
security <xref target="RFC5082">RFC 5082</xref>.</t>
</section>
<section title="Multicast LDP">
<t>Multipoint LDP (mLDP) is a set of extensions to LDP for setting
up Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP)
LSPs. These extensions are specified in <xref target="RFC6388">RFC
6388</xref>. In terms of IPv6-only gap analysis, mLDP has two
identified areas of interest: <list style="numbers">
<t>LDP Control plane: Since mLDP uses the LDP control plane to
discover and establish sessions with the peer, it shares the
same gaps as LDP with regards to control plane (discovery,
transport, and session establishment) in an IPv6-only
network.</t>
<t>Multipoint (MP) FEC Root address: mLDP defines its own MP
FECs and rules, different from LDP, to map MP LSPs. mLDP MP FEC
contains a Root Address field which is an IP address in IP
networks. The current specification allows specifying Root
address according to AFI and hence covers both IPv4 or IPv6 root
addresses, requiring no extension to support IPv6-only MP LSPs.
The root address is used by each LSR participating in an MP LSP
setup such that root address reachability is resolved by doing a
table lookup against root address to find corresponding upstream
neighbor(s). This will pose a problem when an MP LSP traverses
islands of IPv4 and IPv4 clouds on the way to the root node.</t>
</list>For example, consider following setup, where R1/R6 are
IPv4-only, R3/R4 are IPv6-only, and R2/R5 are dual-stack LSRs:</t>
<t><figure>
<artwork><![CDATA[( IPv4-only ) ( IPv6-only ) ( IPv4-only )
R1 -- R2 -- R3 -- R4 -- R5 -- R6
Leaf Root]]></artwork>
</figure>Assume R1 to be a leaf node for an P2MP LSP rooted at R6
(root node). R1 uses R6's IPv4 address as the Root address in MP
FEC. As the MP LSP signaling proceeds from R1 to R6, the MP LSP
setup will fail on the first IPv6-only transit/branch LSRs (R3) when
trying to find IPv4 root address reachability. <xref
target="RFC6512">RFC 6512</xref> defines a recursive-FEC solution
and procedures for mLDP when the backbone (transit/branch) LSRs have
no route to the root. The proposed solution is defined for a
BGP-free core in an VPN environment, but the similar concept can be
used/extended to solve the above issue of IPv6-only backbone
receiving an MP FEC element with an IPv4 address. The solution will
require a border LSR (the one which is sitting on border of an
IPv4/IPv6 island(s) (R2 and R5) to translate an IPv4 root address to
equivalent IPv6 address (and vice vera) through the procedures
similar to RFC6512. The translation of root address on borders of
IPv4 or IPv6 islands will also be needed for recursive FECs and
procedures defined in RFC6512.</t>
</section>
<section title="RSVP- TE">
<t>Resource Reservation Protocol Extensions for MPLS Traffic
Engineering (RSVP-TE) <xref target="RFC3209">RFC 3209</xref> defines
a set of procedures & enhancements to establish label-switched
tunnels that can be automatically routed away from network failures,
congestion, and bottlenecks. RSVP-TE allows establishing an LSP for
an IPv4 or IPv6 prefix, thanks to its LSP_TUNNEL_IPv6 object and
subobjects.</t>
<section title="IGP">
<t><xref target="RFC3630">RFC3630</xref> specifies a method of
adding traffic engineering capabilities to OSPF Version 2. New
TLVs and sub-TLVs were added in <xref
target="RFC5329">RFC5329</xref> to extend TE capabilities to IPv6
networks in OSPF Version 3.</t>
<t><xref target="RFC5305">RFC5305</xref> specifies a method of
adding traffic engineering capabilities to IS-IS. New TLVs and
sub-TLVs were added in <xref target="RFC6119">RFC6119</xref> to
extend TE capabilities to IPv6 networks.</t>
</section>
<section title="RSVP-TE-P2MP" toc="default">
<t><xref target="RFC4875">RFC4875</xref> describes extensions to
RSVP-TE for the setup of point-to-multipoint (P2MP) LSPs in MPLS
and GMPLS with support for both IPv4 and IPv6.</t>
</section>
<section title="RSVP-TE Fast Reroute (FRR)">
<t><xref target="RFC4090">RFC4090</xref> specifies FRR mechanisms
to establish backup LSP tunnels for local repair supporting both
IPv4 and IPv6 networks. Further <xref
target="RFC5268">RFC5268</xref> describes the use of loop-free
alternates to provide local protection for unicast traffic in pure
IP and MPLS networks in the event of a single failure, whether
link, node, or shared risk link group (SRLG) for both IPv4 and
IPv6.</t>
</section>
</section>
<section title="Controller, PCE">
<t>The Path Computation Element (PCE) defined in <xref
target="RFC4655">RFC4655</xref> is an entity that is capable of
computing a network path or route based on a network graph, and
applying computational constraints. A Path Computation Client (PCC)
may make requests to a PCE for paths to be computed. The PCE
communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for path computations and is defined
in <xref target="RFC5440">RFC5440</xref>.</t>
<t>The PCEP specification <xref target="RFC5440">RFC5440</xref> is
defined for both IPv4 and IPv6 with support for PCE discovery via an
IGP (OSPF <xref target="RFC5088">RFC5088</xref>, or ISIS <xref
target="RFC5089">RFC5089</xref>) using both IPv4 and IPv6 addresses.
Note that PCEP uses identical encoding of subobjects as in the
Resource Reservation Protocol Traffic Engineering Extensions
(RSVP-TE) defined in <xref target="RFC3209">RFC3209</xref> which
supports both IPv4 and IPv6.</t>
<t>The extensions of PCEP to support confidentiality <xref
target="RFC5520">RFC5520</xref>, Route Exclusion <xref
target="RFC5521">RFC5521,</xref> Monitoring <xref
target="RFC5886">RFC5886</xref>, and P2MP <xref
target="RFC6006">RFC6006</xref> have support for both IPv4 and
IPv6.</t>
</section>
<section title="BGP">
<t><xref target="RFC3107">RFC3107</xref> specifies a set of BGP
protocol procedures for distributing the labels (for prefixes
corresponding to any address-family) between label switch routers so
that they can use the labels for forwarding the traffic. RFC3107
allows BGP to distribute the label for IPv4 or IPv6 prefix in an
IPv6 only network.</t>
</section>
<section title="GMPLS">
<t><xref target="RFC4558">RFC4558</xref> specifies Node-ID Based
RSVP Hello Messages with capability for both IPv4 and IPv6. <xref
target="RFC4990">RFC4990</xref> clarifies the use of IPv6 addresses
in GMPLS networks including handling in the MIB modules.</t>
</section>
</section>
<section title="MPLS Applications">
<t/>
<section title="L2VPN">
<t>L2VPN <xref target="RFC4664">RFC 4664</xref> specifies two
fundamentally different kinds of Layer 2 VPN services that a service
provider could offer to a customer: Virtual Private Wire Service
(VPWS) and Virtual Private LAN Service (VPLS). <xref
target="RFC4447">RFC 4447</xref> and <xref target="RFC4762">RFC
4762</xref> specify the LDP protocol changes to instantiate VPWS and
VPLS services respectively in an MPLS network using LDP as the
signaling protocol. This is complemented by <xref
target="RFC6074">RFC 6074</xref>, which specifies a set of
procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as
discovery protocol and LDP (as well as L2TPv3) as signaling
protocol. <xref target="RFC4761">RFC 4761</xref> and <xref
target="RFC6624">RFC 6624</xref> specify BGP protocol changes to
instantiate VPLS and VPWS services in an MPLS network, using BGP for
both discovery and signaling.</t>
<t>In an IPv6-only MPLS network, use of L2VPN represents connection
of Layer 2 islands over an IPv6 MPLS core, and very few changes are
necessary to support operation over an IPv6-only network. The L2VPN
signaling protocol is either BGP or LDP in an MPLS network, and both
can run directly over IPv6 core infrastructure, as well as IPv6 edge
devices. <xref target="RFC6074">RFC 6074</xref> is the only RFC that
appears to have a gap wrt IPv6. In its discovery procedures (section
3.2.2 and section 6), it suggests encoding PE IP address in the
VSI-ID, which is encoded in NLRI, which should not exceed 12 bytes
(to differentiate its AFI/SAFI encoding from RFC4761). This means
that PE IP address can NOT be an IPv6 address. Also, in its
signaling procedures (section 3.2.3), it suggests encoding PE_addr
in SAII and TAII, which are limited to 32-bit (AII Type=1) at the
moment.</t>
<section title="EVPN">
<t><xref target="I-D.ietf-l2vpn-evpn">EVPN</xref> is still a work
in progress. As such, it is out of scope for this gap analysis.
Instead, the authors of that draft need to ensure that it supports
IPv6-only operation, or if it cannot, identify dependencies on
underlying gaps in MPLS protocol(s) that must be resolved before
it can support IPv6-only operation.</t>
</section>
</section>
<section title="L3VPN">
<t><xref target="RFC4364">RFC 4364</xref> defines a method by which
a Service Provider may use an IP backbone to provide IP Virtual
Private Networks (VPNs) for its customers. The following use cases
arise in the context of this gap analysis:<list style="numbers">
<t>Connecting IPv6 islands over IPv6-only MPLS network</t>
<t>Connecting IPv4 islands over IPv6-only MPLS network</t>
</list></t>
<t>Both use cases 1 and 2 require mapping an IP packet to an
IPv6-signaled LSP to the remote PE, which is not explicitly defined
in any RFC. RFC4364 has two MAJOR gaps. First, it is not possible to
use an IPv6-only MPLS network, since RFC4364 explicitly assumes
IPv4-only MPLS network i.e. BGP Next Hop is assumed to have /32 (for
example, see section 5 of RFC4364]. Second, it is limited to
VPN-IPv4 address-family i.e. connecting IPv4 islands over IPv4-only
MPLS networks. This second gap has been fixed by 6VPE <xref
target="RFC4659">RFC 4659</xref>, which defines connecting IPv6 VPN
sites over an IPv4-only MPLS networks, but more work is needed to
address the first gap.</t>
<t>The authors do not believe that there are any additional issues
encountered when using L2TPv3, RSVP, or GRE (instead of LDP) as
transport on an IPv6-only network.</t>
<section title="6PE/4PE">
<t><xref target="RFC4798">RFC 4798</xref> defines 6PE, which
defines how to interconnect IPv6 islands over a Multiprotocol
Label Switching (MPLS)-enabled IPv4 cloud. However, use case 2 is
doing the opposite, and thus could also be referred to as 4PE. The
method to support this use case is not defined explicitly. To
support it, IPv4 edge devices need to be able to map IPv4 traffic
to MPLS IPv6 core LSP's. Also, the core switches may not
understand IPv4 at all, but in some cases they may need to be able
to exchange Labeled IPv4 routes from one AS to a neighboring
AS.</t>
</section>
<section title="6VPE/4VPE">
<t><xref target="RFC4659">RFC 4659</xref> defines 6VPE, a method
by which a Service Provider may use its packet-switched backbone
to provide Virtual Private Network (VPN) services for its IPv6
customers. It allows the core network to be MPLS IPv4 or MPLS
IPv6, thus addressing use case 1 above. RFC4364 should work as
defined for use case 2 above, which could also be referred to as
4VPE, but the RFC does not explicitly discuss this use.</t>
</section>
<section title="NG-MVPN">
<t>***TBD [RFC6513] both IPv4 and IPv6 multicast payload
traffic***</t>
<t>No IP version considerations?</t>
</section>
</section>
<section title="MPLS-TP">
<t>***TBD RFC 6371 *** MPLS-TP does not require IP ("and network
operation in the absence of a dynamic > control plane or IP
forwarding support." [RFC 5921]) and thus should not be affected by
operation on an IPv6-only network.</t>
</section>
</section>
<section title="MPLS OAM">
<t>For MPLS LSPs, there are primarily three OAM mechanisms: Extended
ICMP <xref target="RFC4884">RFC 4884</xref> <xref target="RFC4950">RFC
4950</xref>, LSP Ping <xref target="RFC4379">RFC 4379</xref>, and BFD
for MPLS LSPs <xref target="RFC5884">RFC 5884</xref>. For MPLS
Pseudowires, there is also Virtual Circuit Connectivity Verification
(VCCV) <xref target="RFC5085">RFC 5085</xref> <xref
target="RFC5885">RFC 5885</xref>. All of these mechanisms work in pure
IPv6 environments. The next subsections cover these in detail.</t>
<section title="Extended ICMP">
<t>Extended ICMP to support Multi-part messages is defined in <xref
target="RFC4884">RFC 4884</xref>. This extensibility is defined
generally for both ICMPv4 and ICMPv6. The specific ICMP extensions
for MPLS are defined in <xref target="RFC4950">RFC 4950</xref>. ICMP
Multi-part with MPLS extensions works for IPv4 and IPv6. However,
the mechanisms described in RFC 4884 and 4950 may fail when
tunneling IPv4 traffic over an LSP that is supported by IPv6-only
infrastructure.</t>
<t>Assume the following: <list style="symbols">
<t>the path between two IPv4 only hosts contains an MPLS LSP</t>
<t>the two routers that terminate the LSP run dual stack</t>
<t>the LSP interior routers run IPv6 only</t>
<t>the LSP is signaled over IPv6</t>
</list></t>
<t>Now assume that one of the hosts sends an IPv6 packet to the
other. However, the packet’s TTL expires on an LSP interior
router. According to <xref target="RFC3032">RFC 3032</xref>, the
interior router should examine the IPv6 payload, format an ICMPv6
message, and send it (over the tunnel upon which the original packet
arrived) to the egress LSP. In this case, however, the LSP interior
router is not IPv6-aware. It cannot parse the original IPv6
datagram, nor can it send an IPv6 message. So, no ICMP message is
delivered to the source. Some specific ICMP extensions, in
particular ICMP Extensions for Interface and Next-Hop Identification
<xref target="RFC5837">RFC 5837</xref> restrict the address family
of address information included in an Interface Information Object
to the same one as the ICMP (see Section 4.5 of RFC 5837). While
these extensions are not MPLS specific, they can be used with MPLS
packets carrying IP datagrams. This has no implications for
IPv6-only environments.</t>
</section>
<section title="LSP Ping">
<t>The LSP Ping mechanism defined in <xref target="RFC4379">RFC
4379</xref> is specified to work with IPv6. Specifically, the Target
FEC Stacks include both IPv4 and IPv6 versions of all FECs (see
Section 3.2 of RFC 4379). The only exceptions are the Pseudowire
FECs later specified for IPv6 in <xref target="RFC6829">RFC
6829</xref>. Additionally, LSP Ping packets are UDP packets over
both IPv4 and IPv6 (see Section 4.3 of RFC 4379). The multipath
information includes also IPv6 encodings (see Section 3.3.1 of RFC
4379). However, the mechanisms described in RFC 4379 may fail when
tunneling IPv4 traffic over an LSP that is supported by IPv6-only
infrastructure.</t>
<t>Assume the following: <list style="symbols">
<t>LSP Ping is operating in traceroute mode over an MPLS LSP</t>
<t>the two routers that terminate the LSP run dual stack</t>
<t>the LSP interior routers run IPv6 only</t>
<t>the LSP is signaled over IPv6</t>
</list></t>
<t>Packets will expire at LSP interior routers. According to RFC
4379, the interior router must parse the IPv4 Echo Request, and
then, send an IPv4 Echo Reply. However, the LSP interior router is
not IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it
send an IPv4 Echo Reply. So, no reply is sent.</t>
</section>
<section title="BFD">
<t>The BFD specification for MPLS LSPs <xref target="RFC5884">RFC
5884</xref> is defined for IPv4 as well as IPv6 versions of MPLS
FECs (see Section 3.1 of RFC 5884). Additionally the BFD packet is
encapsulated over UDP and specified to run over both IPv4 and IPv6
(see Section 7 of RFC 5884).</t>
</section>
<section title="Pseudowires">
<t>The OAM specifications for MPLS Pseudowires define usage for both
IPv4 and IPv6. Specifically, VCCV <xref target="RFC5085">RFC
5085</xref> can carry IPv4 or IPv6 OAM packets (see Section 5.1.1
and 5.2.1 of RFC 5085), and VCCV for BFD <xref target="RFC5885">RFC
5885</xref> also defines an IPv6 encapsulation (see Section 3.2 of
RFC 5885).</t>
</section>
<section title="MPLS-TP OAM">
<t>*** TBD***</t>
</section>
</section>
<section title="MIBs">
<t><xref target="RFC3811">RFC3811</xref> defines the textual
conventions for MPLS. These lack support for IPv6 in defining
MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions
are used in the MPLS TE MIB specification <xref
target="RFC3812">RFC3812</xref>, GMPLS TE MIB specification <xref
target="RFC4802">RFC4802</xref> and Fast ReRoute (FRR) extension <xref
target="RFC6445">RFC6445</xref>. <xref
target="I-D.manral-mpls-rfc3811bis">3811bis</xref> tries to resolve
this gap by marking this textual convention as obsolete.</t>
<t>The other MIB specifications for LSR <xref
target="RFC3813">RFC3813</xref>, LDP <xref
target="RFC3815">RFC3815</xref> and TE <xref
target="RFC4220">RFC4220</xref> have support for both IPv4 and
IPv6.</t>
</section>
</section>
<section title="Gap Summary">
<t>This draft has reviewed a wide variety of MPLS features and protocols
to determine their suitability for use on IPv6-only networks. While some
parts of the MPLS suite will function properly without additional
changes, gaps have been identified in others, which will need to be
addressed with follow-on work. This section will summarize those gaps,
along with pointers to any work-in-progress to address them.</t>
<texttable anchor="table_gap" title="IPv6-only MPLS Gaps">
<preamble>Identifed gaps in MPLS for IPv6-only networks</preamble>
<ttcol align="center">Item</ttcol>
<ttcol align="center">Gap</ttcol>
<ttcol align="center">Addressed in</ttcol>
<c>LDP</c>
<c>LSP mapping, LDP identifiers, LDP discovery, LDP session
establishment, next hop address and LDP TTL security</c>
<c><xref target="I-D.ietf-mpls-ldp-ipv6">LDP-IPv6</xref></c>
<c>L2VPN</c>
<c><xref target="RFC6074">RFC 6074</xref> discovery, signaling</c>
<c>TBD</c>
<c>L3VPN</c>
<c><xref target="RFC4364">RFC 4364</xref> BGP next-hop, define method
for 4PE/4VPE</c>
<c>TBD</c>
<c>MIBs</c>
<c><xref target="RFC3811">RFC 3811</xref> no IPv6 textual
convention</c>
<c><xref target="I-D.manral-mpls-rfc3811bis">3811bis</xref></c>
<postamble/>
</texttable>
<t/>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This draft is brought to you by the letters I, P, V, and the number
6.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Changing the address family used for MPLS network operation does not
fundamentally alter the security considerations currently extant in any
of the specifics of the protocol or its features. However, the change
does expose the network and protocol to some of the IPv6-specific
security considerations inherent to IPv6 itself as documented in [list
of RFCs?]</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1918;
&RFC3032;
&RFC3107;
&RFC3209;
&RFC3630;
&RFC3811;
&RFC3812;
&RFC3813;
&RFC3815;
&RFC4023;
&RFC4090;
&RFC4220;
&RFC4364;
&RFC4379;
&RFC4447;
&RFC4558;
&RFC4664;
&RFC4655;
&RFC4659;
&RFC4761;
&RFC4762;
&RFC4798;
&RFC4802;
&RFC4817;
&RFC4884;
&RFC4875;
&RFC4950;
&RFC4990;
&RFC5036;
&RFC5082;
&RFC5085;
&RFC5088;
&RFC5089;
&RFC5268;
&RFC5305;
&RFC5329;
&RFC5420;
&RFC5837;
&RFC5440;
&RFC5520;
&RFC5521;
&RFC5884;
&RFC5886;
&RFC6006;
&RFC6074;
&RFC6119;
&RFC6388;
&RFC6445;
&RFC5885;
&RFC6512;
&RFC6540;
&RFC6624;
&RFC6829;
&I-D.ietf-mpls-ldp-ipv6;
&I-D.ietf-l2vpn-evpn;
&I-D.manral-mpls-rfc3811bis;
</references>
<section anchor="app-additional" title="Assignments">
<t>*RFC EDITOR PLEASE REMOVE BEFORE PUBLISHING*</t>
<t>This will track which author volunteered for which section(s):</t>
<t>OAM - Ron Bonica, Carlos Pignataro</t>
<t>LDP/mLDP (multicast) - Kamran Raza</t>
<t>L2VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja</t>
<t>L3VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja</t>
<t>PCE - Dhruv Dhody, Rajiv Papneja</t>
<t>Editors- Wes George(primary), Vishwas Manral, Rajiv Asati</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:27:03 |