draft-ietf-mpls-ipv6-only-gap-00.txt   draft-ietf-mpls-ipv6-only-gap-01.txt 
MPLS W. George, Ed. MPLS W. George, Ed.
Internet-Draft Time Warner Cable Internet-Draft Time Warner Cable
Intended status: Informational C. Pignataro, Ed. Intended status: Informational C. Pignataro, Ed.
Expires: October 19, 2014 Cisco Expires: January 24, 2015 Cisco
April 17, 2014 July 23, 2014
Gap Analysis for Operating IPv6-only MPLS Networks Gap Analysis for Operating IPv6-only MPLS Networks
draft-ietf-mpls-ipv6-only-gap-00 draft-ietf-mpls-ipv6-only-gap-01
Abstract Abstract
This document reviews the MPLS protocol suite in the context of IPv6 This document reviews the MPLS protocol suite in the context of IPv6
and identifies gaps that must be addressed in order to allow MPLS- and identifies gaps that must be addressed in order to allow MPLS-
related protocols and applications to be used with IPv6-only related protocols and applications to be used with IPv6-only
networks. This document is not intended to highlight a particular networks. This document is not intended to highlight a particular
vendor's implementation (or lack thereof) in the context of IPv6-only vendor's implementation (or lack thereof) in the context of IPv6-only
MPLS functionality, but rather to focus on gaps in the standards MPLS functionality, but rather to focus on gaps in the standards
defining the MPLS suite. defining the MPLS suite.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2014. This Internet-Draft will expire on January 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 41 skipping to change at page 8, line 41
3.3.1. L2VPN 3.3.1. L2VPN
L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds
of Layer 2 VPN services that a service provider could offer to a of Layer 2 VPN services that a service provider could offer to a
customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN
Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify
the LDP protocol changes to instantiate VPWS and VPLS services the LDP protocol changes to instantiate VPWS and VPLS services
respectively in an MPLS network using LDP as the signaling protocol. respectively in an MPLS network using LDP as the signaling protocol.
This is complemented by RFC 6074 [RFC6074], which specifies a set of This is complemented by RFC 6074 [RFC6074], which specifies a set of
procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as
discovery protocol and LDP as well as L2TPv3 as signaling protocol. discovery protocol and LDP as well as L2TPv3 as signaling protocol.
RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol
changes to instantiate VPLS and VPWS services in an MPLS network, changes to instantiate VPLS and VPWS services in an MPLS network,
using BGP for both discovery and signaling. using BGP for both discovery and signaling.
In an IPv6-only MPLS network, use of L2VPN represents connection of 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 Layer 2 islands over an IPv6 MPLS core, and very few changes are
necessary to support operation over an IPv6-only network. The L2VPN necessary to support operation over an IPv6-only network. The L2VPN
signaling protocol is either BGP or LDP in an MPLS network, and both 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 can run directly over IPv6 core infrastructure, as well as IPv6 edge
skipping to change at page 10, line 12 skipping to change at page 10, line 12
updated to explicitly cover use case #2. (Discussed in further updated to explicitly cover use case #2. (Discussed in further
detail below) detail below)
3.3.2.1. 6PE/4PE 3.3.2.1. 6PE/4PE
RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect
IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4
cloud. However, use case 2 is doing the opposite, and thus could 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 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 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 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 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 need to be able to exchange Labeled IPv4 routes from one AS to a
neighboring AS. neighboring AS.
Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is
currently not specified in an RFC. currently not specified in an RFC.
3.3.2.2. 6VPE/4VPE 3.3.2.2. 6VPE/4VPE
RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider
skipping to change at page 13, line 37 skipping to change at page 13, line 37
IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). 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 The only exceptions are the Pseudowire FECs later specified for IPv6
in RFC 6829 [RFC6829]. in RFC 6829 [RFC6829].
The multipath information includes also IPv6 encodings (see The multipath information includes also IPv6 encodings (see
Section 3.3.1 of RFC 4379). Section 3.3.1 of RFC 4379).
RFC 4379 does not define the value to be used in the IPv6 Router 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, 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 there is no equivalent value for IPv6 RAO. This gap needs to be
fixed to be able to use LSP Ping in IPv6 networks. fixed to be able to use LSP Ping in IPv6 networks. Further details
on this gap are captured, along with a proposed solution, in
[I-D.raza-mpls-oam-ipv6-rao].
Additionally, LSP Ping packets are UDP packets over both IPv4 and Additionally, LSP Ping packets are UDP packets over both IPv4 and
IPv6 (see Section 4.3 of RFC 4379). However, for IPv6, the IPv6 (see Section 4.3 of RFC 4379). However, for IPv6, the
destination IP address is a (randomly chosen) IPv6 address from 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 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 address. This is a transitional mechanism that should not bleed into
IPv6-only networks, as [I-D.itojun-v6ops-v4mapped-harmful] explains. IPv6-only networks, as [I-D.itojun-v6ops-v4mapped-harmful] explains.
The issue is that the MPLS LSP Ping mechanism needs a range of The issue is that the MPLS LSP Ping mechanism needs a range of
loopback IP addresses to be used as destination addresses to exercise loopback IP addresses to be used as destination addresses to exercise
ECMPs, but the IPv6 address architecture specifies a single address ECMPs, but the IPv6 address architecture specifies a single address
skipping to change at page 16, line 27 skipping to change at page 16, line 27
| GMPLS | RFC6370 [RFC6370] Node | TBD | | GMPLS | RFC6370 [RFC6370] Node | TBD |
| S.3.2.6 | ID derivation | | | S.3.2.6 | ID derivation | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| L2VPN | RFC 6074 [RFC6074] | TBD | | L2VPN | RFC 6074 [RFC6074] | TBD |
| S.3.3.1 | discovery, signaling | | | S.3.3.1 | discovery, signaling | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| L3VPN | RFC 4364 [RFC4364] BGP | TBD | | L3VPN | RFC 4364 [RFC4364] BGP | TBD |
| S.3.3.2 | next-hop, define method | | | S.3.3.2 | next-hop, define method | |
| | for 4PE/4VPE | | | | for 4PE/4VPE | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| OAM | RFC 4379 [RFC4379] no | TBD | | OAM | RFC 4379 [RFC4379] no | IPv6 RAO for MPLS OAM |
| S.3.4 | IPv6 multipath support, | | | S.3.4 | IPv6 multipath support, | [I-D.raza-mpls-oam-ipv6-rao] |
| | possible dropped | | | | no IPv6 RAO, possible | |
| | messages in IP version | | | | dropped messages in IP | |
| | mismatch | | | | version mismatch | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| MIBs | RFC 3811 [RFC3811] no | 3811bis | | MIBs | RFC 3811 [RFC3811] no | 3811bis |
| S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | | S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
Table 1: IPv6-only MPLS Gaps Table 1: IPv6-only MPLS Gaps
5. Acknowledgements 5. Acknowledgements
The authors wish to thank Andrew Yourtchenko, Loa Andersson, David The authors wish to thank Andrew Yourtchenko, Loa Andersson, David
skipping to change at page 18, line 27 skipping to change at page 18, line 27
Changing the address family used for MPLS network operation does not Changing the address family used for MPLS network operation does not
fundamentally alter the security considerations currently extant in fundamentally alter the security considerations currently extant in
any of the specifics of the protocol or its features. any of the specifics of the protocol or its features.
9. Informative References 9. Informative References
[I-D.ietf-l2vpn-evpn] [I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-06 (work in progress), March 2014. evpn-07 (work in progress), May 2014.
[I-D.ietf-l3vpn-mvpn-mldp-nlri] [I-D.ietf-l3vpn-mvpn-mldp-nlri]
Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP
FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf-
l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013. l3vpn-mvpn-mldp-nlri-05 (work in progress), May 2014.
[I-D.ietf-l3vpn-mvpn-pe-ce] [I-D.ietf-l3vpn-mvpn-pe-ce]
Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE-
CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-01 (work in CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-01 (work in
progress), March 2014. progress), March 2014.
[I-D.ietf-mpls-ldp-ipv6] [I-D.ietf-mpls-ldp-ipv6]
Asati, R., Manral, V., Papneja, R., and C. Pignataro, Asati, R., Manral, V., Papneja, R., and C. Pignataro,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-12 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-12
(work in progress), February 2014. (work in progress), February 2014.
skipping to change at page 19, line 11 skipping to change at page 19, line 11
Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire
Considered Harmful", draft-itojun-v6ops-v4mapped- Considered Harmful", draft-itojun-v6ops-v4mapped-
harmful-02 (work in progress), October 2003. harmful-02 (work in progress), October 2003.
[I-D.manral-mpls-rfc3811bis] [I-D.manral-mpls-rfc3811bis]
Manral, V., Tsou, T., Will, W., and F. Fondelli, Manral, V., Tsou, T., Will, W., and F. Fondelli,
"Definitions of Textual Conventions (TCs) for "Definitions of Textual Conventions (TCs) for
Multiprotocol Label Switching (MPLS) Management", draft- Multiprotocol Label Switching (MPLS) Management", draft-
manral-mpls-rfc3811bis-03 (work in progress), June 2013. manral-mpls-rfc3811bis-03 (work in progress), June 2013.
[I-D.raza-mpls-oam-ipv6-rao]
Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert
Option for MPLS OAM", draft-raza-mpls-oam-ipv6-rao-00
(work in progress), July 2014.
[I-D.smith-v6ops-larger-ipv6-loopback-prefix] [I-D.smith-v6ops-larger-ipv6-loopback-prefix]
Smith, M., "A Larger Loopback Prefix for IPv6", draft- Smith, M., "A Larger Loopback Prefix for IPv6", draft-
smith-v6ops-larger-ipv6-loopback-prefix-04 (work in smith-v6ops-larger-ipv6-loopback-prefix-04 (work in
progress), February 2013. progress), February 2013.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
 End of changes. 10 change blocks. 
14 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/