One document matched: draft-ietf-mpls-ipv6-only-gap-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: draft-george-mpls-ipv6-only-gap-01.xml 2743 2013-07-12 12:13:37Z carlos $ -->
<!-- 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 RFC6073 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6073.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 RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.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 RFC5921 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5921.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 RFC6370 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6370.xml">
<!ENTITY RFC6371 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6371.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 RFC5512 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5512.xml">
<!ENTITY RFC5640 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5640.xml">
<!ENTITY RFC6513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY RFC6514 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC6720 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6720.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">
<!ENTITY I-D.v4mapped-harmful SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.itojun-v6ops-v4mapped-harmful.xml">
<!ENTITY I-D.larger-ipv6-loopback-prefix SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.smith-v6ops-larger-ipv6-loopback-prefix.xml">
<!ENTITY I-D.ietf-opsec-lla-only SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-lla-only.xml">
<!ENTITY I-D.ietf-l3vpn-mvpn-pe-ce SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l3vpn-mvpn-pe-ce.xml">
<!ENTITY I-D.ietf-l3vpn-mvpn-mldp-nlri SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l3vpn-mvpn-mldp-nlri.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="no" ?>
<!-- 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-ietf-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" role="editor"
surname="Pignataro">
<organization abbrev="Cisco">Cisco Systems, Inc.</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>+1-919-392-7428</phone>
<email>cpignata@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date/>
<!-- 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>MPLS</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>MPLS, LDP, IPv6, RSVP, L3VPN, L2VPN</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
referred 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
Multi-Protocol Label Switching (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>
<!--
As a gap analysis, might not have 2119 words; at least it does not have now.
<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>This section discusses some drivers for ensuring that MPLS completely
supports IPv6-only operation. It is not intended to be a comprehensive
discussion of all potential use cases, but rather a discussion of at
least one use case to provide context and justification to undertake
such a gap analysis.</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. As the number of devices to manage increases, the operator is
compelled to move to IPv6. Depending on the MPLS features required, it
is plausible to assume that the (existing) MPLS network will need to be
extended to these IPv6-only devices.</t>
<t>Additionally, as the impact of IPv4 exhaustion becomes more acute,
more and more aggressive IPv4 address reclamation measures will be
justified. Many networks are likely to focus on preserving their
remaining IPv4 addresses 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
baseline assumption for this analysis is that some endpoints as well as
Label Switch Routers (PE and P routers) 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 Label
Distribution Protocol (LDP) <xref target="RFC5036">RFC 5036</xref>,
Resource Reservation Protocol Extensions for MPLS Traffic Engineering
(RSVP-TE) <xref target="RFC3209">RFC 3209</xref>, or Border Gateway
Protocol (BGP) <xref target="RFC3107">RFC 3107</xref>, and whether they
are encapsulated in MPLS <xref target="RFC3032">RFC 3032</xref>, IP
<xref target="RFC4023">RFC 4023</xref>, Generic Routing Encapsulation
(GRE) <xref target="RFC4023">RFC 4023</xref>, or Layer 2 Tunneling
Protocol Version 3 (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 Data Plane">
<t>MPLS labeled packets can be transmitted over a variety of data
links <xref target="RFC3032">RFC 3032</xref>, and MPLS labeled packets
can also be encapsulated over IP. The encapsulations of MPLS in IP and
GRE as well as MPLS over L2TPv3 support IPv6. See Section 3 of <xref
target="RFC4023">RFC 4023</xref> and Section 2 of <xref
target="RFC4817">RFC 4817</xref> respectively.</t>
<t>In the case where an IPv4 prefix is resolved over an IPv6 LSP, an
IPv6 Explicit Null label cannot immediately preceed an IPv4
packet.</t>
<t>Gap: None.</t>
</section>
<section title="MPLS Control Plane">
<t/>
<section anchor="LDP" 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> and <xref
target="RFC6720">RFC 6720</xref>.</t>
<t>Gap: Major, update to RFC 5036 in progress that should close this
gap.</t>
</section>
<section title="Multipoint 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 if an MP LSP traverses
IPv4-only and IPv6-only nodes in a dual-stack network 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>
<t>Gap: Major, update in progress for LDP via <xref
target="I-D.ietf-mpls-ldp-ipv6">LDP-IPv6</xref>, may need additional
updates to 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>
<t>Gap: None</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>
<t>Gap: None</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>
<t>Gap: None</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="RFC5286">RFC5286</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>
<t>Gap: None</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>
<t>Gap: None.</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>
<t>Gap: None.</t>
</section>
<section anchor="GMPLS" 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>
<t>Section 5.3, second paragraph of <xref
target="RFC6370">RFC6370</xref> describes the mapping from an
MPLS-TP LSP_ID to RSVP-TE with an assumption that Node_IDs are
derived from valid IPv4 addresses. This assumption fails in an
IPv6-only network, given that there wouldn’t be any IPv4
addresses.</t>
<t>Gap: Minor; Section 5.3. of RFC6370 needs to be updated.</t>
</section>
</section>
<section title="MPLS Applications">
<t/>
<section anchor="L2VPN" 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 for IPv6-only operation. 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, and 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>
<t><xref target="RFC6073">RFC 6073</xref> defines the new LDP PW
Switching Point PE TLV, which supports IPv4 and IPv6.</t>
<t>Gap: Minor. RFC6074 needs to be updated.</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 anchor="L3VPN" 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 require mapping an IP packet to an IPv6-signaled
LSP. RFC4364 defines a VPN-IPv4 address family, but not a VPN-IPv6
address family. <xref target="RFC4659">RFC 4659</xref> corrects this
oversight. Also, Section 5 of <xref target="RFC4364">RFC 4364</xref>
assumes that the BGP next-hop contains exactly 32 bits. This text
should be generalized to include 128 bit next-hops as well. Section
3.2.1.1 of <xref target="RFC4659">RFC 4659</xref> does actually
specifies a 128-bit BGP next-hop.</t>
<t>The authors do not believe that there are any additional issues
encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as
transport on an IPv6-only network.</t>
<t>Gap: Major. RFC4364 must be updated, and RFC4659 may need to be
updated to explicitly cover use case #2. (Discussed in further
detail below)</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>
<t>Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is
currently not specified in an RFC.</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>
<t>Gap: Minor. RFC4659 may need to be updated to explicitly cover
use case #2</t>
</section>
<section title="BGP Encapsulation SAFI">
<t><xref target="RFC5512">RFC 5512</xref> defines the BGP
Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute,
which can be used to signal tunneling over a single-Address Family
IP core. This mechanism supports transport of MPLS (and other
protocols) over Tunnels in an IP core (including an IPv6-only
core). In this context, load-balancing can be provided as
specified in <xref target="RFC5640">RFC 5640</xref>.</t>
<t>Gap: None.</t>
</section>
<section title="NG-MVPN">
<t><xref target="RFC6513">RFC 6513</xref> defines the procedure to
provide multicast service over MPLS VPN backbone for the
customers. The procedure involves the below set of protocols:</t>
<section title="PE-CE Multicast Routing Protocol">
<t><xref target="RFC6513">RFC 6513</xref> explains the use of
PIM as PE-CE protocol while Section 11.1.2 of <xref
target="RFC6514">RFC 6514</xref> explains the use of mLDP as
PE-CE protocol.</t>
<t>The MCAST-VPN NLRI route-type format defined in <xref
target="RFC6514">RFC 6514</xref> is not sufficiently covering
all scenarios when mLDP is used as PE-CE protocol. The issue is
explained in section 2 of <xref
target="I-D.ietf-l3vpn-mvpn-mldp-nlri"/> along with new
route-type that encodes the mLDP FEC in NLRI.</t>
<t>Further <xref target="I-D.ietf-l3vpn-mvpn-pe-ce"/> defines
the use of BGP as PE-CE protocol.</t>
<t>Gap: None.</t>
</section>
<section title="P-Tunnel Instantiation">
<t><xref target="RFC6513">RFC 6513</xref> explains the use of
the below tunnels: <list style="symbols">
<t>RSVP-TE P2MP LSP</t>
<t>PIM Tree</t>
<t>mLDP P2MP LSP</t>
<t>mLDP MP2MP LSP</t>
<t>Ingress Replication</t>
</list></t>
<t>Gap: Gaps in RSVP-TE P2MP LSP and mLDP P2MP and MP2MP LSP are
covered in previous sections.</t>
<t>PIM Tree and Ingress Replication are out of the scope of this
document.</t>
</section>
<section title="PE-PE Multicast Routing Protocol">
<t>Section 3.1 of <xref target="RFC6513">RFC 6513</xref>
explains the use of PIM as PE-PE protocol while <xref
target="RFC6514">RFC 6514</xref> explains the use of BGP as
PE-PE protocol.</t>
<t>Gap: Any gaps in PIM or BGP as PE-PE Multicast Routing
protocol are outside the scope of this document</t>
</section>
</section>
</section>
<section title="MPLS-TP">
<t>MPLS-TP does not require IP (see section 2 of <xref
target="RFC5921">RFC 5921</xref>) and should not be affected by
operation on an IPv6-only network. Therefore this is considered out
of scope for this document.</t>
<t>Gap: None.</t>
</section>
</section>
<section anchor="OAM" 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>
<t>Gap: Major. RFC4379 needs to be updated for multipath IPv6.
Additionally, there is potential for dropped messages in Extended ICMP
and LSP ping due to IP version mismatches. It is important to note
that this is a more generic problem with tunneling when IP address
family mismatches exist, and is not specific to MPLS, so while MPLS
will be affected, it will be difficult to fix this problem
specifically for MPLS, rather than fixing the more generic
problem.</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 IPv4 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 IPv4 payload, format an ICMPv4
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 IPv4-aware. It cannot parse the original IPv4
datagram, nor can it send an IPv4 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>
<t>Gap: Major. IP version mismatches may cause dropped messages.
However, as noted in the previous section, this problem is not
specific to MPLS.</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>.</t>
<t>The multipath information includes also IPv6 encodings (see
Section 3.3.1 of RFC 4379).</t>
<t>RFC 4379 does not define the value to be used in the IPv6 Router
Alert option (RAO). For IPv4 RAO, a value of zero is used. However,
there is no equivalent value for IPv6 RAO. This gap needs to be
fixed to be able to use LSP Ping in IPv6 networks.</t>
<t>Additionally, LSP Ping packets are UDP packets over both IPv4 and
IPv6 (see Section 4.3 of RFC 4379). However, for IPv6, the
destination IP address is a (randomly chosen) IPv6 address from the
range 0:0:0:0:0:FFFF:127/104. That is, using an IPv4-mapped IPv6
address. This is a transitional mechanism that should not bleed into
IPv6-only networks, as <xref
target="I-D.itojun-v6ops-v4mapped-harmful"/> explains. The issue is
that the MPLS LSP Ping mechanism needs a range of loopback IP
addresses to be used as destination addresses to exercise ECMPs, but
the IPv6 address architecture specifies a single address (::1/128)
for loopback. A mechanism to achieve this was proposed in <xref
target="I-D.smith-v6ops-larger-ipv6-loopback-prefix"/>.</t>
<t>Another gap is that 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>
<t>The mechanism described in RFC 4379 also does not sufficiently
explain the behaviour in certain IPv6-specific scenarios. For
example, RFC 4379 defines the K value as 28 octets when Address
Family is set to IPv6 Unnumbered, but it doesn't describe how to
carry a 32 bit LSR Router ID in the 128 bit Downstream IP Address
Field.</t>
<t>Gap: Major. LSP ping uses IPv4-mapped IPv6 addresses, IP version
mismatches may cause dropped messages, unclear mapping from LSR
Router ID to Downstream IP Address.</t>
</section>
<section title="BFD OAM">
<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>
<t>Gap: None.</t>
</section>
<section title="Pseudowire OAM">
<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>
<t>Additionally, for LSP Ping for Pseudowires, the Pseudowire FECs
are specified for IPv6 in <xref target="RFC6829">RFC
6829</xref>.</t>
<t>Gap: None.</t>
</section>
<section title="MPLS-TP OAM">
<t>As with MPLS-TP, MPLS-TP OAM <xref target="RFC6371">RFC
6371</xref> is not dependent on IP or existing MPLS OAM functions,
and should not be affected by operation on an IPv6-only network.
Therefore, this is out of scope for this document.</t>
<t>Gap: None.</t>
</section>
</section>
<section anchor="MIBs" 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>
<t>Gap: Major. Work underway to update RFC3811, may also need to
update RFC3812, RFC4802, and RFC6445, which depend on it.</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" style="all" 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 S.<xref format="counter" target="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>GMPLS S.<xref format="counter" target="GMPLS"/></c>
<c><xref target="RFC6370">RFC6370</xref> Node ID derivation</c>
<c>TBD</c>
<c>L2VPN S.<xref format="counter" target="L2VPN"/></c>
<c><xref target="RFC6074">RFC 6074</xref> discovery, signaling</c>
<c>TBD</c>
<c>L3VPN S.<xref format="counter" target="L3VPN"/></c>
<c><xref target="RFC4364">RFC 4364</xref> BGP next-hop, define method
for 4PE/4VPE</c>
<c>TBD</c>
<c>OAM S.<xref format="counter" target="OAM"/></c>
<c><xref target="RFC4379">RFC 4379</xref> no IPv6 multipath support,
possible dropped messages in IP version mismatch</c>
<c>TBD</c>
<c>MIBs S.<xref format="counter" target="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>The authors wish to thank Andrew Yourtchenko, Loa Andersson, David
Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their detailed
reviews, as well as Brian Haberman, Joel Jaeggli, Adrian Farrell, and
Nobo Akiya for their comments.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section title="Contributing Authors">
<t>The following people have contributed text to this draft:</t>
<?rfc subcompact="yes" ?>
<t><list style="empty">
<t>Rajiv Asati</t>
<t>Cisco Systems</t>
<t>7025 Kit Creek Road</t>
<t>Research Triangle Park, NC 27709</t>
<t>US</t>
<t/>
<t>Email: rajiva@cisco.com</t>
<t/>
<t/>
<t>Kamran Raza</t>
<t>Cisco Systems</t>
<t>2000 Innovation Drive</t>
<t>Ottawa, ON K2K-3E8</t>
<t>CA</t>
<t/>
<t>Email: skraza@cisco.com</t>
<t/>
<t/>
<t>Ronald Bonica</t>
<t>Juniper Networks</t>
<t>2251 Corporate Park Drive</t>
<t>Herndon, VA 20171</t>
<t>US</t>
<t/>
<t>Email: rbonica@juniper.net</t>
<t/>
<t/>
<t>Rajiv Papneja</t>
<t>Huawei Technologies</t>
<t>2330 Central Expressway</t>
<t>Santa Clara, CA 95050</t>
<t>US</t>
<t/>
<t>Email: rajiv.papneja@huawei.com</t>
<t/>
<t/>
<t>Dhruv Dhody</t>
<t>Huawei Technologies</t>
<t>Leela Palace</t>
<t>Bangalore, Karnataka 560008</t>
<t>IN</t>
<t/>
<t>Email: dhruv.ietf@gmail.com</t>
<t/>
<t/>
<t>Vishwas Manral</t>
<t>Ionos Networks </t>
<t>Sunnyvale, CA 94089</t>
<t>US</t>
<t/>
<t>Email: vishwas@ionosnetworks.com</t>
<t/>
<t/>
<t>Nagendra Kumar</t>
<t>Cisco Systems, Inc.</t>
<t>7200 Kit Creek Road</t>
<t>Research Triangle Park, NC 27709</t>
<t>US</t>
<t/>
<t>Email: naikumar@cisco.com</t>
<t/>
</list></t>
<?rfc subcompact="no" ?>
</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.</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/... ).-->
<!--
Nothing here until a 2119 word appears
<references title="Normative References">
&RFC2119;
</references>
-->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1918;
&RFC6073;
&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;
&RFC5286;
&RFC5305;
&RFC5329;
&RFC5837;
&RFC5440;
&RFC5520;
&RFC5521;
&RFC5884;
&RFC5886;
&RFC5921;
&RFC6006;
&RFC6074;
&RFC6119;
&RFC6370;
&RFC6371;
&RFC6388;
&RFC6445;
&RFC5885;
&RFC6512;
&RFC6540;
&RFC6624;
&RFC6829;
&RFC5512;
&RFC5640;
&RFC6513;
&RFC6514;
&RFC6720;
&I-D.ietf-mpls-ldp-ipv6;
&I-D.ietf-l2vpn-evpn;
&I-D.manral-mpls-rfc3811bis;
&I-D.v4mapped-harmful;
&I-D.larger-ipv6-loopback-prefix;
&I-D.ietf-l3vpn-mvpn-pe-ce;
&I-D.ietf-l3vpn-mvpn-mldp-nlri;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:59:17 |