Internet-Draft HBH Options Processing December 2020
Hinden & Fairhurst Expires 6 June 2021 [Page]
Network Working Group
8200 (if approved)
Intended Status:
Standards Track
R. Hinden
Check Point Software
G. Fairhurst
University of Aberdeen

IPv6 Hop-by-Hop Options Processing Procedures


This document specifies procedures for how IPv6 Hop-by-Hop options are processed. It modifies the procedures specified in the IPv6 Protocol Specification (RFC8200) to make processing in routers more practical with the goal of making IPv6 Hop-by-Hop options useful to deploy in the Internet. When published, this document updates RFC8200.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 June 2021.

Table of Contents

1. Introduction

This document specifies procedures for how IPv6 Hop-by-Hop options are processed. It modifies the procedures specified in the IPv6 Protocol Specification (RFC8200) to make processing in routers more practical with the goal of making IPv6 Hop-by-Hop options useful to deploy in the Internet.

When published this document updates [RFC8200].

The current list of defined Hop-by-Hop options can be found at [IANA-HBH].

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

This document uses the following loosely defined terms:

4. Background

In the first version of the IPv6 specification, Hop-by-Hop options were required to be processed by all nodes, routers and hosts. This proved to not be practical in high speed routers due to several factors, including:

When the IPv6 Specification was updated and published in July 2017 as [RFC8200], the procedures relating to hop-by-hop options are as follows:

The changes meant that an implementation complied with the IPv6 specification even if it did not process hop-by-hop options, and that it was expected that routers would add configuration information to control which hop-by-hop options they would process.

Unfortunately, this did not improve the processing of Hop-by-Hop options and they are often not possible to be deployed and used in the Internet. It merely documented how they were being used in the Internet.

In hindsight, hop-by-hop options were still not practical to be used widely in the Internet. Many operational routers are configured to drop all packets containing a hop-by-hop option header. The main issues remain:

There has been some academic research that discussed the general problem with dropping packets containing IPv6 extension headers, including the Hop-by-Hop Options header. For example [Hendriks] states that "dropping all packets with Extension Headers, is a bad practice", and that "The share of traffic containing more than one EH however, is very small. For the design of hardware able to handle the dynamic nature of EHs, we therefore recommend to support at least one EH"

This document defines a set of procedures for the hop-by-hop option header that make the processing of hop-by-hop options practical in modern transit routers.

5. Hop-by-Hop Header Processing Procedures

This section describes three sets of changes to [RFC8200].

5.1. Hop-by-Hop Options Per Packet

The Hop-by-Hop Option Header as defined in Section 4.3 of [RFC8200] is identified by a Next Header value of 0 in the IPv6 header. Section 4.1 requires a Hop-by-Hop Options header to appear immediately after the IPv6 header. [RFC8200] also requires that a Hop-by-Hop Options header can only appear once in a packet.

The Hop-by-Hop Options Header as defined in [RFC8200] can contain one or more Hop-by-Hop options. This document updates [RFC8200] such that there MUST only be one option contained in an Hop-by-Hop Options header in a single packet. The motivation for this change is to simplify the processing of Hop-by-Hop options in the fast path.

Nodes creating packets with a Hop-by-Hop option headers MUST only include a single option in the packet. This also requires that all Hop-by-Hop Options MUST be 8-octet aligned. See Section 6 for more detail.

Nodes processing a packet with a Hop-by-Hop options header MUST discard the packet if there is more than one Hop-by-Hop option in that header.

5.2. Hop-by-Hop Headers Processing

Section 4.2 of [RFC8200] defines an Option Type field in options that controls how the option is processed if the IPv6 node processing the option header does not recognize the Option Type. This document modifies that behavior for options carried in an Hop-by-Hop Option header in two ways.

IPv6 nodes MUST only process an Hop-by-Hop Options header if it can be done in the fast path of the router. If the IPv6 node can not process the Hop-by-Hop Option header in the fast path is MUST skip over this option and continue processing the header normally.

Section 4.2 of [RFC8200] defines the Option Type identifiers as internally encoded such that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. This document modifies this behaviour for Hop-by-Hop options as follows:

    00 - skip over this option and continue processing the header.

    01 - discard the packet.

    10 - discard the packet.

    11 - discard the packet.

