summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7506.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7506.txt')
-rw-r--r--doc/rfc/rfc7506.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc7506.txt b/doc/rfc/rfc7506.txt
new file mode 100644
index 0000000..7fa6b34
--- /dev/null
+++ b/doc/rfc/rfc7506.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Raza
+Request for Comments: 7506 Cisco Systems, Inc.
+Updates: 4379 N. Akiya
+Category: Standards Track Big Switch Networks
+ISSN: 2070-1721 C. Pignataro
+ Cisco Systems, Inc.
+ April 2015
+
+
+ IPv6 Router Alert Option
+ for MPLS Operations, Administration, and Maintenance (OAM)
+
+Abstract
+
+ RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute
+ mechanism in which the Router Alert Option (RAO) MUST be set in the
+ IP header of the MPLS Echo Request messages and may conditionally be
+ set in the IP header of the MPLS Echo Reply messages depending on the
+ Reply Mode used. While a generic "Router shall examine packet"
+ Option Value is used for the IPv4 RAO, there is no generic RAO value
+ defined for IPv6 that can be used. This document allocates a new,
+ generic IPv6 RAO value that can be used by MPLS Operations,
+ Administration, and Maintenance (OAM) tools, including the MPLS Echo
+ Request and MPLS Echo Reply messages for MPLS in IPv6 environments.
+ Consequently, it updates RFC 4379.
+
+ The initial motivation to request an IPv6 RAO value for MPLS OAM
+ comes from the MPLS LSP Ping/Traceroute. However, this value is
+ applicable to all MPLS OAM and not limited to MPLS LSP Ping/
+ Traceroute.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7506.
+
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 1]
+
+RFC 7506 MPLS OAM IPv6 Router Alert April 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
+ 3. IPv6 RAO Value for MPLS OAM . . . . . . . . . . . . . . . . . 3
+ 4. Updates to RFC 4379 . . . . . . . . . . . . . . . . . . . . . 3
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 4
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 5
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
+
+1. Introduction
+
+ A commonly deployed MPLS OAM tool is specified in [RFC4379],
+ "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures",
+ which is used to diagnose MPLS network data planes. This
+ specification, often referred to as "MPLS LSP Ping/Traceroute"
+ [RFC4379], requires the use of the Router Alert Option (RAO) in the
+ IP header. For example, Section 4.3 of [RFC4379] states that the IP
+ RAO MUST be set in the IP header of an MPLS Echo Request message.
+ Similarly, Section 4.5 of [RFC4379] states that the IP RAO MUST be
+ set in the IP header of an MPLS Echo Reply message if the Reply Mode
+ in the Echo Request is set to "Reply via an IPv4/IPv6 UDP packet with
+ Router Alert".
+
+ [RFC2113] defines a generic Option Value 0x0 for IPv4 RAO that is
+ used in LSP Ping and LSP Traceroute for MPLS in IPv4 environments.
+ This IPv4 RAO value of 0x0 is assigned to "Router shall examine
+ packet". However, currently there is no generic IPV6 RAO value
+ defined that can be used in LSP Ping and LSP Traceroute for MPLS in
+
+
+
+Raza, et al. Standards Track [Page 2]
+
+RFC 7506 MPLS OAM IPv6 Router Alert April 2015
+
+
+ IPv6 environments. Specifically, [RFC2711] defined the Router Alert
+ for a general IPv6 purpose but required the Value field in the RAO to
+ indicate a specific reason for using the RAO. Because there is no
+ defined value for MPLS LSP Ping/Traceroute use or for general use, it
+ is not possible for MPLS OAM tools to use the IPv6 Router Alert
+ mechanism.
+
+ As vendors are starting to implement MPLS on the IPv6 control plane
+ (e.g., [LDP-IPV6]), there is a need to define and allocate such an
+ Option Value for IPv6 in order to comply with [RFC4379]. This
+ document defines a new IPv6 RAO value that can be used by MPLS OAM
+ tools, including the MPLS Echo Request and MPLS Echo Reply messages
+ for MPLS in IPv6 environments.
+
+ This document closes the gap discussed in the third paragraph of
+ Section 3.4.2 in [RFC7439].
+
+2. Specification of Requirements
+
+ 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 [RFC2119].
+
+3. IPv6 RAO Value for MPLS OAM
+
+ This document defines a new Option Value (69) for the IPv6 RAO to
+ alert transit routers to examine the packet more closely for MPLS OAM
+ purposes. This Option Value is used by any MPLS OAM application that
+ requires their packets to be examined by a transit router.
+
+ In the scope of this document, this Option Value will be used by the
+ MPLS Echo Request and MPLS Echo Reply for its IPv6 messages, as is
+ required by [RFC4379].
+
+4. Updates to RFC 4379
+
+ [RFC4379] specifies the use of the RAO in the IP header. Sections
+ 4.3 and 4.5 of [RFC4379] are updated as follows:
+
+ For every time in which the "Router Alert IP Option" is used, the
+ following text is appended:
+
+ In case of an IPv4 header, the generic IPv4 RAO value 0x0
+ [RFC2113] SHOULD be used. In case of an IPv6 header, the IPv6 RAO
+ value (69) allocated through this document for MPLS OAM MUST be
+ used.
+
+
+
+
+
+Raza, et al. Standards Track [Page 3]
+
+RFC 7506 MPLS OAM IPv6 Router Alert April 2015
+
+
+5. IANA Considerations
+
+ This document defines a new value (69) for the IPv6 RAO to alert
+ transit routers to examine the packet more closely for MPLS OAM
+ purposes. IANA has assigned a new code point under its "IPv6 Router
+ Alert Option Values" registry defined by [RFC2711], updated by
+ [RFC5350], and maintained in [IANA-IPv6-RAO]. The new code point is
+ as follows:
+
+ Value Description Reference
+ ----- ------------------------------- ---------------
+ 69 MPLS OAM RFC 7506
+
+6. Security Considerations
+
+ This document introduces no new security concerns in addition to what
+ have already been captured in [RFC4379] and [RFC6398], the latter of
+ which expands the security considerations of [RFC2113] and [RFC2711].
+
+ IPv6 packets containing the MPLS OAM RAO are encapsulated with an
+ MPLS header and are not expected to be inspected by every label
+ switched hop within an MPLS LSP. Consequently, this value of the RAO
+ will be processed by the appropriate router and is not subject to the
+ problem of being ignored, as described in Section 2.2 of [RFC7045].
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
+ RFC 2711, October 1999,
+ <http://www.rfc-editor.org/info/rfc2711>.
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+ Label Switched (MPLS) Data Plane Failures", RFC 4379,
+ February 2006, <http://www.rfc-editor.org/info/rfc4379>.
+
+ [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the
+ IPv4 and IPv6 Router Alert Options", RFC 5350, September
+ 2008, <http://www.rfc-editor.org/info/rfc5350>.
+
+ [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
+ Usage", BCP 168, RFC 6398, October 2011,
+ <http://www.rfc-editor.org/info/rfc6398>.
+
+
+
+Raza, et al. Standards Track [Page 4]
+
+RFC 7506 MPLS OAM IPv6 Router Alert April 2015
+
+
+7.2. Informative References
+
+ [IANA-IPv6-RAO]
+ IANA, "IPv6 Router Alert Option Values",
+ <http://www.iana.org/assignments/ipv6-routeralert-values>.
+
+ [LDP-IPV6] Asati, R., Pignataro, C., Raza, K., Manral, V., and R.
+ Papneja, "Updates to LDP for IPv6", Work in Progress,
+ draft-ietf-mpls-ldp-ipv6-17, February 2015.
+
+ [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
+ 1997, <http://www.rfc-editor.org/info/rfc2113>.
+
+ [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
+ of IPv6 Extension Headers", RFC 7045, December 2013,
+ <http://www.rfc-editor.org/info/rfc7045>.
+
+ [RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for
+ Operating IPv6-Only MPLS Networks", RFC 7439, January
+ 2015, <http://www.rfc-editor.org/info/rfc7439>.
+
+Acknowledgements
+
+ The authors would like to thank George Swallow, Ole Troan, Bob
+ Hinden, Faisal Iqbal, Mathew Janelle, and Gregory Mirsky for their
+ useful input.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 5]
+
+RFC 7506 MPLS OAM IPv6 Router Alert April 2015
+
+
+Authors' Addresses
+
+ Kamran Raza
+ Cisco Systems, Inc.
+ 2000 Innovation Drive
+ Kanata, ON K2K-3E8
+ Canada
+
+ EMail: skraza@cisco.com
+
+
+ Nobo Akiya
+ Big Switch Networks
+
+ EMail: nobo.akiya.dev@gmail.com
+
+
+ Carlos Pignataro
+ Cisco Systems, Inc.
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States
+
+ EMail: cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 6]
+