< draft-xiao-6man-icmpv6-ioam-conf-state-00.txt   draft-xiao-6man-icmpv6-ioam-conf-state-01.txt >
6MAN Working Group X. Min 6MAN Working Group X. Min
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Updates: 4884 (if approved) G. Mirsky Updates: 4884 (if approved) G. Mirsky
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: 27 April 2022 24 October 2021 Expires: 27 October 2022 25 April 2022
ICMPv6 Echo Request/Reply for Enabled In-situ OAM Capabilities ICMPv6 Echo Request/Reply for Enabled In-situ OAM Capabilities
draft-xiao-6man-icmpv6-ioam-conf-state-00 draft-xiao-6man-icmpv6-ioam-conf-state-01
Abstract Abstract
This document describes the ICMPv6 IOAM Echo functionality, which This document describes the ICMPv6 IOAM Echo functionality, which
uses the ICMPv6 IOAM Echo Request/Reply messages, allowing the IOAM uses the ICMPv6 IOAM Echo Request/Reply messages, allowing the IOAM
encapsulating node to discover the enabled IOAM capabilities of each encapsulating node to discover the enabled IOAM capabilities of each
IOAM transit node and IOAM decapsulating node. IOAM transit and decapsulating node.
This document updates RFC 4884.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 27 April 2022. This Internet-Draft will expire on 27 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. ICMPv6 IOAM Echo Request . . . . . . . . . . . . . . . . . . 3 3. ICMPv6 IOAM Echo Request . . . . . . . . . . . . . . . . . . 3
4. ICMPv6 IOAM Echo Reply . . . . . . . . . . . . . . . . . . . 4 4. ICMPv6 IOAM Echo Reply . . . . . . . . . . . . . . . . . . . 5
4.1. IOAM Capabilities Objects . . . . . . . . . . . . . . . . 5 4.1. IOAM Capabilities Objects . . . . . . . . . . . . . . . . 6
4.2. Examples of IOAM Echo Reply . . . . . . . . . . . . . . . 7 4.2. Examples of IOAM Echo Reply . . . . . . . . . . . . . . . 7
5. ICMPv6 Message Processing . . . . . . . . . . . . . . . . . . 8 5. ICMPv6 Message Processing . . . . . . . . . . . . . . . . . . 10
5.1. Code Field Processing . . . . . . . . . . . . . . . . . . 9 5.1. Code Field Processing . . . . . . . . . . . . . . . . . . 11
6. Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . . 10 6. Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
IPv6 encapsulation for In-situ OAM (IOAM) data is defined in IPv6 encapsulation for In-situ OAM (IOAM) data is defined in
[I-D.ietf-ippm-ioam-ipv6-options], which uses IPv6 hop-by-hop options [I-D.ietf-ippm-ioam-ipv6-options], which uses IPv6 hop-by-hop options
and/or destination options to carry IOAM data. and destination option to carry IOAM data.
As specified in [I-D.ietf-ippm-ioam-conf-state], echo request/reply As specified in [I-D.ietf-ippm-ioam-conf-state], echo request/reply
can be used for the IOAM encapsulating node to discover the enabled can be used for the IOAM encapsulating node to discover the enabled
IOAM capabilities at IOAM transit nodes and IOAM decapsulating node. IOAM capabilities at IOAM transit and decapsulating nodes.
As specified in [RFC4443], the Internet Control Message Protocol for As specified in [RFC4443], the Internet Control Message Protocol for
IPv6 (ICMPv6) is an integral part of IPv6, and the base protocol MUST IPv6 (ICMPv6) is an integral part of IPv6, and the base protocol MUST
be fully implemented by every IPv6 node. ICMPv6 messages include be fully implemented by every IPv6 node. ICMPv6 messages include
error messages and informational messages, and the latter are error messages and informational messages, and the latter are
referred to as ICMPv6 Echo Request/Reply messages. [RFC4884] defines referred to as ICMPv6 Echo Request/Reply messages. [RFC4884] defines
ICMPv6 Extension Structure by which multi-part ICMPv6 error messages ICMPv6 Extension Structure by which multi-part ICMPv6 error messages
are supported. [RFC8335] defines ICMPv6 Extended Echo Request/Reply are supported. [RFC8335] defines ICMPv6 Extended Echo Request/Reply
messages, and the ICMPv6 Extended Echo Request contains an ICMPv6 messages, and the ICMPv6 Extended Echo Request contains an ICMPv6
Extension Structure customized for this message. Both [RFC4884] and Extension Structure customized for this message. Both [RFC4884] and
[RFC8335] provide sound principles and examples on how to extend [RFC8335] provide sound principles and examples on how to extend
ICMPv6 error messages and echo request/reply messages. ICMPv6 error messages and echo request/reply messages.
This document describes the ICMPv6 IOAM Echo functionality, which This document describes the ICMPv6 IOAM Echo functionality, which
uses the ICMPv6 IOAM Echo Request/Reply messages, allowing the IOAM uses the ICMPv6 IOAM Echo Request/Reply messages, allowing the IOAM
encapsulating node to discover the enabled IOAM capabilities of each encapsulating node to discover the enabled IOAM capabilities of each
IOAM transit node and IOAM decapsulating node. IOAM transit and decapsulating node.
The IOAM encapsulating node sends an ICMPv6 IOAM Echo Request message The IOAM encapsulating node sends an ICMPv6 IOAM Echo Request message
to each IOAM transit and decapsulating node, then each receiving node to each IOAM transit and decapsulating node, then each receiving node
executes access control procedures, and if access is granted, each executes access control procedures, and if access is granted, each
receiving node returns an ICMPv6 IOAM Echo Reply message which receiving node returns an ICMPv6 IOAM Echo Reply message which
indicates the enabled IOAM capabilities of the receiving node. The indicates the enabled IOAM capabilities of the receiving node. The
ICMPv6 IOAM Echo Reply contains an ICMPv6 Extension Structure exactly ICMPv6 IOAM Echo Reply message contains an ICMPv6 Extension Structure
customized to this message, and the ICMPv6 Extension Structure exactly customized to this message, and the ICMPv6 Extension
contains one or more IOAM Capabilities Objects. Structure contains one or more IOAM Capabilities Objects.
Note that before the IOAM encapsulating node sends the ICMPv6 IOAM Note that before the IOAM encapsulating node sends the ICMPv6 IOAM
Echo Request messages, it needs to know the IPv6 address of each node Echo Request messages, it needs to know the IPv6 address of each node
along the transport path of a data packet. that can be achieved by along the transport path of a data packet to which IOAM data would be
executing ICMPv6 traceroute or provisioning explicit path at the IOAM added. That can be achieved by executing ICMPv6 traceroute or
encapsulating node. provisioning explicit path at the IOAM encapsulating node.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. ICMPv6 IOAM Echo Request 3. ICMPv6 IOAM Echo Request
skipping to change at page 5, line 42 skipping to change at page 6, line 14
* Following the IOAM Echo Reply header, it's a List of IOAM * Following the IOAM Echo Reply header, it's a List of IOAM
Capabilities Objects, which is also called IOAM Capabilities Capabilities Objects, which is also called IOAM Capabilities
Response Container Payload in Section 3.2 of Response Container Payload in Section 3.2 of
[I-D.ietf-ippm-ioam-conf-state]. [I-D.ietf-ippm-ioam-conf-state].
* Section 7 of [RFC4884] defines the ICMP Extension Structure. As * Section 7 of [RFC4884] defines the ICMP Extension Structure. As
per RFC 4884, the Extension Structure contains exactly one per RFC 4884, the Extension Structure contains exactly one
Extension Header followed by one or more objects. When applied to Extension Header followed by one or more objects. When applied to
the ICMPv6 IOAM Echo Reply message, the ICMP Extension Structure the ICMPv6 IOAM Echo Reply message, the ICMP Extension Structure
SHOULD contain one or more IOAM Capabilities Objects. MUST contain one or more IOAM Capabilities Objects.
4.1. IOAM Capabilities Objects 4.1. IOAM Capabilities Objects
All ICMPv6 IOAM Capabilities Objects are encapsulated in an ICMPv6 All ICMPv6 IOAM Capabilities Objects are encapsulated in an ICMPv6
IOAM Echo Reply message. IOAM Echo Reply message.
Each ICMPv6 IOAM Capabilities Object has the following format: Each ICMPv6 IOAM Capabilities Object has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 7, line 27 skipping to change at page 8, line 16
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |Sequence Number| Num of NS-IDs | | Identifier |Sequence Number| Num of NS-IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type | | Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W| | IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Egress_MTU | | Namespace-ID | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress_if_id (short or wide format) ...... | | Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type | | Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | IOAM-POT-Type |P|SoR|Reserved | | Namespace-ID | IOAM-POT-Type |SoP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example 1 of IOAM Echo Reply
In a deployment where two Namespace-IDs (Namespace-ID1 and Namespace-
ID2) are used, for both Namespace-ID1 and Namespace-ID2 the IOAM Pre-
allocated Tracing Capabilities and IOAM Proof-of-Transit Capabilities
are enabled at the IOAM transit node that received ICMPv6 IOAM Echo
Request message, the ICMPv6 IOAM Echo Reply message is depicted as
the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |Sequence Number| Num of NS-IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID1 | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID1 | IOAM-POT-Type |SoP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID2 | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID2 | IOAM-POT-Type |SoP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example 2 of IOAM Echo Reply
In a deployment where only the default Namespace-ID is used, the IOAM In a deployment where only the default Namespace-ID is used, the IOAM
Pre-allocated Tracing Capabilities, IOAM Proof-of-Transit Pre-allocated Tracing Capabilities, IOAM Proof-of-Transit
Capabilities and IOAM Edge-to-Edge Capabilities are enabled at the Capabilities and IOAM Edge-to-Edge Capabilities are enabled at the
IOAM decapsulating node that received ICMPv6 IOAM Echo Request IOAM decapsulating node that received ICMPv6 IOAM Echo Request
message, the ICMPv6 IOAM Echo Reply message is depicted as the message, the ICMPv6 IOAM Echo Reply message is depicted as the
following: following:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |Sequence Number| Num of NS-IDs | | Identifier |Sequence Number| Num of NS-IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type | | Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W| | IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Egress_MTU | | Namespace-ID | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress_if_id (short or wide format) ...... | | Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type | | Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | IOAM-POT-Type |P|SoR|Reserved | | Default Namespace-ID | IOAM-POT-Type |SoP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type | | Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | IOAM-E2E-Type | | Namespace-ID | IOAM-E2E-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TSF|TSL| Reserved | MBZ | |TSF| Reserved | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example 3 of IOAM Echo Reply
Note that when an ICMPv6 IOAM Echo Request message or IOAM Echo Reply Note that when an ICMPv6 IOAM Echo Request message or IOAM Echo Reply
message is received, the Payload Length field of IPv6 Header message is received, the Payload Length field of IPv6 Header
[RFC8200] indicates the message length. [RFC8200] indicates the message length.
5. ICMPv6 Message Processing 5. ICMPv6 Message Processing
When a node receives an ICMPv6 IOAM Echo Request message and any of When a node receives an ICMPv6 IOAM Echo Request and any of the
the following conditions apply, the node MUST silently discard the following conditions apply, the node MUST silently discard the
incoming message: incoming message:
* The node does not recognize the ICMPv6 IOAM Echo Request message. * The node does not recognize the ICMPv6 IOAM Echo Request message.
* The node has not explicitly enabled ICMPv6 IOAM Echo * The node has not explicitly enabled ICMPv6 IOAM Echo
functionality. functionality.
* The incoming ICMPv6 IOAM Echo Request carries a Source Address * The incoming ICMPv6 IOAM Echo Request carries a Source Address
that is not explicitly authorized. that is not explicitly authorized.
skipping to change at page 12, line 41 skipping to change at page 14, line 41
All codes mentioned above are assigned on an FCFS basis with a range All codes mentioned above are assigned on an FCFS basis with a range
of 0-255. of 0-255.
8. Security Considerations 8. Security Considerations
Securiy issues discussed in [I-D.ietf-ippm-ioam-conf-state] apply to Securiy issues discussed in [I-D.ietf-ippm-ioam-conf-state] apply to
this document. this document.
This document recommends using IP Authentication Header [RFC4302] or This document recommends using IP Authentication Header [RFC4302] or
IP Encapsulating Security Payload Header [RFC4303] to provide IP Encapsulating Security Payload Header [RFC4303] to provide
integrity protection for IOAM Capabilities info. integrity protection for IOAM Capabilities information.
This document recommends using IP Encapsulating Security Payload This document recommends using IP Encapsulating Security Payload
Header [RFC4303] to provide privacy protection for IOAM Capabilities Header [RFC4303] to provide privacy protection for IOAM Capabilities
info. information.
This document recommends that the network operators establish This document recommends that the network operators establish
policies that restrict access to ICMPv6 IOAM Echo functionality. In policies that restrict access to ICMPv6 IOAM Echo functionality. In
order to enforce these policies, nodes that support ICMPv6 IOAM Echo order to enforce these policies, nodes that support ICMPv6 IOAM Echo
functionality MUST support the following configuration options: functionality MUST support the following configuration options:
* Enable/disable ICMP IOAM Echo functionality. By default, ICMPv6 * Enable/disable ICMPv6 IOAM Echo functionality. By default, ICMPv6
IOAM Echo functionality is disabled. IOAM Echo functionality is disabled.
* Define enabled Namespace-IDs. By default, all Namespace-IDs * Define enabled Namespace-IDs. By default, all Namespace-IDs
except the default one (i.e., Namespace-ID 0x0000) are disabled. except the default one (i.e., Namespace-ID 0x0000) are disabled.
* For each enabled Namespace-ID, define the prefixes from which * For each enabled Namespace-ID, define the prefixes from which
ICMPv6 IOAM Echo Request messages are permitted. ICMPv6 IOAM Echo Request messages are permitted.
When a node receives an ICMPv6 IOAM Echo Request message that it is When a node receives an ICMPv6 IOAM Echo Request message that it is
not configured to support, it MUST silently discard the message. See not configured to support, it MUST silently discard the message. See
skipping to change at page 13, line 32 skipping to change at page 15, line 32
TBA. TBA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ippm-ioam-conf-state] [I-D.ietf-ippm-ioam-conf-state]
Min, X., Mirsky, G., and L. Bo, "Echo Request/Reply for Min, X., Mirsky, G., and L. Bo, "Echo Request/Reply for
Enabled In-situ OAM Capabilities", Work in Progress, Enabled In-situ OAM Capabilities", Work in Progress,
Internet-Draft, draft-ietf-ippm-ioam-conf-state-01, 24 Internet-Draft, draft-ietf-ippm-ioam-conf-state-03, 26
October 2021, <https://www.ietf.org/archive/id/draft-ietf- January 2022, <https://www.ietf.org/archive/id/draft-ietf-
ippm-ioam-conf-state-01.txt>. ippm-ioam-conf-state-03.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
skipping to change at page 14, line 14 skipping to change at page 16, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ippm-ioam-ipv6-options] [I-D.ietf-ippm-ioam-ipv6-options]
Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
ipv6-options-06, 31 July 2021, ipv6-options-07, 6 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-ippm-ioam- <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
ipv6-options-06.txt>. ipv6-options-07.txt>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
 End of changes. 30 change blocks. 
47 lines changed or deleted 94 lines changed or added

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