INTERNET-DRAFT T. Herbert Intended Status: Proposed Standard Intel Expires: March 2020 September 24, 2019 IPv4 Hop-by-Hop Options and Destination Options Extension Headers draft-herbert-ipv4-hbh-destopt-00 Abstract This specification enables the use of Hop-by-Hop Options and Destination Options extension headers which are defined for IPv6 to be used with IPv4. The goal is to provide a uniform and feasible method of extensibility that is common between IPv4 and IPv6. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of T. Herbert Expires March 27, 2020 [Page 1] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Enabling IPv4 extension headers . . . . . . . . . . . . . . 4 2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Option format . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Extension header formats . . . . . . . . . . . . . . . . . . 6 2.2.1 Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6 2.2.2 Destination Options Header . . . . . . . . . . . . . . . 6 2.3 Extension Header Order . . . . . . . . . . . . . . . . . . . 6 2.4 Experimental options . . . . . . . . . . . . . . . . . . . . 7 3 ICMP errors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 7 3.2 Destination Unreachable codes . . . . . . . . . . . . . . . 9 4 Requirements and operation . . . . . . . . . . . . . . . . . . 10 4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Interaction with standard IPv4 mechanisms . . . . . . . . . 11 4.2.1 IPv4 options . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2 IPv4 fragmentation . . . . . . . . . . . . . . . . . . . 11 4.3 Processing limits . . . . . . . . . . . . . . . . . . . . . 11 5 Deployability . . . . . . . . . . . . . . . . . . . . . . . . . 12 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Protocol descriptions . . . . . . . . . . . . . . . . . . . 13 7.2 IPv4 Parameters registry . . . . . . . . . . . . . . . . . . 13 7.3 ICMP parameters . . . . . . . . . . . . . . . . . . . . . . 15 7.3.1 Parameter Problem codes . . . . . . . . . . . . . . . . 15 7.3.2 Destination Unreachable codes . . . . . . . . . . . . . 15 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 T. Herbert Expires March 27, 2020 [Page 2] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 1 Introduction This specification enables the Hop-by-Hop Options and Destination Options extension headers which are defined for IPv6 to be used with IPv4. The goal is to provide an extensible mechanism in IPv4 that is unified with IPv6 and facilitates leveraging common protocol and implementation for extensibility between the two versions of the Internet Protocol. Hop-by-Hop Options and Destination Options extension headers are defined in [RFC8200]. The respective IP protocol numbers, 0 and 60, are defined for use with IPv6 as Next Header values, but are reserved for IPv4 and are not valid values in the IPv4 Protocol field. This document permits the use of protocol numbers 0 and 60 in the IPv4 protocol field and defines the semantics of processing Hop-by-Hop Options and Destination Options extension headers in the context of IPv4. Note that the use of the Hop-by-Hop Options and Destination Options protocol numbers the IPv4 Protocol field effectively designates the field to be the IPv4 Next Header field. The use of extension headers in IPv4 is not without precedent. Both the Authentication header (AH, protocol number 51) [RFC4302] and Encapsulating Security Payload (ESP, protocol number 50) [RFC4303] are defined for use with IPv4. Note that this specification only enables the use of Hop-by-Hop Options and Destination Options extension headers in IPv4. It does not define the use of any other extension headers with IPv4 including the Routing Header and Fragmentation Header. 1.1 Motivation IPv6 is intended to become the standard protocol of the Internet, however it is clear that there is a large segment of users that will be using IPv4 for the foreseeable future. This is particularly true in many enterprises where a business case for transitioning to IPv6 hasn't yet emerged [V6STATE]. In lieu of sun-setting IPv4 and expecting all users to move to IPv6 in some time frame that is unlikely to be met, this specification suggests an alternative to enable the extensibility mechanisms of IPv6 in IPv4. The rationale for this is two fold: 1) Users benefit from forward looking features being actively defined and developed for IPv6 without requiring them to first transition to IPv6. T. Herbert Expires March 27, 2020 [Page 3] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 2) In making IPv4 look more like IPv6, the work required to complete a future transition to IPv6 may be reduced or simplified. Various proposals that would use Hop-by-Hop Options or Destination Options are currently being developed in IETF. These include Path MTU Option [MTUOPT], In-situ OAM [IOAM], Service-aware IPv6 Network [SAIN], and Firewall and Service Tickets [FAST]. These proposals leverage the extensibility mechanisms of extension headers defined for IPv6. These proposals, in some form, could be of value for use with IPv4. Unfortunately, IPv4 does not define a mechanism that meets reasonable requirements for extensibility. IP options are quite limited and have long been considered obsolete. There have been proposals for encoding host to network signaling in UDP (e.g. [SPUD], IOAM over encapsulation in Geneve [IOAMGEN]), however these are shown to neither be generic nor robust especially in the case that encapsulated data must be modified in flight [RFC7605]. The proposal in this document is to enable IPv4 packets to carry Hop- by-Hop Options and Destination Options extension headers in the same manner that IPv6 does. In doing so, the various options defined for IPv6 can be used with IPv4 to the benefit of the user. It is expected that in many cases, such as the IOAM and Path MTU options, options are protocol agnostic and would be applicable to use in IPv4 with little or no change. In other cases, particularly when an option carries an IP address, the options might be defined to be IPv6 specific and require some adaptation to work with IPv4. 1.2 Enabling IPv4 extension headers IPv4 options were defined in [RFC0791] as the means of extending the IP protocol. IPv4 options have not been successful. Early router implementations, and even those today, either don't process IPv4 options or relegate them to a slow path effectively making them unusable for serious applications. IPv4 options are limited to forty bytes length and, unlike TCP options, no IP options have been defined that are critical to communications. The upshot is that IPv4 options have long not been considered an option for deployment [IPNOOP]. IPv6 took a different approach. Extensibility of IPv6 is provided by extension headers. Optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet [RFC8200]. IPv6 extension headers have had mixed success in deployment in that some intermediate devices have trouble processing them [RFC7872], however there are several active proposals in IETF that would make use of them (e.g. [FAST], T. Herbert Expires March 27, 2020 [Page 4] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 [MTUOPT], [IOAM], [SRV6EH]). Using extension headers with IPv4 is logically straightforward. The IPv4 Protocol field is effectively re-designated to be a Next Header field with the same meaning and semantics as the IPv6 Next Header field. In this manner, an IPv4 packet can contain IPv6 extension headers that are recast as IPv4 extension headers. This specification describes the use of Hop-by-Hop Options and Destination Options extension headers in IPv4. A number of ICMP errors may be sent when an error condition is encountered in processing extension headers. The relevant ICMPv6 errors are defined in [RFC4443] and [ICMPLIM]. This specification adapts these ICMPv6 errors for use in IPv4. 2 Format IPv4 extension headers are optional internet-layer information encoded in separate headers that may be placed between the IPv4 header and the upper-layer header in a packet. IPv4 Hop-by-Hop Options and Destination Options extension headers are based on the corresponding IPv6 extension headers and share the same basic properties and semantics [RFC8200]. As illustrated in these examples, an IPv4 packet MAY carry zero, one, or more extension headers, each identified by Protocol field of the IPv4 header or the Next Header field of a preceding extension header: +---------------+------------------------ | IPv4 header | TCP header + data | | | Protocol = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | IPv4 header | Hop-by-Hop | TCP header + data | | | | Protocol = | Next Header = | | Hop-by-Hop | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv4 header | Hop-by-Hop | Destination Opt | TCP | | | | header + data | Protocol = | Next Header = | Next Header = | | Hop-by-Hop | DestOpt | TCP | +---------------+----------------+-----------------+----------------- T. Herbert Expires March 27, 2020 [Page 5] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 2.1 Option format The format and processing of options in IPv4 Hop-by-Hop Options and Destination Options extension headers is the same as that defined for IPv6 options in section 4.2 of [RFC8200] with the following modifications: * In the case that an option is unrecognized by a receiver and the highest-order 2 bits specify that an ICMP error should be sent (values of 10 and 11) then an ICMPv4 Parameter Problem, Code 5 is sent (see section 3). Note that PAD1 and PADN are defined for IPv4 Hop-by-Hop Options and Destination Options with the same format and semantics as defined for IPv6. 2.2 Extension header formats 2.2.1 Hop-by-Hop Options The format of the IPv4 Hop-by-Hop Options extension header is the same as the corresponding format of IPv6 Hop-by-Hop Options defined in section 4.3 of [RFC8200] with the following modifications: * The Next Header field MUST contain a protocol number that is defined to be usable with IPv4 or 60 (IPv4 Destination Options extension header). 2.2.2 Destination Options Header The format of the IPv4 Destination Options extension header is the same as the corresponding format of IPv6 Destination Options defined in section 4.6 of [RFC8200] with the following modifications: * The Next Header field MUST contain a protocol number that is defined to be usable with IPv4 or 60 (IPv4 Destination Options extension header). 2.3 Extension Header Order When more than one IPv4 extension header is used in the same packet, it is RECOMMENDED that those headers appear in the following order: IPv4 header Hop-by-Hop Options header Destination Options header (note 1) Authentication header (note 2) Encapsulating Security Payload header (note 2) T. Herbert Expires March 27, 2020 [Page 6] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 Upper-Layer header note 1: unlike IPv6, routing headers are not defined for IPv4 so there is no distinction between Destination Options that appear before or after the routing header. note 2: additional recommendations regarding the relative order of the Authentication and Encapsulating Security Payload headers are given in [RFC4303]. 2.4 Experimental options This document assigns a single option type for experimental purposes, with all possible values of the "act" and "chg" fields, resulting in eight distinct option type codes. These are the same values defined for experimental Hop-by-Hop and Destination Options in IPv6 [RFC4727]. Experimental IPv4 Hop-by-Hop Options and Destination Options Types are: HEX act chg rest ---- --- --- ----- 0x1e 00 0 11110 0x3e 00 1 11110 0x5e 01 0 11110 0x7e 01 1 11110 0x9e 10 0 11110 0xbe 10 1 11110 0xde 11 0 11110 0xfe 11 1 11110 3 ICMP errors ICMP errors are defined to be sent in response to errors that occur in processing extension headers. Six ICMPv4 Parameter Problem codes are defined and one ICMPv4 Destination Unreachable code is defined. These codes are adaptations of ICMPv6 codes defined in [RFC4443] and [ICMPLIM]. 3.1 Parameter Problem codes The format for ICMP Parameter Problem errors related to extension headers employs a multi-part ICMPv4 message format as defined in [RFC4884]. The extended structure contains a pointer to the octet beyond the limit. T. Herbert Expires March 27, 2020 [Page 7] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 The format of the ICMPv4 Parameter Problem for extension headers is: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + leading octets of original datagram | | | | // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Header Fields: Destination Address Copied from the Source Address field of the invoking packet. ICMPv4 Fields: Type 12 (Parameter Problem Message) Code (pertinent to this specification) 3 - Erroneous header field encountered 4 - Unrecognized Next Header type encountered 5 - Unrecognized IPv4 option encountered 6 - Extension header too big 7 - Extension header chain too long 8 - Too many options in extension header 9 - Option too big Length Length of the padded "original datagram" field, measured in 32- bit words. Pointer Identifies the octet offset within the invoking packet where the error was detected. Codes 3, 4, and 5 are analogues of Parameter Problem codes 0, 1, and 2 defined for IPv6 in [RFC4443]. Operation and semantics of these T. Herbert Expires March 27, 2020 [Page 8] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 codes are the same as their counterparts in [RFC4443] with the following modifications: * The multi-part ICMP format of [RFC4884] is used and its fields are set appropriately. * The pointer to the offending byte in the invoking packet is contained in the 32 bit Pointer field in the extended format. Codes 6, 7, 8, and 9 are analogues of Parameter Problem codes 4, 5, 6, and 7 defined for IPv6 in [ICMPLIM]. Operation and semantics of these codes are the same as their counterparts in [ICMPLIM] with the following modifications: * The multi-part ICMP format of [RFC4884] is used and its fields are set appropriately. * The pointer to the offending byte in the invoking packet is contained in the 32 bit Pointer field in the extended format. 3.2 Destination Unreachable codes This specification defines one IPv4 Destination Unreachable code for aggregate header limits being exceeded as described in [ICMPLIM]. The error for aggregate header limits employs a multi-part ICMPv4 message format as defined in [RFC4884]. The extended structure contains a pointer to the octet beyond the limit. The format of the ICMPv4 message for an aggregate header limit exceeded is: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + leading octets of original datagram | | | | // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T. Herbert Expires March 27, 2020 [Page 9] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 IPv4 Header Fields: Destination Address Copied from the Source Address field of the invoking packet. ICMPv4 Fields: Type 3 (Destination Unreachable Message) Code (pertinent to this specification) 16 - Headers too long Length Length of the padded "original datagram" field, measured in 32- bit words. Pointer Identifies the octet offset within the invoking packet where the error was detected. Code 16 is an analogue of Destination Unreachable code 8 defined in [ICMPLIM]. Operation and semantics of the code should be the same as the counterpart in [ICMPLIM]. 4 Requirements and operation 4.1 Requirements IPv4 Hop-by-Hop and Destination Options extension headers normatively assume the requirements of IPv6 extension headers as defined in [RFC8200] section 4, with the following modifications: * References to the IPv6 header are replaced by references to the IPv4 header. * ICMP errors sent in the course of processing Hop-by-Hop Options and Destination Options extension headers use ICMPv4 instead of ICMPv6. Applicable ICMPv4 errors for extension header processing are specified in section 3. * The IPv4 header Protocol field assumes the same role and semantics with respect to extension headers as the IPv6 Next Header field. * The Hop-by-Hop Options header is used to carry optional information that MAY be examined and processed by any node along T. Herbert Expires March 27, 2020 [Page 10] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 a packet's delivery path. * If a legacy IPv4 destination node, one that does not support IPv4 Hop-by-Hop Options or Destination Options extension headers, receives a packet with those extension headers then the packet will be processed as having an unknown protocol. It is expected that the packet will be discarded and an ICMP error may be generated. * References to the Payload Length are reinterpreted as being the computed IPv4 payload length (i.e. IPv4 Total Length minus the length of the IPv4 header). 4.2 Interaction with standard IPv4 mechanisms IPv4 Hop-by-Hop Options and Destination Options extension headers may be used concurrently with IPv4 mechanisms such as IPv4 options and IPv4 fragmentation. This section discusses the interactions. 4.2.1 IPv4 options An IPv4 packet MAY contain both IPv4 options and Hop-by-Hop Options or Destination Options extension headers. IPv4 options are completely independent of IPv4 extension headers. IPv4 options MUST be processed before processing any extension headers per normal requirements of processing the IP header before the IP payload. 4.2.2 IPv4 fragmentation A packet containing Hop-by-Hop Options and Destination Options extension headers may be fragmented using standard IPv4 fragmentation. At a destination, if a received packet was fragmented by standard IPv4 fragmentation, it MUST be reassembled before processing any IPv4 extension headers. If an IPv4 packet containing Hop-by-Hop Options is fragmented using standard IPv4 fragmentation, the Hop-by-Hop Options are not set in each of the packet fragments. An intermediate node MAY process the Hop-by-Hop options in the first fragment if the complete Hop-by-Hop extension header is contained within the fragment. 4.3 Processing limits Section 5.3 of [RFC8504] describes the use of limits in processing extension headers in order to protect a node from excessive extension header options. These limits are adapted for use with IPv4 extension T. Herbert Expires March 27, 2020 [Page 11] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 headers. The requirements in [ICMPLIM] for sending and processing ICMP errors related to processing limits are applicable. A node MAY impose limits on processing IPv4 Destination Options and Hop-by-Hop Options extension headers. This includes limits on length or number of consecutive padding options, disallowing unknown options, and limits on the number of options or length of options. If a limit is exceeded in processing a received packet, the packet is discarded and an appropriate ICMP error SHOULD be sent (Section 3, [ICMPLIM]). A node MAY allow configuration of different limits for processing IPv4 and IPv6 options. The default limits for IPv4 are assumed to be the same as those defined for IPv6 in [RFC8504]. 5 Deployability If a legacy host device receives an IPv4 packet with IPv4 Hop-by-Hop Options or Destination extension headers, the packet will be treated as having an unknown protocol and should dropped. Intermediate nodes might also observe to packets with a protocol number that is unrecognized and will forward the packet inasmuch as they would forward any packet with an unknown protocol. In the public Internet, it is well known that there are some intermediate nodes that will drop packets with protocols that are unknown to them (firewalls would commonly to this for instance). Therefore, it is unlikely that packets with IPv4 Hop-by-Hop Options or Destination Options extension headers can be ubiquitously deployed over the Internet. In a limited domain [LIMDOM], an operator would have control over intermediate nodes and could ensure that at a minimum they properly forward packets with IPv4 extension headers. Routers in a limited domain can be updated to process IPv4 Hop-by-Hop Options provide the functionality of features like IOAM. T. Herbert Expires March 27, 2020 [Page 12] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 6 Security Considerations This specification enables use of Hop-by-Hop Options and Destination Options extension headers in IPv4. Related security mechanisms of IPv6 extension headers can be applied for use with IPv4 extension headers. 7 IANA Considerations 7.1 Protocol descriptions IANA is requested to change the descriptions of the Hop-by-Hop Options and Destination Options extension headers to reflect that they are not IPv6 specific. In the "Assigned Internet Protocol Numbers Registry", the modified protocols descriptions are: +----------+---------+------------+-----------+--------------------+ | Decimal | Keyword | Protocol | IPv6 | Reference | | | | | Extension | | | | | | header | | +----------+---------+------------+-----------+--------------------+ | 0 | HOPOPT | Hop-by-Hop | | [RFC8200][RFCXXXX] | | | | Option | | [This document] | +----------+---------+------------+-----------+--------------------+ | 60 | Opts | Destination| | [RFC8200][RFCXXXX] | | | | Options | | [This document] | +----------+---------+------------+-----------+--------------------+ 7.2 IPv4 Parameters registry IANA is requested to create a parameters registry in "Internet Protocol Version 4 (IPv4) Parameters". This registry contains the assigned IPv4 Hop-by-Hop Options and Destination Options numbers. The description of the registry shall contain: Name: Destination Options and Hop-by-Hop Options Registration Procedure(s): IESG Approval, IETF Review or Standards Action Reference: This specification Note: From (This specification) IPv4 Option Types are 8-bit values, structured as three subfields, are defined in Section 4.2 of [RFC8200]. T. Herbert Expires March 27, 2020 [Page 13] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 Each distinct 8-bit Option Type identifies a different option, i.e., the high-order 3 bits are considered part of the option identification. However, it is recommended that Option Types be assigned with distinct values in the "rest" subfield, until and unless that 5-bit space becomes full. Available Formats: For each option number, the value, description, and document reference are listed. The value is provided in both hexadecimal as well as binary. The binary value is split into action, change, and rest bits which refer to the semantics of the three high-order bits of the Option Type. The initial set of assigned IPv4 Option Types are: +----------+---------------+-------------------+-----------------+ |Hex value | Binary value | Description | Reference | | | act chg rest | | | +----------+---------------+-------------------+-----------------+ | 0x00 | 00 0 00000 | Pad1 | [This document] | | | | | [RFC8200] | +----------+---------------+-------------------+-----------------+ | 0x01 | 00 0 00001 | PadN | [This document] | | | | | [RFC8200] | +----------+---------------+-------------------+-----------------+ | 0x1e | 00 0 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ | 0x3e | 00 1 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ | 0x5e | 01 0 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ | 0x7e | 01 1 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ | 0x9e | 10 0 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ | 0xbe | 10 1 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ | 0xde | 11 0 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ | 0xfe | 11 1 11110 | Experimental | [This document] | +----------+---------------+-------------------+-----------------+ T. Herbert Expires March 27, 2020 [Page 14] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 7.3 ICMP parameters 7.3.1 Parameter Problem codes IANA is requested to assign the following codes in "ICMP Type Numbers" for type 12 "Parameter Problem": 3 - Erroneous header field encountered 4 - Unrecognized Next Header type encountered 5 - Unrecognized IPv4 option encountered 6 - Extension header too big 7 - Extension header chain too long 8 - Too many options in extension header 9 - Option too big 7.3.2 Destination Unreachable codes IANA is requested to assign the following codes in "ICMP Type Numbers" for type 3 "Destination Unreachable": 16 - Headers too long T. Herbert Expires March 27, 2020 [Page 15] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 8 References 8.1 Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . 8.2 Informative References [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, . [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, . [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, . [RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, . [V6STATE] B. Kuerbis and M. Mueller, Internet Governance Project, "The Hidden Standards War: Economic Factors Affecting IPv6 Deployment", February, 2019. [SRV6EH] C. Filsfils, Ed., S. Previdi, J. Leddy, S. Matsushima, D. T. Herbert Expires March 27, 2020 [Page 16] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 Voyer, Ed., "IPv6 Segment Routing Header (SRH)", draft- ietf-6man-segment-routing-header-22 [CRH] Bonica, R., So, N., Xu, F., Chen, G., Zhu, Y., Yang, G., Zhou, Y., "The IPv6 Compressed Routing Header (CRH)" draft- bonica-6man-comp-rtg-hdr-03 [MTUOPT] Hinden, R. and Fairhurst, G., "IPv6 Minimum Path MTU Hop- by-Hop Option", draft-hinden-6man-mtu-option-00 [IOAM] F. Brockners, S. Bhandari, V. Govindan, C. Pignataro, H. Gredler, J. Leddy, S. Youell, T. Mizrahi, D. Mozes, P. Lapukhov, R. Chang, "Encapsulations for In-situ OAM Data" draft-brockners-inband-oam-transport-05 [SAIN] Li, Z. and Peng, S., "Service-aware IPv6 Network", draft- li-6man-service-aware-ipv6-network-00 [FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert- fast-03 [SPUD] Hildebrbrand, J. and Trammell, B., Substrate Protocol for User Datagrams (SPUD) Prototype, draft-hildebrand-spud- prototype-03 [IOAMGEN] Brockners, F. et al., "Geneve encapsulation for In-situ OAM Data", draft-brockners-ippm-ioam-geneve-01 [IPNOOP] Rodrigo Fonseca, George Manning Porter, Randy H. Katz, Scott Shenker and Ion Stoica, "IP Options are not an option", [ICMPLIM] Herbert, T., "ICMPv6 errors for discarding packets due to processing limits", draft-ietf-6man-icmp-limits-01 [IANA-PN] IANA, "Protocol Numbers", . [IANA-EH] IANA, "IPv6 Extension Header Types", . [LIMDOM] Carpenter, B., and Liu, B., "Limited Domains and Internet Protocols", draft-carpenter-limited-domains-06 T. Herbert Expires March 27, 2020 [Page 17] INTERNET DRAFT draft-herbert-ipv4-hbh-destopt-00 September 24, 2019 Author's Address Tom Herbert Intel Santa Clara, CA, USA USA Email: tom@herbertland.com T. Herbert Expires March 27, 2020 [Page 18]