A uniform two-field (Next Header + Hdr Ext Len) prefix for all new extension headers allows middleboxes and routers to skip over unknown headers without parsing their internals, minimizing breakage in the existing deployed base.

ip

Destination options are preferred over new extension headers because they provide more flexible handling characteristics and better backward compatibility; existing infrastructure can process destination options without requiring ASIC updates.

ip

Hop-by-hop behavior is discouraged for new extension headers because some deployed Internet routers are configured to either ignore or drop packets containing headers with hop-by-hop behavior, and such headers can be subverted to create attacks on routers that process them.

ip, security

Several deployed IPv6 routers and firewalls, contrary to RFC 2460, parse past or ignore all currently defined extension headers at wire speed using custom ASICs. Any new extension header not following a predictable format risks breaking these deployed capabilities.

ip

The uniform format proposed in this document is not backward compatible with all currently defined IPv6 extension headers; it applies only to newly defined extension headers. The IPv6 fragment header predates this document and does not follow this format.

ip

Any IPv6 extension headers defined in the future MUST use the consistent format defined in Figure 1 (Next Header, Hdr Ext Len, Header Specific Data), to minimize breakage in intermediate nodes.

ip

Any proposal to create a new option for the existing Hop-by-Hop Header MUST include a detailed explanation of why the hop-by-hop behavior is absolutely essential.

ip, process

Any proposal to create or specify a new IPv6 extension header MUST include a detailed technical explanation of why no existing IPv6 extension header can be used.

ip, process

Implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs.

ip

New IPv6 extension headers having hop-by-hop behavior MUST NOT be created or specified, due to the risk of packet drops and router attacks in the public Internet.

ip, security

New IPv6 extension headers MUST NOT be created or specified unless no existing IPv6 extension header can be used by specifying a new option for that existing header.

ip, process

New optional information to be sent SHOULD be encoded in a new option for the existing IPv6 Destination Options header rather than in a new extension header.

ip

New options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative solution is feasible.

ip

The request for creation of a new IPv6 extension header MUST be accompanied by a specific explanation of why destination options could not be used to convey the information.

ip, process

The Hdr Ext Len field is an 8-bit unsigned integer giving the length of the extension header in 8-octet units, not including the first 8 octets.

ip

The Next Header field is an 8-bit selector that identifies the type of header immediately following the extension header, using the same values as the IPv4 Protocol field per IANA IP Parameters.

ip

Intermediate nodes such as firewalls that skip over unknown extension headers (using the uniform format to traverse them) might allow the setup of a covert channel from outside to inside the firewall using the data fields of those unknown headers.

ip, security

All new IPv6 extension headers must begin with an 8-bit Next Header selector (same values as IPv4 Protocol field) followed by an 8-bit Hdr Ext Len field (length in 8-octet units, not including the first 8 octets), followed by variable-length Header Specific Data.

ip