| < 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/ | ||||