INTERNET-DRAFT T. Herbert
Intended Status: Proposed Standard Quantonium
Expires: November 2019
May 2, 2019
IPv4 Extension Headers and Flow Label
draft-herbert-ipv4-eh-01
Abstract
This specification defines extension headers for IPv4 and a
definition of an IPv4 flow label. The goal is to provide a uniform
and feasible method of extensibility that is shared 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 November 3, 2019 [Page 1]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 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 IPv4 extension headers . . . . . . . . . . . . . . . . . . . 4
1.3 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . 5
2 IPv4 extension headers . . . . . . . . . . . . . . . . . . . . 5
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 General requirements . . . . . . . . . . . . . . . . . . 6
2.1.2 Fragmentation and reassembly requirements . . . . . . . 7
2.2 Interaction with standard IPv4 mechanisms . . . . . . . . . 7
2.2.1 IPv4 options and IPv4 extension headers . . . . . . . . 8
2.2.2 IPv4 fragmentation and IPv4 extension headers . . . . . 8
2.2.3 Atomic datagram recommendation . . . . . . . . . . . . . 8
2.3 ICMP errors . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Parameter Problem codes . . . . . . . . . . . . . . . . 9
2.3.2 Destination Unreachable codes . . . . . . . . . . . . . 10
2.4 Processing limits . . . . . . . . . . . . . . . . . . . . . 11
2.5 No Next Header . . . . . . . . . . . . . . . . . . . . . . . 12
3 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Sender requirements . . . . . . . . . . . . . . . . . . . . 12
3.2 Receiver requirements . . . . . . . . . . . . . . . . . . . 13
4 Deployability . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 14
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Protocol descriptions . . . . . . . . . . . . . . . . . . . 14
6.2 Parameter Problem codes . . . . . . . . . . . . . . . . . . 15
6.2 Destination Unreachable codes . . . . . . . . . . . . . . . 15
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Normative References . . . . . . . . . . . . . . . . . . . 16
7.2 Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
T. Herbert Expires November 3, 2019 [Page 2]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
1 Introduction
This specification defines extension headers for IPv4 as well as an
IPv4 flow label. The motivation is to provide an extensible mechanism
in IPv4 that is unified with IPv6 and thus leverages common protocol
and implementation for extensibility between the two versions of the
Internet Protocol.
The extension headers defined for IPv6 in [RFC8200], specifically
Hop-by-Hop Options, Destination Options, Routing Header, and Fragment
Header, are permitted for use with IPv4 (note that Authentication
Header and Encapsulating Security Payload are already usable with
IPv4). Additionally, No Next Header (protocol number 59) is defined
to be usable in IPv4 packets.
The IPv4 flow label is similarly derived from the definition of the
IPv6 flow label. There is no flow label defined in the IPv4 header
[RFC791], however under specific circumstances the sixteen bit
Identification field may safely be used as a flow label.
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 which is to improve IPv4. However the nature
of these improvements is very specific, the idea is to "backport"
useful features of IPv6 into IPv4. Essentially, this makes IPv4 look
more like IPv6. 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
transition to IPv6.
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 IPv6 extensions are currently being
discussed in IETF. These include Segment Routing [SRHV6], Compressed
Routing Header [CRH], Path MTU Option [MTUOPT], In-situ OAM [IOAM],
Service-aware IPv6 Network [SAIN], and Firewall and Service Tickets
[FAST]. These proposals leverage the extensibility mechanism of
T. Herbert Expires November 3, 2019 [Page 3]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
extension headers defined for IPv6. All of these proposals, in some
form, could be of value for use with IPv4. Unfortunately, IPv4 does
not have an extensibility mechanism that meets the requirements for
supporting them. 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 like
Geneve [IOAMGEN]), however these are shown to neither be generic nor
robust especially in the case that encapsulated data must be modified
in flight.
The proposal contained in this document is to enable IPv4 packets to
carry the extension headers in the same manner that IPv6 packets can
carry extension headers. In doing so, the various extensions for IPv6
can be used with IPv4 to the benefit of the user. In many cases (such
as IOAM and Path MTU option), the extension being defined is protocol
agnostic and would be applicable and usable with IPv4 with little or
no change. In other cases, such as segment routing, the extension
might be IPv6 specific, for example the segment routing header
contains a list of IPv6 addresses. With some modification to the
extension definition, it is also conceivable that these may work with
IPv4. For instance, in the case of segment routing, the extension can
be adapted for use with IPv4 by defining a routing header format that
contains IPv4 addresses instead of IPv6 addresses.
1.2 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],
[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
T. Herbert Expires November 3, 2019 [Page 4]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
headers that are recast as IPv4 extension headers. These include Hop-
by-Hop Options, Routing Header, Fragment, Destination Options,
Authentication, and Encapsulating Security Payload. In cases where an
extension header contains IPv6 specific information, the extension
header can be adapted for use with IPv4. For instance, a Routing
Header carrying IPv6 addresses to visit could be adapted to carry
IPv4 addresses.
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.
1.3 The IPv4 flow label
IPv6 [RFC8200] introduced the concept of a flow label that has proven
quite convenient to perform flow classification, such as that needed
by Equal-Cost Multipath (ECMP). The base IPv4 header does not have
reserved bits that could be allocated as a flow label, however the
sixteen bit Identification field can be used as a flow label in
atomic datagrams [RFC6864].
2 IPv4 extension headers
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 extension headers
are based on IPv6 extension headers and share the same basic
properties and semantics [RFC8200].
Extension headers are numbered from IANA IP Protocol Numbers [IANA-
PN], the same values are used for IPv4 and IPv6. When processing a
sequence of Next Header values in a packet, the first one that is not
an extension header [IANA-EH] indicates that the next item in the
packet is the corresponding upper-layer header. A special "No Next
Header" value is used if there is no upper-layer header.
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:
T. Herbert Expires November 3, 2019 [Page 5]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
+---------------+------------------------
| 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 | Fragment header | fragment of TCP
| | | | header + data
| Protocol = | Next Header = | Next Header = |
| Hop-by-Hop | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
2.1 Requirements
2.1.1 General requirements
IPv4 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 extension headers
use ICMPv4 instead of ICMPv6. Applicable ICMPv4 errors for
extension header processing are specified in section 2.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
a packet's delivery path.
* If a legacy IPv4 destination node, one that does not support
IPv4 extension headers, receives a packet with 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
T. Herbert Expires November 3, 2019 [Page 6]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
error may be generated.
* Extension headers or options that carry IPv6 specific data or
are otherwise specific to IPv6 MUST NOT be used with IPv4
(Segment Routing [SRV6EH] for example). IPv4 variants of these
may be defined if achieving the same functionality in IPv4 is
desirable.
* References to the Payload Length, for instance in reassembly
procedures, are reinterpreted as being the computed IPv4 payload
length (i.e. IPv4 Total Length minus the length of the IPv4
header).
2.1.2 Fragmentation and reassembly requirements
The following are modifications to fragmentation and reassembly
requirements:
* References to setting the Payload Length field in the IPv6
header are interpreted to be setting the Total Length in the
IPv4 header taking into account the IPv4 header length.
* When creating or modifying IPv4 headers in packets, the IPv4
header checksum MUST be set correctly.
* Different fragment packets MAY contain different IPv4 options.
In the reassembled packet, the IP options are taken from the
first fragment packet (the one with offset of zero).
* Different fragment packets MAY contain different extension
headers preceding the fragment header. In the reassembled
packet, the extension headers preceding the fragment header are
taken from the first fragment packet (the one with offset of
zero).
* If the length and offset of a fragment are such that the Total
Length of the packet reassembled from that fragment would exceed
65,535 octets, then that fragment must be discarded and an ICMP
Parameter Problem, Code 0, message should be sent to the source
of the fragment, pointing to the Fragment Offset field of the
fragment packet.
2.2 Interaction with standard IPv4 mechanisms
IPv4 extension headers may be used concurrently with IPv4 mechanisms
such as IPv4 options and IPv4 fragmentation. This section discusses
the interactions.
T. Herbert Expires November 3, 2019 [Page 7]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
2.2.1 IPv4 options and IPv4 extension headers
An IPv4 packet MAY contain both IPv4 options and 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.
2.2.2 IPv4 fragmentation and IPv4 extension headers
An IPv4 packet MAY be fragmented both by using a Fragment extension
header as well as by standard IPv4 fragmentation. The Fragment header
can only be set at the source, however intermediate devices can
fragment packets using standard IPv4 fragmentation. Standard IPv4
fragmentation at a source node MUST be done only after any extension
headers are set in a packet or the packet was fragmented using the
Fragment header. Specifically, fragmentation using the extension
header MUST NOT be done on packet fragments created by standard IPv4
fragmentation. However, a packet fragment that contains a Fragment
header MAY itself be fragmented by standard IPv4 fragmentation. There
is no correlation between standard IPv4 fragmentation and the IPv4
Fragment header, the identifier space for each are unrelated and
reassembly procedures are independent.
At a destination, if a received packet was fragmented by standard
IPv4 fragmentation, it MUST be reassembled before processing any IPv4
extension headers. This requirement ensures that standard IPv4
reassembly is done before reassembly for the Fragment header.
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. If the Fragment
header is used with IPv4 then the DF bit (Don't Fragment) bit SHOULD
be set and Path MTU discovery mechanisms SHOULD be used.
2.2.3 Atomic datagram recommendation
It is RECOMMENDED to only use IPv4 extensions in atomic datagrams.
Atomic datagrams [RFC6864] are IPv4 packets for which the Don't
Fragment bit set, More Fragment bit is not set, and Fragment Offset
is zero. In this case the packet will not be subject to IPv4
fragmentation, the Fragment header can alternatively be used for
fragmentation.
T. Herbert Expires November 3, 2019 [Page 8]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
2.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 Destination Unreachable code is defined. These
codes are adaptations of ICMPv6 codes defined in [RFC4443] and
[ICMPLIM].
2.3.1 Parameter Problem codes
The format for ICMP Parameter Problem errors related to extension
header 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 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 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
T. Herbert Expires November 3, 2019 [Page 9]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
6 - Extension header too big
7 - Extension header chain too long
8 - Too many options in extension header
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
codes are the same as their counterparts in [RFC4443] with the
following differences:
* 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, and 8 are analogues of Parameter Problem codes 4, 5, and
6 defined for IPv6 in [ICMPLIM]. Operation and semantics of these
codes are the same as their counterparts in [RFC4443] with the
following differences:
* 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.
2.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:
T. Herbert Expires November 3, 2019 [Page 10]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
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 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
[ICMP6LIM]. Operation and semantics of the code should be the same as
the counterpart in [ICMP6LIM].
2.4 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
headers.
T. Herbert Expires November 3, 2019 [Page 11]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
A node MAY impose limits on processing IPv4 extension headers and
Destination and Hop-by-Hop options. 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 defined in Section 2.3 SHOULD be sent.
A node MAY allow configuration of different limits for processing
IPv4 and IPv6 options. The default limits for IPv4 are assumed to be
those defined in [RFC8504].
2.5 No Next Header
The value 59 may be set in the Protocol field of the IPv4 header or
in Next Header field of an IPv4 extension header. This indicates that
there is nothing following that header. The semantics of setting this
value are the same as that described in [RFC8200] with adaptation for
use with IPv4. If the Total Length field of the IPv4 header indicates
the presence of octets past the end of a header whose Next Header
field contains 59, those octets must be ignored and passed on
unchanged if the packet is forwarded.
3 The IPv4 flow label
The Identification field of the IPv4 header is re-purposed to be the
IPv4 flow label in atomic datagrams. As stated in [RFC6864]:
">> Originating sources MAY set the IPv4 ID field of atomic
datagrams to any value."
This specification allows the IPv4 ID to be used as a flow label in
atomic datagrams where (DF==1)&&(MF==0)&&(frag_offset==0).
3.1 Sender requirements
An origin host MAY set the IPv4 Identification field as a flow label
in atomic datagram packets. The IPv4 flow label is set following the
same procedures for setting the IPv6 flow label as described in
[RFC6437] with the following modifications:
* The Identification field MUST only be used as a flow label in
atomic datagrams. That is Don't Fragment (DF) bit MUST be set,
More Fragment (MF) bit MUST NOT be set, and Fragment Offset MUST
be zero.
* If the IPv4 Identification field is not used as a flow label in
atomic fragments, the Identification field MUST be set to zero.
T. Herbert Expires November 3, 2019 [Page 12]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
* Only stateless flow labels can be set.
* The value to set, e.g. from a hash computation over packet
headers, is truncated to sixteen bits (the size of the
Identification field).
* Intermediate nodes MUST NOT set the Identification field in
atomic datagrams.
3.2 Receiver requirements
Receivers, including intermediate hosts, MAY process a non-zero
Identification field in the IPv4 header of atomic datagrams as being
a flow label. The IPv4 flow label for instance can be used as input
to ECMP as described in [RFC6438].
If the Identification field is zero or the packet is not an atomic
datagram (either the More Fragment bit is set, the Don't Fragment bit
is not set, or Fragment Offset is non-zero) then the Identification
field MUST NOT be considered as a flow label.
4 Deployability
If a legacy host device receives an IPv4 packet with IPv4 extension
headers, the packet will be treated as having an unknown protocol and
should dropped. Intermediate devices might also see packets with a
protocol unknown to them and will forward the packet inasmuch as they
would forward any packet with an unknown protocol.
In the 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 extension headers can be ubiquitously
deployed over the Internet. A workaround to this might be to
encapsulate extension headers in UDP [EHUDPENCAP].
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 or Routing
headers to provide the functionality of features like IOAM and
Segment Routing in IPv4. Similarly, they could be updated to support
the IPv4 flow label to provide flow based ECMP in the same manner
that the IPv6 flow label is used for ECMP [RFC6438].
T. Herbert Expires November 3, 2019 [Page 13]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
5 Security Considerations
This specification enables use of IPv6 extension headers in IPv4.
Related security mechanisms of IPv6 extension headers can be applied
for use with IPv4 extension headers.
The IPv4 flow label has similar security properties as the IPv6 flow
label.
6 IANA Considerations
6.1 Protocol descriptions
IANA is requested to change the descriptions of IPv6 extension
headers and No Next Header protocol numbers 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] |
+----------+---------+------------+-----------+--------------------+
| 43 | Route | Routing | | [Steve_Deering] |
| | | Header | | [This document] |
+----------+---------+------------+-----------+--------------------+
| 44 | Frag | Fragment | | [Steve_Deering] |
| | | Header | | [This document] |
+----------+---------+------------+-----------+--------------------+
| 59 | NoNxt | No Next | | [RFC8200][RFCXXXX] |
| | | Header | | [This document] |
+----------+---------+------------+-----------+--------------------+
| 60 | Opts | Destination| | [RFC8200][RFCXXXX] |
| | | Options | | [This document] |
+----------+---------+------------+-----------+--------------------+
IANA is requested to update "Internet Protocol Version 4 (IPv4)
Parameters" to include sections for "IPv6 Extension Header Types",
"Destination Options and "Hop-by-Hop Options", and "Routing Types".
These are based on the similarly named sections in "Internet Protocol
Version 6 (IPv6) Parameters" with appropriate modifications for IPv4.
T. Herbert Expires November 3, 2019 [Page 14]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
6.2 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
6.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 November 3, 2019 [Page 15]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
7 References
7.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, <https://www.rfc-
editor.org/info/rfc8200>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for
Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
7.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,
<https://www.rfc-editor.org/info/rfc7872>.
[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, <https://www.rfc-
editor.org/info/rfc4443>.
[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, <https://www.rfc-
editor.org/info/rfc4884>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/info/rfc7605>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
T. Herbert Expires November 3, 2019 [Page 16]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
"IPv6 Flow Label Specification", RFC 6437, DOI
10.17487/RFC6437, November 2011, <https://www.rfc-
editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for
Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[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.
Voyer, Ed., "IPv6 Segment Routing Header (SRH)", draft-
ietf-6man-segment-routing-header-16
[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",
<https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-
2005-24.html>
T. Herbert Expires November 3, 2019 [Page 17]
INTERNET DRAFT draft-herbert-ipv4-eh-01 May 2, 2019
[ICMPLIM] Herbert, T., "ICMPv6 errors for discarding packets due to
processing limits", draft-ietf-6man-icmp-limits-01
[IANA-PN] IANA, "Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers>.
[IANA-EH] IANA, "IPv6 Extension Header Types",
<https://www.iana.org/assignments/ipv6-parameters>.
[LIMDOM] Carpenter, B., and Liu, B., "Limited Domains and Internet
Protocols", draft-carpenter-limited-domains-06
Author's Address
Tom Herbert
Quantonium
Santa Clara, CA
USA
Email: tom@quantonium.net
T. Herbert Expires November 3, 2019 [Page 18]