< draft-ietf-v6ops-hbh-00.txt   draft-ietf-v6ops-hbh-01.txt >
Network Working Group S. Peng Network Working Group S. Peng
Internet-Draft Z. Li Internet-Draft Z. Li
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: 12 April 2022 C. Xie Expires: 20 October 2022 C. Xie
China Telecom China Telecom
Z. Qin Z. Qin
China Unicom China Unicom
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
9 October 2021 18 April 2022
Operational Issues with Processing of the Hop-by-Hop Options Header Operational Issues with Processing of the Hop-by-Hop Options Header
draft-ietf-v6ops-hbh-00 draft-ietf-v6ops-hbh-01
Abstract Abstract
This document describes the processing of the Hop-by-Hop Options This document describes the processing of the Hop-by-Hop Options
Header (HBH) in today's routers in the aspects of standards Header (HBH) in today's routers in the aspects of standards
specification, common implementations, and default operations. This specification, common implementations, and default operations. This
document outlines the reasons why the Hop-by-Hop Options Header is document outlines the reasons why the Hop-by-Hop Options Header is
rarely utilized in current networks. In addition, this document rarely utilized in current networks. In addition, this document
describes how the HBH could be used as a powerful mechanism allowing describes how the HBH could be used as a powerful mechanism allowing
deployment and operations of new services requiring a more optimized deployment and operations of new services requiring a more optimized
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 12 April 2022. This Internet-Draft will expire on 20 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Modern Router Architecture . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification of RFC 8200 . . . . . . . . . . . . . . . . . . 7 3. Modern Router Architecture . . . . . . . . . . . . . . . . . 4
4. Common Implementations . . . . . . . . . . . . . . . . . . . 8 4. Specification of RFC 8200 . . . . . . . . . . . . . . . . . . 7
4.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 9 5. Common Implementations . . . . . . . . . . . . . . . . . . . 8
4.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 9
5. Operators' Typical Processing . . . . . . . . . . . . . . . . 9 5.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 9
6. New Services . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Typical Processing . . . . . . . . . . . . . . . . . . . . . 9
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 7. New Services . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Migration Strategies . . . . . . . . . . . . . . . . . . . . 11 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Migration Strategies . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Due to historical reasons, such as incapable ASICs, limited IPv6 Due to historical reasons, such as incapable ASICs, limited IPv6
deployments, and few service requirements, the most common Hop-by-Hop deployments, and few service requirements, the most common Hop-by-Hop
Options header (HBH) processing implementation is that the node sends Options header (HBH) processing implementation is that the node sends
the IPv6 packets with the Hop-by-Hop Options header to the control the IPv6 packets with the Hop-by-Hop Options header to the control
plane of the node. The option type of each option carried within the plane of the node. The option type of each option carried within the
Hop-by-Hop Options header will not even be examined before the packet Hop-by-Hop Options header will not even be examined before the packet
skipping to change at page 4, line 13 skipping to change at page 4, line 13
way without impacting the management plane. way without impacting the management plane.
* Ease the deployments of the new HBH based network services in a * Ease the deployments of the new HBH based network services in a
multi-vendor scenario that can now be deployed without operational multi-vendor scenario that can now be deployed without operational
impact. impact.
In this draft, the reasons why the HBH is rarely used within networks In this draft, the reasons why the HBH is rarely used within networks
will be documented and a proper list of requirements aiming to allow will be documented and a proper list of requirements aiming to allow
a better leverage of the HBH capability will be defined. a better leverage of the HBH capability will be defined.
2. Modern Router Architecture 2. Terminology
The Forwarding Plane and Control Plane used in this draft can refer
to the same terminologies as defined in
[I-D.ietf-6man-hbh-processing], respectively.
3. Modern Router Architecture
Modern router architecture design maintains a strict separation of Modern router architecture design maintains a strict separation of
the router control plane and its forwarding plane [RFC6192], as shown the router control plane and its forwarding plane [RFC6192], as shown
in Figure 1. Either the control plane or the forwarding plane is in Figure 1. Either the control plane or the forwarding plane is
composed of both software and hardware, but each plane is responsible composed of both software and hardware, but each plane is responsible
for different functions. In this draft, we focus on only the routers for different functions. In this draft, we focus on only the routers
following the architecture as shown in Figure 1 and those being following the architecture as shown in Figure 1 and those being
deployed in the network rather than those at home. deployed in the network rather than those at home.
+----------------+ +----------------+
skipping to change at page 6, line 39 skipping to change at page 6, line 39
the separation between the forwarding and control planes. In this the separation between the forwarding and control planes. In this
case HBH control options would be required to be punted to control case HBH control options would be required to be punted to control
plane by fixed function ASICs as well as NPUs. plane by fixed function ASICs as well as NPUs.
The maximum length of an HBH Options header is 2,048 bytes. A source The maximum length of an HBH Options header is 2,048 bytes. A source
node can encode hundreds of options in 2,048 bytes node can encode hundreds of options in 2,048 bytes
[I-D.herbert-6man-eh-limits]. With today's technology it would be [I-D.herbert-6man-eh-limits]. With today's technology it would be
cost prohibitive to be able to process hundreds of options with cost prohibitive to be able to process hundreds of options with
either NPU or proprietary fixed function ASIC. either NPU or proprietary fixed function ASIC.
While [RFC2460] required that all nodes must examine and process the As per [RFC8200], it is now expected that nodes along a packet's
Hop-by-Hop Options header, it is now expected that nodes along a delivery path only examine and process the Hop-by-Hop Options header
packet's delivery path only examine and process the Hop-by-Hop if explicitly configured to do so. This can be beneficial in cases
Options header if explicitly configured to do so [RFC8200]. This can where transit nodes are legacy hardware and the destination endpoint
be beneficial in cases where transit nodes are legacy hardware and PE is newer NPU based hardware that can process HBH in the forwarding
the destination endpoint PE is newer NPU based hardware that can plane.
process HBH in the forwarding plane.
IPv6 Extended Header limitations that need to be addressed to make IPv6 Extended Header limitations that need to be addressed to make
HBH processing more efficient and viable in the forwarding plane: HBH processing more efficient and viable in the forwarding plane:
[RFC8504] defines the IPv6 node requirements and how to protect a [RFC8504] defines the IPv6 node requirements and how to protect a
node from excessive header chain and excessive header options with node from excessive header chain and excessive header options with
various limitations that can be defined on a node. [RFC8883] defines various limitations that can be defined on a node. [RFC8883] defines
ICMPv6 Errors for discarding packets due to processing limits. Per ICMPv6 Errors for discarding packets due to processing limits. Per
[RFC8200] HBH options must be processed serially. However, an [RFC8200] HBH options must be processed serially. However, an
implementation of options processing can be made to be done with more implementation of options processing can be made to be done with more
parallelism in serial processing grouping of similar options to be parallelism in serial processing grouping of similar options to be
processed in parallel. processed in parallel.
The IPv6 standard does not currently limit the header chain length or The IPv6 standard does not currently limit the header chain length or
number of options that can be encoded. number of options that can be encoded.
Each Option is encoded in a TLV and so processing of a long list of Each Option is encoded in a TLV and so processing of a long list of
TLVs is expensive. Zero data length encoded options TLVs are a valid TLVs is expensive. Zero data length encoded options TLVs are a valid
option. A DOS vector could be easily generated by encoding 1000 HBH option. A DOS vector could be easily generated by encoding 1000 HBH
options (Zero data length) in a standard 1500 MTU packet. So now options (Zero data length) in a standard 1500 MTU packet. So now
imagine if you have a Christmas tree long header chain to parse each imagine if you have a Christmas tree long header chain to parse each
with many options. with many options.
3. Specification of RFC 8200 4. Specification of RFC 8200
[RFC8200] defines several IPv6 extension header types, including the [RFC8200] defines several IPv6 extension header types, including the
Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop-
by-Hop (HBH) Options header is used to carry optional information by-Hop (HBH) Options header is used to carry optional information
that will be examined and processed by every node along a packet's that will be examined and processed by every node along a packet's
delivery path, and it is identified by a Next Header value of zero in delivery path, and it is identified by a Next Header value of zero in
the IPv6 header. the IPv6 header.
The Hop-by-Hop (HBH) Options header contains the following fields: The Hop-by-Hop (HBH) Options header contains the following fields:
skipping to change at page 8, line 5 skipping to change at page 8, line 5
The Hop-by-Hop (HBH) Options header carries a variable number of The Hop-by-Hop (HBH) Options header carries a variable number of
"options" that are encoded in the format of type-length-value (TLV). "options" that are encoded in the format of type-length-value (TLV).
The highest-order two bits (i.e., the ACT bits) of the Option Type The highest-order two bits (i.e., the ACT bits) of the Option Type
specify the action that must be taken if the processing IPv6 node specify the action that must be taken if the processing IPv6 node
does not recognize the Option Type. The third-highest-order bit does not recognize the Option Type. The third-highest-order bit
(i.e., the CHG bit) of the Option Type specifies whether or not the (i.e., the CHG bit) of the Option Type specifies whether or not the
Option Data of that option can change en route to the packet's final Option Data of that option can change en route to the packet's final
destination. destination.
While [RFC2460] required that all nodes must examine and process the As per [RFC8200], it is now expected that nodes along a packet's
Hop-by-Hop Options header, it is now expected that nodes along a delivery path only examine and process the Hop-by-Hop Options header
packet's delivery path only examine and process the Hop-by-Hop if explicitly configured to do so. It means that the HBH processing
Options header if explicitly configured to do so [RFC8200]. It means behavior in a node depends on its configuration.
that the HBH processing behavior in a node depends on its
configuration.
However, in the current [RFC8200], there is no explicit specification However, in the current [RFC8200], there is no explicit specification
of the possible configurations. Therefore, the nodes may be of the possible configurations. Therefore, the nodes may be
configured to ignore the Hop-by-Hop Options header, drop packets configured to ignore the Hop-by-Hop Options header, drop packets
containing a Hop-by-Hop Options header, or assign packets containing containing a Hop-by-Hop Options header, or assign packets containing
a Hop-by-Hop Options header to the control plane [RFC8200]. Because a Hop-by-Hop Options header to the control plane [RFC8200]. Because
of these likely uncertain processing behaviors, new hop-by-hop of these likely uncertain processing behaviors, new hop-by-hop
options are not recommended. options are not recommended.
4. Common Implementations 5. Common Implementations
In the current common implementations, once an IPv6 packet, with its In the current common implementations, once an IPv6 packet, with its
Next Header field set to 0, arrives at a node, it will be directly Next Header field set to 0, arrives at a node, it will be directly
sent to the control plane of the node. With such implementations, sent to the control plane of the node. With such implementations,
the value of the Next Header field in the IPv6 header is the only the value of the Next Header field in the IPv6 header is the only
trigger for the default processing behavior. The option type of each trigger for the default processing behavior. The option type of each
option carried within the Hop-by-Hop Options header will not even be option carried within the Hop-by-Hop Options header will not even be
examined before the packet is sent to the control plane. examined before the packet is sent to the control plane.
Very often, such processing behavior is the default configuration on Very often, such processing behavior is the default configuration on
skipping to change at page 9, line 17 skipping to change at page 9, line 13
adjacent inter-as operators that only use underlay global Internet adjacent inter-as operators that only use underlay global Internet
routing table. In an operator closed domain where MPLS VPN overlay routing table. In an operator closed domain where MPLS VPN overlay
is utilized to carry internet traffic, the operator has full control is utilized to carry internet traffic, the operator has full control
of the underlay and IPv6 Extended header chain length as well as the of the underlay and IPv6 Extended header chain length as well as the
number of HBH options encoded. number of HBH options encoded.
In the global routing table scenario for Internet traffic there is no In the global routing table scenario for Internet traffic there is no
way to control the IPv6 Extended header chain length as well as the way to control the IPv6 Extended header chain length as well as the
number of HBH options encoded. number of HBH options encoded.
4.1. Historical Reasons 5.1. Historical Reasons
When IPv6 was first implemented on high-speed routers, HBH options When IPv6 was first implemented on high-speed routers, HBH options
were not yet well-understood and ASICs were not as capable as they were not yet well-understood and ASICs were not as capable as they
are today. So, early IPv6 implementations dispatched all packets are today. So, early IPv6 implementations dispatched all packets
that contain HBH options to their control plane. that contain HBH options to their control plane.
4.2. Consequences 5.2. Consequences
Such implementation introduces a risk of a DoS attack on the control Such implementation introduces a risk of a DoS attack on the control
plane of the node, and a large flow of IPv6 packets could congest the plane of the node, and a large flow of IPv6 packets could congest the
control plane, causing other critical functions (including routing control plane, causing other critical functions (including routing
and network management) that are executed on the control plane to and network management) that are executed on the control plane to
fail. Rate limiting mechanisms will cause inconsistent packet drops fail. Rate limiting mechanisms will cause inconsistent packet drops
and impact the normal end-to-end IP forwarding of the network and impact the normal end-to-end IP forwarding of the network
services. services.
5. Operators' Typical Processing 6. Typical Processing
To mitigate this DoS vulnerability, many operators deployed Access To mitigate this DoS vulnerability, many operators deployed Access
Control Lists (ACLs) that discard all packets containing HBH Options. Control Lists (ACLs) that discard all packets containing HBH Options.
[RFC6564] shows the Reports from the field indicating that some IP [RFC6564] shows the Reports from the field indicating that some IP
routers deployed within the global Internet are configured either to routers deployed within the global Internet are configured either to
ignore or to drop packets having a hop-by-hop header. As stated in ignore or to drop packets having a hop-by-hop header. As stated in
[RFC7872], many network operators perceive HBH Options to be a breach [RFC7872], many network operators perceive HBH Options to be a breach
of the separation between the forwarding and control planes. of the separation between the forwarding and control planes.
Therefore, several network operators configured their nodes so as to Therefore, several network operators configured their nodes so as to
discard all packets containing the HBH Options Extension Header, discard all packets containing the HBH Options Extension Header,
while others configured nodes to forward the packet but to ignore the while others configured nodes to forward the packet but to ignore the
HBH Options. [RFC7045] also states that hop-by-hop options are not HBH Options. [RFC7045] also states that hop-by-hop options are not
handled by many high-speed routers or are processed only on a control handled by many high-speed routers or are processed only on a control
plane. plane. [I-D.vyncke-v6ops-james] shows that the HBH options header
cannot reliably traverse the global Internet; only small headers with
'skipable' options have some chances.
Due to such behaviors observed and described in these specifications, Due to such behaviors observed and described in these specifications,
new hop-by-hop options are not recommended in [RFC8200] hence the new hop-by-hop options are not recommended in [RFC8200] hence the
usability of HBH options is severely limited. usability of HBH options is severely limited.
6. New Services Besides service providers' networks, other sectors such as industrial
IoT networks are slowly replacing a dozen of semi-proprietary
protocols in industrial automation into IP. The proper processing of
the HBH options header is also required.
7. New Services
As IPv6 is being rapidly and widely deployed worldwide, more and more As IPv6 is being rapidly and widely deployed worldwide, more and more
applications and network services are migrating to or directly applications and network services are migrating to or directly
adopting IPv6. More and more new services that require HBH are adopting IPv6. More and more new services that require HBH are
emerging and the HBH Options header is going to be utilized by the emerging and the HBH Options header is going to be utilized by the
new services in various scenarios. new services in various scenarios.
In-situ OAM (IOAM) with IPv6 encapsulation In-situ OAM (IOAM) with IPv6 encapsulation
[I-D.ietf-ippm-ioam-ipv6-options] is one of the examples. IOAM in [I-D.ietf-ippm-ioam-ipv6-options] is one of the examples. IOAM in
IPv6 is used to enhance diagnostics of IPv6 networks and complements IPv6 is used to enhance diagnostics of IPv6 networks and complements
skipping to change at page 10, line 50 skipping to change at page 10, line 51
As more services start utilizing the HBH Options header, more packets As more services start utilizing the HBH Options header, more packets
containing HBH Options are going to be injected into the networks. containing HBH Options are going to be injected into the networks.
According to the current common configuration in most network According to the current common configuration in most network
deployments, all the packets of the new services are going to be sent deployments, all the packets of the new services are going to be sent
to the control plane of the nodes, with the possible consequence of to the control plane of the nodes, with the possible consequence of
causing a DoS on the control plane. The packets will be dropped and causing a DoS on the control plane. The packets will be dropped and
the normal IP forwarding may be severely impacted. The deployment of the normal IP forwarding may be severely impacted. The deployment of
new network services involving multi-vendor interoperability will new network services involving multi-vendor interoperability will
become impossible. become impossible.
7. Requirements 8. Requirements
* The HBH options header SHOULD NOT become a possible DDoS Vector. * The HBH options header SHOULD NOT become a possible DDoS Vector.
Therefore, the control plane MUST be preserved from unwanted Therefore, the control plane MUST be preserved from unwanted
incoming traffic due to HBH header present in the packet. incoming traffic due to HBH header present in the packet.
* HBH options SHOULD be designed in a manner so that they don't * HBH options SHOULD be designed in a manner so that they don't
reduce the probability of packet delivery. reduce the probability of packet delivery.
* HBH processing MUST be efficient. That is, it MUST be possible to * HBH processing MUST be efficient. That is, it MUST be possible to
produce implementations that perform well at a reasonable cost produce implementations that perform well at a reasonable cost
without endanger the security of the router. without endanger the security of the router.
skipping to change at page 11, line 26 skipping to change at page 11, line 26
HBH options that should be processed more quickly. HBH options that should be processed more quickly.
* HBH Options MAY influence how a packet is forwarded. However, * HBH Options MAY influence how a packet is forwarded. However,
with the exception of the Router Alert Option, an HBH Option MUST with the exception of the Router Alert Option, an HBH Option MUST
NOT cause control plane state to be created, modified or destroyed NOT cause control plane state to be created, modified or destroyed
on the processing node. As per [RFC6398], protocol developers on the processing node. As per [RFC6398], protocol developers
SHOULD avoid future use of the Router Alert Option. SHOULD avoid future use of the Router Alert Option.
* More requirements are to be added. * More requirements are to be added.
8. Migration Strategies 9. Migration Strategies
In order to make the HBH options header usable and facilitate the In order to make the HBH options header usable and facilitate the
ever-emerging new services to be deployed across multiple vendors' ever-emerging new services to be deployed across multiple vendors'
devices, the new HBH header scheme, SHOULD allow a smooth migration devices, the new HBH header scheme, SHOULD allow a smooth migration
from old to new behavior without disruption time. Also, co-existence from old to new behavior without disruption time. Also, co-existence
between old and news scheme MUST be possible. between old and news scheme MUST be possible.
9. Security Considerations 10. Security Considerations
The same as the Security Considerations apply as in [RFC8200] for the The same as the Security Considerations apply as in [RFC8200] for the
part related with the HBH Options header. part related with the HBH Options header.
10. IANA Considerations 11. IANA Considerations
This document does not include an IANA request. This document does not include an IANA request.
11. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge Ron Bonica, Fred Baker, Bob The authors would like to acknowledge Ron Bonica, Fred Baker, Bob
Hinden, Stefano Previdi, and Donald Eastlake for their valuable Hinden, Stefano Previdi, and Donald Eastlake for their valuable
review and comments. review and comments.
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-00, 29 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-6man-hbh-
processing-00.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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/info/rfc6192>. March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>. 2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, of IPv6 Extension Headers", RFC 7045,
skipping to change at page 12, line 42 skipping to change at page 12, line 45
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
12.2. Informative References 13.2. Informative References
[I-D.herbert-6man-eh-limits] [I-D.herbert-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6 Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft, Extension Headers", Work in Progress, Internet-Draft,
draft-herbert-6man-eh-limits-00, 22 June 2021, draft-herbert-6man-eh-limits-00, 22 June 2021,
<https://www.ietf.org/archive/id/draft-herbert-6man-eh- <https://www.ietf.org/archive/id/draft-herbert-6man-eh-
limits-00.txt>. limits-00.txt>.
[I-D.ietf-6man-ipv6-alt-mark] [I-D.ietf-6man-ipv6-alt-mark]
Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate Marking Method", Pang, "IPv6 Application of the Alternate Marking Method",
Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
alt-mark-10, 14 September 2021, alt-mark-13, 31 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-alt- <https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-alt-
mark-10.txt>. mark-13.txt>.
[I-D.ietf-6man-mtu-option] [I-D.ietf-6man-mtu-option]
Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU
Hop-by-Hop Option", Work in Progress, Internet-Draft, Hop-by-Hop Option", Work in Progress, Internet-Draft,
draft-ietf-6man-mtu-option-11, 30 September 2021, draft-ietf-6man-mtu-option-14, 15 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-6man-mtu- <https://www.ietf.org/archive/id/draft-ietf-6man-mtu-
option-11.txt>. option-14.txt>.
[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>.
[I-D.vyncke-v6ops-james]
Vyncke, É., Léas, R., and J. Iurman, "Just Another
Measurement of Extension header Survivability (JAMES)",
Work in Progress, Internet-Draft, draft-vyncke-v6ops-
james-01, 19 March 2022, <https://www.ietf.org/archive/id/
draft-vyncke-v6ops-james-01.txt>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999, RFC 2711, DOI 10.17487/RFC2711, October 1999,
<https://www.rfc-editor.org/info/rfc2711>. <https://www.rfc-editor.org/info/rfc2711>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>. <https://www.rfc-editor.org/info/rfc8250>.
 End of changes. 33 change blocks. 
62 lines changed or deleted 84 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/