Date: Mon, Sep 4, 2023 at 7:30 AM
Subject: Rtgdir last call review of draft-ietf-mpls-lspping-norao-02
To: <rtg-dir@xxxxxxxx>
Cc: <draft-ietf-mpls-lspping-norao.all@xxxxxxxx>, <last-call@xxxxxxxx>, <mpls@xxxxxxxx>
Reviewer: Carlos Pignataro
Review result: Has Issues
Hi,
Please find below the Routing Area Directorate (rtgdir) review for
draft-ietf-mpls-lspping-norao-02. I'll be happy to provide further
clarifications or provide text as appropriate. I hope these are useful and
clear.
More Substantive:
Abstract
The echo request and echo response messages, defined in RFC 8029
"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"
CMP> In the first line, the messages are misnamed. I suggest:
The MPLS echo request and MPLS echo response messages, defined in
RFC 8029 "Detecting MPLS Data-Plane Failures"...
GIM>> Thank you for the suggestion, I agree. These changes applied throughout the document.
CMP> While this might seem, on the surface, an editorial, I feel it
CMP> is important for two main reasons.
CMP> First, the actual name of the messages is "MPLS echo request"
CMP> and "MPLS echo reply".
CMP> Second, as it was discussed during RFC 8029, it disambiguates
CMP> from ICMP homonyms.
The rationale for having an RAO is
questionable.
CMP> As this is the whole justification for this document, I do not
CMP> believe that the "rationale is questionable". Maybe its
CMP> effectiveness, or the applicability of the rationale to RAO as
CMP> a solution. But the rationale (intercept packets) is key...
GIM>> Would the following update address your concern:
OLD TEXT:
The rationale for having an RAO is
questionable.
NEW TEXT:
The rationale for using an
RAO as the exception mechanism is questionable.
Furthermore, RFC 6398 identifies security
vulnerabilities associated with the RAO.
CMP> This loose sentence feels handwavish -- as RFC 6398 has
CMP> no-use recommendations for the open Internet end-to-end,
CMP> while allows use in controlled environments.
GIM>> This refers to the analysis of the security concerns in Section 3 and recommendations that are based on the analysis, e.g., Section 4.1. As LSP Ping may be used in inter-area cases, recommendations in Section 4.1 of RFC 6398 are relevant. Would the following clarification address your concern:
OLD TEXT:
Furthermore, RFC 6398 identifies security
vulnerabilities associated with the RAO.
NEW TEXT:
Furthermore, [RFC6398]
identifies security vulnerabilities associated with the RAO and
recommends against its use outside of controlled environments.
CMP> Overall, I feel the rationale for this doc needs some
CMP> tightening in the Abstract.
1. Introduction
RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
Failures" (aka LSP Ping) [RFC8029] detects data-plane failures in
MPLS Label Switched Paths (LSPs). It can operate in “ping mode” or
“traceroute mode”. When operating in ping mode, it verifies end-to-
end LSP continuity. When operating in traceroute mode, it can
localize failures to a particular node along an LSP.
CMP> I would keep the definition of ping and traceroute modes aligned
CMP> with RFC 8029, that says
"ping mode is used for connectivity checks,
and traceroute is used for hop-by-hop fault localization as well as
path tracing."
CMP> note "continuity" vs. "connectivity", and addition of "path tracing"
GIM>> Please consider the following update:
OLD TEXT:
When operating in ping mode, it verifies end-to-
end LSP continuity. When operating in traceroute mode, it can
localize failures to a particular node along an LSP.
NEW TEXT:
When operating in ping mode, it checks LSP
connectivity. When operating in traceroute mode, it can trace an LSP
and localize failures to a particular node along an LSP.
The echo request message is
further encapsulated in an MPLS label stack.
CMP> This should be a global check on the document, "The MPLS echo request"
GIM>> Thank you for pointing that.Done.
CMP> Also, this sentence implies that it is always encapsulated in an MPLS
CMP> label stack -- whereas that would not be the case for Implicit Null.
CMP> This is in Section 4.3 of RFC 8029, in:
"If all of the FECs in the
stack correspond to Implicit Null labels, the MPLS echo request is
considered unlabeled...""
GIM>> A very helpful observation, thank you. The following update is proposed to clarify:
OLD TEXT:
The echo request message is
further encapsulated in an MPLS label stack.
NEW TEXT:
The MPLS echo request
message is further encapsulated in an MPLS label stack, except when
all of the FECs in the stack correspond to Implicit Null labels.
When operating in ping mode, LSP ping sends a single echo request
message, with the MPLS TTL set to a high value (e.g., 255). This
CMP> Is this TTL set to any "high value" (and what exactly is high??),
CMP> Or to "255" as in S4.3 of RFC 8029?
GIM>> The text in RFC 8029 seems open to an interpretation (in the way it uses the normative language):
In "ping" mode (end-to-end connectivity check), the TTL in the
outermost label is set to 255.
Would using wording close to RFC 8029 address your concern:
OLD TEXT:
When operating in ping mode, LSP ping sends a single echo request
message, with the MPLS TTL set to a high value (e.g., 255).
NEW TEXT:
When operating in ping mode, LSP ping sends a single MPLS echo
request message, with the MPLS TTL set to 255.
When operating in traceroute mode, MPLS ping sends multiple echo
request messages.
CMP> This paragraph above is potentially ambiguous: can traceroute
CMP> send lots of "MPLS echo requests" messages all at once in a
CMP> concurrent fashion (like concurrent algo in Paris Traceroute)?
CMP> Not really due to the DDSMAP. I'd suggest pointing to RFC 8029
CMP> as much as possible on this, instead of re-writing it.
CMP> And for this sentence, add that subsequently increasing TTL, etc.
GIM>> I think that rather than repeating it, we can refer to the traceroute process defined in Section 4.3 of RFC 8029, e.g.,
NEW TEXT:
When operating in traceroute mode, MPLS ping sends multiple
MPLS echo request messages as defined in Section 4.3 of [RFC8029].
The IP header that encapsulates an echo request message must include
a Router Alert Option (RAO), while the IP header that encapsulates an
echo reply message may include an RAO.
CMP> It is not that the *MPLS* (keeps being missed) echo reply "may"
CMP> include a RAO. It is that there are cases in which it MUST and
CMP> cases in which it doesn't -- as per reply-modes. See S4.5 of
CMP> RFC 8029.
GIM>> It seems as if the use of the non-normative "may" is reasonable since the use of RAO in the MPLS echo reply message is dependent on the value of the Reply Mode in the corresponding MPLS echo request message. Would the following clarification address your concern:
OLD TEXT:
The IP header that encapsulates an echo request message must include
a Router Alert Option (RAO), while the IP header that encapsulates an
echo reply message may include an RAO.
NEW TEXT:
The IP header that encapsulates an MPLS echo request message must
include a Router Alert Option (RAO), while the IP header that
encapsulates an MPLS echo reply message must include an RAO if the
value of the Reply Mode in the corresponding MPLS echo request
message is "Reply via an IPv4/IPv6 UDP packet with Router Alert".
In both cases, the rationale
for including an RAO is questionable. Furthermore, [RFC6398]
identifies security vulnerabilities associated with the RAO and
recommends against its use outside of controlled environments.
CMP> All same comments as with the Abstract, plus, "MPLS LSP Ping"
CMP> is not used end-to-end in the open Internet, right? As such,
CMP> the applicability (as this justification) of 6398 is questionable.
GIM>> MPLS LSP ping can be used in inter-area cases. As the boundary between "open Internet" and "inter-area" is blurred, recommendations of Section 4.1 of RFC 6398 seems like applicable in the case analyzed in the document.
2.1. Echo Request
...
To achieve this, RFC 8029 proposes the following:
CMP> This section and enumeration is very useful.
CMP> Nit: RFC 8029 doesn't "propose" but "specifies" maybe.
GIM>> s/propose/specifies/
CMP> There's one important element missing, however, which
CMP> is the "MPLS Router Alert Label". See Section 4.4 of
CMP> RFC 8029, first paragraph.
GIM>> Thank you for pointing this out. The goal of the list is to enumarate all mechanisms to prevent leaking MPLS echo request message that are used concurrently. MPLS Router Alert is an optional exception mechanism and because of that it is not included in the list. I hope that is reasonable.
3. When the echo request message is encapsulated in IPv4, the IPv4
header must include an RAO. When the echo request message is
encapsulated in IPv6, the IPv6 header chain must include a Hop-
by-hop extension header and the Hop-by-hop extension header must
include an RAO.
CMP> This is slightly incomplete, given RFC 7506 (specifying the
CMP> actual RAO value)
GIM>> Would the following clarification address your concern:
OLD TEXT:
When the echo request message is
encapsulated in IPv6, the IPv6 header chain must include a Hop-
by-hop extension header and the Hop-by-hop extension header must
include an RAO.
NEW TEXT:
When the MPLS echo request
message is encapsulated in IPv6, the IPv6 header chain must
include a Hop-by-hop extension header and the Hop-by-hop
extension header must include an RAO with the option value set to
MPLS OAM [RFC7506].
2.2. Echo Reply
An LSP ping replies to the MPLS echo message with an MPLS echo reply
message. It has four reply modes:
CMP> There are 4 reply modes specified in RFC 8029, but there's more, see
CMP>
https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#reply-modes
GIM>> Will adding the reference to RFC 8029 makes it unambiguos:
NEW TEXT:
An LSP ping replies to the MPLS echo request message with an MPLS
echo reply message. Four reply modes are defined in [RFC8029]:
3. Update to RFC 7506
RFC 7506 defines the IPv6 Router Alert Option for MPLS Operations,
Administration, and Management. This document reclassifies RFC 7506
as Historic.
CMP> A question: since RFC 7506 defines the IPv6 RAO value as "MPLS OAM",
CMP> and not as "MPLS LSP Ping", are other MPLS OAM potential uses of it?
CMP> An ICMPv6 over MPLS with RAO, would it use this value?
GIM>> I am not aware of the specification that requires use of MPLS OAM option in case of ICMPv6 over MPLS.
4. Update to RFC 8029
CMP> This section changes subject to focus on the loopback address for
CMP> IPv6. Given how many pieces of RFC 8029 include the RAO text,
CMP> I'd suggest this section to specifically enumerate all places
CMP> in RFC 8029 that it's updating.
CMP> For example, how would these sections of RFC 8029 be re-written?
CMP> Sections 2.2, 3, 4.3, 4.4 (what if a RAO is *received*?), and
CMP> the "Label Operation Check", 4.5, 6.2.1, etc.
* For IPv6, the IPv6 loopback address ::1/128 SHOULD be used.
CMP> The issue of ::1/128 is a bit more complex than a single sentence,
CMP> because it is swapping a range for an address. This is documented
CMP> in https://www.rfc-editor.org/rfc/rfc7439#section-3.4.2, and
CMP> that analysis should be referenced/cited and addressed.
CMP> Further, RFC 7439 Section 3.4.2 should be Updated by this doc.
GIM>> Section 3.4.2 of RFC 7439 explains use of an IPv4-mapped IPv6 address as IPv6 destination address as mechanism to excersise multiple paths. In the draft, for the ECMP environment use of alternative sources of entropy is recommended:
* To exercise all paths in an ECMP environment, the entropy other
than the IP destination address SHOULD be used.
Furthermore, use of the IPv4-mapped IPv6 range of addresses is not prohibited, it remains an option. Thus, it appears that everything discussed in Section 3.4.2 of RFC 7439 is not affected by this draft.
CMP> Further, what happens to RFC 8029's Section 3.4.1.1.1, "Multipath
CMP> Information Encoding"?
GIM>> Section 4 of draft-ietf-mpls-lspping-norao makes use of IPv6 address from the 0:0:0:0:0:FFFF:7F00/104 range optional
* The sender of an echo request MAY select the IPv6 destination
address from the 0:0:0:0:0:FFFF:7F00/104 range.
As the use of that range is allowed, there's no apparent need updating Section 3.4.1.1.1. Would you agree?
7. Security Considerations
The recommendations this document makes do not compromise security.
CMP> Given that security was one of the cited rationales mentioned,
CMP> I'd think that this section should discuss how the security
CMP> posture is improved with this document.
GIM>> Thank you for your suggestion. Please consider the follwoing updated text:
NEW TEXT:
The recommendations this document makes do not compromise security.
In case of using IPv6 loopback address ::1/128 strengthens security
for LSP Ping by using the standardized loopback address with well-
defined behavior.
More Editorial:
Abstract
The echo request and echo response messages, defined in RFC 8029
"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"
(aka LSP ping messages), are encapsulated in IP headers that include
CMP> ^^^ suggest "AKA" or "usually referred to as" instead of "aka".
CMP> Same comment on the Introduction.
GIM>> Done*2
1. Introduction
RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
Failures" (aka LSP Ping) [RFC8029] detects data-plane failures in
MPLS Label Switched Paths (LSPs). It can operate in “ping mode” or
CMP> ^^^^^^^^^^^
CMP> There's a number of non-ascii characters, as for example the use of
CMP> “” instead of "". Suggest global replacement.
GIM>>
Therefore, this document removes the RAO from both LSP ping message
encapsulations. It updates RFCs 7506 [RFC7506] and 8029.
CMP> Missing citation for RFC 8029.
GIM>> Thank you for another great catch. Done.
2.1. Echo Request
CMP> "When the *MPLS* echo request message" ("MPLS" is missing in each
CMP> one of the number list elements)
GIM>> Per your earlier suggestion, applied global update. I hope I caught all of them.
2. When the echo request message is encapsulated in IPv4, the IPv4
TTL must be equal to 1. When the echo request message is
encapsulated in IPv6, the IPv6 Hop Limit must be equal to 1. For
further information on the encoding of the TTL/Hop Limit in an
echo request message see Section 4.3 of [RFC8029].
CMP> Missing comma, "...echo request message, see Section..."
GIM>> Done, thx.
2.2. Echo Reply
However, it is not clear that the use of the RAO increases the
reliability of the return path. In fact, one can argue it decreases
the reliability in many instances, due to the additional burden of
processing the RAO. This document changes RGC 8020 in that mode 3
are removed.
CMP> Typo, "RGC 8020" instead of "RFC 8029".
GIM>> Changed to reference to RFC 8029. Would you agree?
5. Backwards Compatibility
This document requests that the IPv6 RAO value for MPLS OAM (69) in
[IANA-IPV6-RAO] is marked as "Deprecated". It also requests tha that
CMP> Typo, "tha that" should be "that the" ^^^^^^^^
GIM>> Thank you for catching this. Done.
I hope these help and are clear and useful.
Thanks!
Carlos.
MPLS WG K. Kompella
Internet-Draft R. Bonica
Updates: 7506, 8029 (if approved) Juniper Networks
Intended status: Standards Track G. Mirsky, Ed.
Expires: 13 March 2024 Ericsson
10 September 2023
Deprecating the Use of Router Alert in LSP Ping
draft-ietf-mpls-lspping-norao-03
Abstract
The MPLS echo request and MPLS echo response messages, defined in RFC
8029 "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
Failures" (usually referred to as LSP ping messages), are
encapsulated in IP headers that include a Router Alert Option (RAO).
The rationale for using an RAO as the exception mechanism is
questionable. Furthermore, RFC 6398 identifies security
vulnerabilities associated with the RAO and recommends against its
use outside of controlled environments.
Therefore, this document removes the RAO from LSP ping message
encapsulations. It updates RFCs 7506 and 8029.
This document also recommends the use of an IPv6 loopback address
(::1/128) and discourages the use of an IPv4 loopback address mapped
to IPv6.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 March 2024.
Kompella, et al. Expires 13 March 2024 [Page 1]
Internet-Draft RAO-less LSP Ping September 2023
Copyright Notice
Copyright (c) 2023 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Router Alert for LSP Ping (RFC 8029) . . . . . . . . . . . . 3
2.1. MPLS Echo Request . . . . . . . . . . . . . . . . . . . . 3
2.2. MPLS Echo Reply . . . . . . . . . . . . . . . . . . . . . 4
3. Update to RFC 7506 . . . . . . . . . . . . . . . . . . . . . 5
4. Update to RFC 8029 . . . . . . . . . . . . . . . . . . . . . 5
5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
Failures" (usually referred to as LSP Ping) [RFC8029] detects data-
plane failures in MPLS Label Switched Paths (LSPs). It can operate
in "ping mode" or "traceroute mode". When operating in ping mode, it
checks LSP connectivity. When operating in traceroute mode, it can
trace an LSP and localize failures to a particular node along an LSP.
The reader is assumed be familiar with [RFC8029] and its terminology.
LSP ping defines a probe message called the â??MPLS echo requestâ??. It
also defines a response message called the â??MPLS echo replyâ??. Both
messages are encapsulated in UDP and IP. The MPLS echo request
message is further encapsulated in an MPLS label stack, except when
all of the FECs in the stack correspond to Implicit Null labels.
Kompella, et al. Expires 13 March 2024 [Page 2]
Internet-Draft RAO-less LSP Ping September 2023
When operating in ping mode, LSP ping sends a single MPLS echo
request message, with the MPLS TTL set to 255. This message is
intended to reach the egress Label Switching Router (LSR). When
operating in traceroute mode, MPLS ping sends multiple MPLS echo
request messages as defined in Section 4.3 of [RFC8029]. It
manipulates the MPLS TTL so that the first message expires on the
first LSR along the path and subsequent messages expire on subsequent
LSRs.
The IP header that encapsulates an MPLS echo request message must
include a Router Alert Option (RAO), while the IP header that
encapsulates an MPLS echo reply message must include an RAO if the
value of the Reply Mode in the corresponding MPLS echo request
message is "Reply via an IPv4/IPv6 UDP packet with Router Alert". In
both cases, the rationale for including an RAO is questionable.
Furthermore, [RFC6398] identifies security vulnerabilities associated
with the RAO and recommends against its use outside of controlled
environments.
Therefore, this document removes the RAO from both LSP ping message
encapsulations. It updates RFCs 7506 [RFC7506] and 8029 [RFC8029].
1.1. Terminology
The key words â??MUSTâ??, â??MUST NOTâ??, â??REQUIREDâ??, â??SHALLâ??, â??SHALL NOTâ??,
â??SHOULDâ??, â??SHOULD NOTâ??, â??RECOMMENDEDâ??, â??NOT RECOMMENDEDâ??, â??MAYâ??, and
â??OPTIONALâ?? in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
LSP: Label Switched Path
LSR: Label Switching Router
RAO: Router Alert Option
2. Router Alert for LSP Ping (RFC 8029)
2.1. MPLS Echo Request
While the MPLS echo request message must traverse every node in the
LSP under test, it must not traverse any other node. Specifically,
the message must not be forwarded beyond the egress Label Switching
Router (LSR).
To achieve this, RFC 8029 specifies the following:
Kompella, et al. Expires 13 March 2024 [Page 3]
Internet-Draft RAO-less LSP Ping September 2023
1. When the MPLS echo request message is encapsulated in IPv4, the
IPv4 destination address must be chosen from the subnet 127/8.
When the MPLS echo request message is encapsulated in IPv6, the
IPv6 destination address must be chosen from the subnet
0:0:0:0:0:FFFF:7F00:0/104.
2. When the MPLS echo request message is encapsulated in IPv4, the
IPv4 TTL must be equal to 1. When the MPLS echo request message
is encapsulated in IPv6, the IPv6 Hop Limit must be equal to 1.
For further information on the encoding of the TTL/Hop Limit in
an MPLS echo request message, see Section 4.3 of [RFC8029].
3. When the MPLS echo request message is encapsulated in IPv4, the
IPv4 header must include an RAO. When the MPLS echo request
message is encapsulated in IPv6, the IPv6 header chain must
include a Hop-by-hop extension header and the Hop-by-hop
extension header must include an RAO with the option value set to
MPLS OAM [RFC7506].
Currently, ALL of these are required. However, any one is sufficient
to prevent forwarding the packet beyond the egress LSR.
Therefore, this document changes RFC 8029 in that Requirement 3 is
removed.
The authors are not aware of any implementation that relies on the
RAO to prevent packets from being forwarded beyond the egress LSR.
2.2. MPLS Echo Reply
An LSP ping replies to the MPLS echo request message with an MPLS
echo reply message. Four reply modes are defined in [RFC8029]:
1. Do not reply
2. Reply via an IPv4/IPv6 UDP packet
3. Reply via an IPv4/IPv6 UDP packet with Router Alert
4. Reply via application-level control channel
The rationale for mode 3 is questionable, if not wholly misguided.
According to RFC 8029, â??If the normal IP return path is deemed
unreliable, one may use 3 (Reply via an IPv4/IPv6 UDP packet with
Router Alert).â??
Kompella, et al. Expires 13 March 2024 [Page 4]
Internet-Draft RAO-less LSP Ping September 2023
However, it is not clear that the use of the RAO increases the
reliability of the return path. In fact, one can argue it decreases
the reliability in many instances, due to the additional burden of
processing the RAO. This document changes RFC 8020[RFC8029] in that
mode 3 are removed.
The authors are not aware of any implementations of mode 3.
3. Update to RFC 7506
RFC 7506 defines the IPv6 Router Alert Option for MPLS Operations,
Administration, and Management. This document reclassifies RFC 7506
as Historic.
4. Update to RFC 8029
[RFC8029] requires that the IPv6 Destination Address used in IP/UDP
encapsulation of an MPLS echo request packet is selected from the
IPv4 loopback address range mapped to IPv6. Such packets do not have
the same behavior as prescribed in [RFC1122] for an IPv4 loopback
addressed packet.
[RFC4291] defines ::1/128 as the single IPv6 loopback address.
Considering that this specification updates section 2.1 of [RFC8029]
regarding the selection of an IPv6 destination address for an MPLS
echo request message:
* For IPv6, the IPv6 loopback address ::1/128 SHOULD be used.
* The sender of an MPLS echo request MAY select the IPv6 destination
address from the 0:0:0:0:0:FFFF:7F00/104 range.
* To exercise all paths in an ECMP environment, the entropy other
than the IP destination address SHOULD be used.
LSP Ping implementations SHOULD ignore RAO options when they arrive
on incoming MPLS echo request and MPLS echo reply messages.
5. Backwards Compatibility
LSP Ping implementations SHOULD ignore RAO options when they arrive
on incoming MPLS echo request and MPLS echo reply messages.
This document requests that the IPv6 RAO value for MPLS OAM (69) in
[IANA-IPV6-RAO] is marked as "Deprecated". It also requests that the
Reply Mode 3 ("Reply via an IPv4/IPv6 UDP packet with Router Alert")
in [IANA-LSP-PING] is marked as "Deprecated".
Kompella, et al. Expires 13 March 2024 [Page 5]
Internet-Draft RAO-less LSP Ping September 2023
We interpret "DEPRECATED" in this context to mean that the deprecated
values should not be used in new implementations, and that deployed
implementations that use these values continue to work seamlessly.
6. IANA Considerations
If this document is approved, mark the IPv6 RAO value of MPLS OAM
(69) in [IANA-IPV6-RAO] as â??Deprecatedâ??. [RFC8126] offers a formal
description of the word "Deprecated".
Also, mark Reply Mode 3 (â??Reply via an IPv4/IPv6 UDP packet with
Router Alertâ??) in [IANA-LSP-PING] as â??Deprecatedâ??.
7. Security Considerations
The recommendations this document makes do not compromise security.
In case of using IPv6 loopback address ::1/128 strengthens security
for LSP Ping by using the standardized loopback address with well-
defined behavior.
8. Normative References
[IANA-IPV6-RAO]
IANA, "IPv6 Router Alert Option Values", n.d.,
<https://www.iana.org/assignments/ipv6-routeralert-
values>.
[IANA-LSP-PING]
IANA, "Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs) Ping Parameters", n.d.,
<https://www.iana.org/assignments/mpls-lsp-ping-
parameters/mpls-lsp-ping-parameters.xml>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
Kompella, et al. Expires 13 March 2024 [Page 6]
Internet-Draft RAO-less LSP Ping September 2023
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert
Option for MPLS Operations, Administration, and
Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April
2015, <https://www.rfc-editor.org/info/rfc7506>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses
Kireeti Kompella
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States
Email: kireeti.ietf@xxxxxxxxx
Ron Bonica
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States
Email: rbonica@xxxxxxxxxxx
Greg Mirsky (editor)
Ericsson
Email: gregimirsky@xxxxxxxxx
Kompella, et al. Expires 13 March 2024 [Page 7]
<<< text/html; charset="US-ASCII"; name="draft-ietf-mpls-lspping-norao-03.diff.html": Unrecognized >>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
