RFC 7506

IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)

📅 published April 2015, from ietf

RFC 7506: IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) ✨

okay bestie, let's get into it 🎀 this one's from April 2015 and it's a Standards Track doc, so it's the real deal, not a vibes-only memo 💅 the authors are Kamran Raza (Cisco Systems, Inc.), Nobo Akiya (Big Switch Networks), and Carlos Pignataro (Cisco Systems, Inc.) 👑 it updates RFC 4379 (that's the MPLS LSP Ping/Traceroute one) and it's published as ISSN 2070-1721 🦋

Abstract 🌸

okay so RFC 4379 says the Router Alert Option (RAO) MUST be set in the IP header of MPLS Echo Request messages, and it might be set on Echo Reply messages depending on the Reply Mode 🫶 for IPv4 there's a generic "Router shall examine packet" value, but for IPv6 there was no generic RAO value you could use 💀 this doc allocates a brand new generic IPv6 RAO value that MPLS OAM tools can use, including the Echo Request and Echo Reply for MPLS in IPv6 environments 🧚 so yeah, it updates RFC 4379 ✨

the motivation starts with MPLS LSP Ping/Traceroute, but the value applies to all MPLS OAM, not just that one 🌈 it's giving universal energy 😭

Status of This Memo 💜

this is an Internet Standards Track document 🔥 it's a product of the IETF and it reflects the community's consensus, got public review, and was approved by the IESG ✨ more on Internet Standards is in Section 2 of RFC 5741 🍓

info about the current status, errata, and feedback lives at http://www.rfc-editor.org/info/rfc7506 🎀

Copyright (c) 2015 IETF Trust and the document authors, all rights reserved 💅 this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date, so go read those, they spell out your rights 🫶

if you pull code components out of this doc, they have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in that license 🙈

Table of Contents 🌈

  • 1. Introduction ⭐
  • 2. Specification of Requirements ⭐
  • 3. IPv6 RAO Value for MPLS OAM ⭐
  • 4. Updates to RFC 4379 ⭐
  • 5. IANA Considerations ⭐
  • 6. Security Considerations ⭐
  • 7. References ⭐
    • 7.1. Normative References
    • 7.2. Informative References
  • Acknowledgements
  • Authors' Addresses

1. Introduction 🌸

okay so MPLS OAM has a commonly deployed tool specified in [RFC4379], "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" 🔥 it's used to diagnose MPLS data planes, and it's often called "MPLS LSP Ping/Traceroute" [RFC4379] 💅 that spec requires the Router Alert Option (RAO) in the IP header. Like, Section 4.3 of [RFC4379] says the IP RAO MUST be set on an MPLS Echo Request message 😭 and Section 4.5 says the IP RAO MUST be set on an MPLS Echo Reply message if the Reply Mode in the Echo Request is "Reply via an IPv4/IPv6 UDP packet with Router Alert" 🫶

[RFC2113] defines a generic Option Value 0x0 for the IPv4 RAO, used by LSP Ping and LSP Traceroute for MPLS in IPv4 environments 🧚 that value is assigned to "Router shall examine packet" ✨ but there's currently no generic IPv6 RAO value that LSP Ping and LSP Traceroute can use for MPLS in IPv6 environments 💀 [RFC2711] defined the Router Alert for general IPv6 use, but it needed the Value field to name a specific reason for using the RAO 🙈 since there's no value for MPLS LSP Ping/Traceroute or for general use, MPLS OAM tools just can't use the IPv6 Router Alert mechanism 😭

vendors are starting to run MPLS on the IPv6 control plane (for example, [LDP-IPV6]) 🌈 so we need to define and allocate an Option Value for IPv6 to comply with [RFC4379] 💖 this doc defines that new IPv6 RAO value, usable by MPLS OAM tools including the Echo Request and Echo Reply for MPLS in IPv6 environments 👑

this doc 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 doc are to be read as described in [RFC2119] 🎀 these are the official BCP 14 vibes, so pay attention to them 💅

3. IPv6 RAO Value for MPLS OAM 🍓

this doc defines a new Option Value (69) for the IPv6 RAO that tells transit routers to look at the packet more closely for MPLS OAM purposes ✨ any MPLS OAM app that needs its packets examined by a transit router uses this value 🫶

in scope here, the Echo Request and Echo Reply for their IPv6 messages use this value, because [RFC4379] requires it 🔥

4. Updates to RFC 4379 🌸

[RFC4379] specifies using the RAO in the IP header 🧚 Sections 4.3 and 4.5 of [RFC4379] get updated like this:

every time the "Router Alert IP Option" is used, the following text gets 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.

5. IANA Considerations 🌈

this doc defines a new value (69) for the IPv6 RAO that alerts transit routers to examine the packet more closely for MPLS OAM 💖 IANA assigned a new code point in the "IPv6 Router Alert Option Values" registry, which is defined by [RFC2711], updated by [RFC5350], and maintained in [IANA-IPv6-RAO] 👑 the new code point looks like this:

   Value   Description                       Reference
   -----   -------------------------------   ---------------
      69   MPLS OAM                          RFC 7506

6. Security Considerations 💀

this doc adds no new security concerns beyond what's already covered in [RFC4379] and [RFC6398] 😭 the latter expands on the security considerations of [RFC2113] and [RFC2711] 🙈

IPv6 packets carrying the MPLS OAM RAO get encapsulated with an MPLS header and aren't expected to be inspected by every label switched hop in an MPLS LSP 🦋 so this RAO value is handled by the appropriate router and isn't subject to the problem of being ignored, as described in Section 2.2 of [RFC7045] 🔥

7. References 💅

7.1. Normative References 🫶

7.2. Informative References 🦋

Acknowledgements 🎀

the authors want to thank George Swallow, Ole Troan, Bob Hinden, Faisal Iqbal, Mathew Janelle, and Gregory Mirsky for their useful input 💖 bestie squad goals 👑

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 💜
📦 where this page comes from