INTERNET-DRAFT Tom Herbert
Intended Status: Standard Quantonium
Expires: March 10, 2019
September 14, 2018
Updates to Requirements for IPv6 Options
draft-herbert-ipv6-update-opts-00
Abstract
This document updates requirements for IPv6 Destination and Hop-by-
Hop Options. The requirements that option type and option length
cannot change en route, as well as the requirements that options
cannot be added or removed, are made explicit. The meaning and
requirements of a Destination Option marked as changeable are
clarified. Finally, the requirement that all destinations listed in a
Routing header must process options in a Destination Options header
preceding the Routing header is relaxed.
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) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Herbert Expires March, 2019 [Page 1]
INTERNET DRAFT draft-herbert-ipv6-update-opts-00 September 14, 2018
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
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
2 Requirements for adding, removing, or changing options . . . . 4
3 Requirements for changeable Destination Options . . . . . . . . 4
4 Requirements for processing Destination Options . . . . . . . . 5
5 Detecting that Destination Options precede a Routing header . . 5
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1 Normative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Herbert Expires March, 2019 [Page 2]
INTERNET DRAFT draft-herbert-ipv6-update-opts-00 September 14, 2018
1 Introduction
[RFC8200] defines Hop-by-Hop and Destination Options. This document
clarifies requirements for changing, adding, or removing options in a
packet en route to its final destination. It also relaxes the
requirement that Destination Options preceding a Routing header must
be processed by all destinations listed in the Routing header.
[RFC8200] specifies that "The third-highest-order bit of the Option
Type specifies whether or not the Option Data of that option can
change en route to the packet's final destination." It is implicit in
this requirement that neither the Option Type nor Option Data Length
can change en route to the packet's destination. It also follows that
options cannot be added or removed while a packet is en route. This
document makes these requirements explicit.
Per [RFC8200], Destination Options may be marked as changeable (the
third-highest-order bit of the Option Type for the Destination Option
is set). [RFC8200] also states that with the exception of Hop-by-Hop
options, extension headers are not processed except by the
destination node. It follows that the only possible case that a
Destination Option may be modified en route is by a node that is one
of destinations to be visited in a Routing header. This document
clarifies this requirement.
Per [RFC8200], if a Destination Options header precedes a Routing
header, then all of the destinations listed in the Routing header
must process the Destination Options. This document proposes to relax
that requirement by allowing nodes listed in the Routing header to
ignore Destination Options that precede the Routing header. The
motivation for this is similar to that of relaxing the requirement
that all intermediate nodes process Hop-by-Hop options in [RFC8200].
Intermediate destination nodes may be closer in taxonomy to switches
and routers than end hosts, so it follows that they may have similar
processing constraints in efficiently processing extension headers
and TLVs. Those constraints could lead to similar ad hoc behaviors
for processing packets with options-- some implementations have
dropped packets with options, others have relegated them to slow path
processing. In any case, such behaviors at even a few nodes can
essentially render options unusable. Allowing nodes to ignore options
retains the primary value and usability of Destination Options
preceding a Routing header. Nodes that are not interested in them can
ignore them, nodes that fully support them can process them.
Herbert Expires March, 2019 [Page 3]
INTERNET DRAFT draft-herbert-ipv6-update-opts-00 September 14, 2018
2 Requirements for adding, removing, or changing options
This section clarifies requirements of [RFC8200] for changing,
adding, or removing Destination Options or Hop-by-Hop Options.
The Option Type of an option MUST NOT be changed en route to a
packet's final destination. Note that this precludes changing the
high order bits of an Option Type which indicate a changeable option
or the action to take for an unknown option.
The Option Data Length of an option MUST NOT be changed en route to a
packet's final destination. If the third-highest-order bit of the
Option Type is set indicating that the Option Data can change en
route, then any changes MUST be to the existing Option Data and the
Option Length MUST be preserved. Note, if the Option Data Length is
zero then the option cannot be modified in any way.
Options MUST NOT be added to or removed from a packet en route to its
final destination. This requirement precludes adding or removing
options within an existing extension header, as well as adding or
removing a Destination or Hop-by-Hop extension headers in a packet.
Note that in the case that a routing header is present, the "final
destination" refers to the final destination listed to visit in the
routing header. At intermediate destinations of a routing header, the
packet is considered en route to the final destination, so that
requirements about changing a packet en route to its final
destination are applicable.
3 Requirements for changeable Destination Options
If a Destination Option in a Destination Options header that precedes
a Routing header is marked as changeable (the third-highest order bit
of the option type is set), then the Option Data may be changed by
any destination node en route to the final destination. Specifically,
the node for the initial destination address as well as any nodes to
visit as listed in the Routing header may change the Option Data.
If a Destination Option is marked as changeable (the third-highest
order bit of the option type is set) and is in a Destination Options
header that follows a Routing header, or there is no Routing header
present, then the Option Data cannot be changed en route. There are
no nodes in the path that are permitted to change the Option Data.
Note that the requirement when an Authentication header is present
the entire Option Data field must be treated as zero-valued octets
when computing or verifying the packet's authenticating value is
still applicable.
Herbert Expires March, 2019 [Page 4]
INTERNET DRAFT draft-herbert-ipv6-update-opts-00 September 14, 2018
4 Requirements for processing Destination Options
This section clarifies requirements of processing Destination Options
with respect to its relationship to a Routing header.
Options in a Destination Options header that follow a Routing header,
or are in a packet having no Routing header, MUST be processed by the
destination node. In the case that a Routing header is present, the
Destination Options that follow the Routing header MUST be processed
by the final destination listed in the Routing header.
Options in a Destination Options header that precede a Routing header
MAY be examined or processed by the original destination node and
nodes listed to visit in the Routing header (including the final
destination of the Routing Header). If a node does not process the
options in a Destination Option header, then it MUST skip over the
Destination Options header and continue to process the next header
which is likely the Routing header.
5 Detecting that Destination Options precede a Routing header
As specified in requirements of this document, an implementation
might process Destination Options differently depending on whether
they precede a Routing header. Procedures are therefore needed to
detect if Destination Options precede a Routing header.
An implementation MAY determine that Destination Options precede a
Routing Header by inspecting the Next Header field of the Destination
Option. If the Next Header field indicates a Routing Header, then the
implementation can conclude that Destination Options precede a
Routing Header. Note that this employs a heuristic based on the
recommended ordering of extension headers of [RFC8200] in which the
Routing header should immediately follow Destination Options before a
Routing header.
An implementation MAY scan the packet to determine if a Routing
header is present that follows a Destination Options header. If such
a scan is performed, an implementation MUST NOT process any scanned
extension headers beyond inspecting their Next Header and Header Ext
Length fields. This requirement is necessary ensure that extension
headers are strictly processed order as manadated by [RFC8200].
If a node is not able to determine that Destination Options precede a
Routing header, the Destinations Options MUST be processed as though
they do not precede a Routing header. In this case, a destination
node, regardless whether it is an intermediate or final destination,
MUST process the Destination Options and MUST NOT change any
Destination Options even if they are marked as changeable.
Herbert Expires March, 2019 [Page 5]
INTERNET DRAFT draft-herbert-ipv6-update-opts-00 September 14, 2018
6 Security Considerations
Relaxing the requirement that Destination Options preceding a Routing
header can be ignored by intermediate destination nodes should not
pose any new security risk. It should be noted that any security
mechanism specified in a Destination Option should take into account
that not all intermediate destinations would necessarily process the
security option.
7 IANA Considerations
There are no IANA considerations in this specification.
8 References
8.1 Normative References
[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>.
Author's Address
Tom Herbert
Quantonium
Santa Clara, CA
USA
Email: tom@quantonium.net
Herbert Expires March, 2019 [Page 6]