The motivation for this change is to simplify what the router needs to do in the fast path when it can not recognize the Option Type. It is no longer required to send ICMP Parameter Problem messages.

5.3. Configuration

Section 4 of [RFC8200] allows for a router to control it's processing of IPv6 Hop-by-Hop options by local configuration. The text is:

  • NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so.

A possible approach to implementing this is to maintain a lookup table based on Option Type of the IPv6 options that are supported in the fast path. This would allow for a node to quickly determine if an option is supported and can be processed. If the option is not supported, then the node processes it as described in Section 5.2 of this document.

The actions of the lookup table SHOULD be configurable by the operator of the router.

6. Hop-by-Hop Option Header Alignment

[RFC8200] requires all extension headers to be 8-octet aligned. The text from Section 4 is:

Two types of Pad options are defined to keep this alignment, that is Pad1 and PadN, if the options in an Destination Option Header or Hop-by-Hop Option Header do not result in 8-octet alignment.

This document requires all Hop-by-Hop Options to be 8-octet aligned (see Section 5.1). This eliminates the need for Pad options to be used in the Hop-by-Hop Option header to make them 8-octet aligned.

The current list of defined Destination and Hop-by-Hop options can be found at [IANA-HBH].

The following sections list current Hop-by-Hop Options that meet the alignment requirement defined here (Section 6.1) or if they need to be be deprecated or modified (Section 6.2). Hop-by-Hop Options that have been deprecated, and Destination Options are listed separately in Section 6.3. Pad Options (Pad1 and PadN), and RFC3692-style Experiment options are not listed.

6.1. Hop-by-Hop Options that Meet Alignment Requirement

The following Hop-by-Hop Options meet the alignment requirements defined in this section:

*** Note: Need to verify that these options are 8-octet aligned.

6.2. Hop-by-Hop Options that Must be Deprecated or Modified

The Hop-by-Hop Options listed in this section do not meet the alignment requirements defined in this section. They either need to be deprecated or modified to support 8-octet alignment without the use of Pad options. If there is interest in modifying them, it should be straightforward to make them have 8-octet alignment.

6.3. Destination Options and Deprecated Hop-by-Hop Options

The options listed in this section are either Destination Options or Deprecated Hop-by-Hop Options. 8-octet alignment is not an issue.

  • Tunnel Encapsulation Limit [RFC2473]
  • RPL Option (DEPRECATED) [RFC6553]
  • Endpoint Identification (DEPRECATED) [CHARLES LYNN]
  • MPL Option (DEPRECATED) [RFC7731]
  • Home Address [RFC6275]
  • Line-Identification Option [RFC6788]
  • Performance and Diagnostic Metrics (PDM) [RFC8250]

7. New Hop-by-Hop Options

Any new IPv6 Hop-by-Hop option defined in the future should have 8-octet alignment without the use of any Pad options. This requirement modifies Section 4.8 of [RFC8200].

8. IANA Considerations

This draft has no actions for the IANA.

9. Security Considerations


10. Acknowledgments

Helpful comments were received from Brian Carpenter, Ron Bonica, Ole Troan, [your name here], and other members of the 6MAN working group.

11. Change log [RFC Editor: Please remove]

draft-hinden-6man-hbh-processing-00, 2020-Nov-29: Initial draft.

12. Normative References

"Destination Options and Hop-by-Hop Options", <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <>.

13. Informative References

Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. Aiko, "Threats and Surprises behind IPv6 Extension Headers", , , , <>.
Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-by-Hop Option", Work in Progress, Internet-Draft, draft-ietf-6man-mtu-option-04, , <>.
Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. Smith, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-04, , <>.
Robles, I., Richardson, M., and P. Thubert, "Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane", Work in Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-42, , <>.
Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, , <>.
Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, , <>.
Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, , <>.
Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, , <>.
StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI 10.17487/RFC5570, , <>.
Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, , <>.
Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, , <>.
Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, , <>.
Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, , <>.
Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, , <>.
Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. Nordmark, "The Line-Identification Option", RFC 6788, DOI 10.17487/RFC6788, , <>.
Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. Cespedes, "Depth-First Forwarding (DFF) in Unreliable Networks", RFC 6971, DOI 10.17487/RFC6971, , <>.
Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, , <>.
Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, , <>.

Authors' Addresses

Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
United States of America
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
AB24 3UE
United Kingdom