On Tue, 6 Aug 2013, Mark Andrews wrote:
> http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt
This is an interesting draft and I see that it attempts to offer a
fairly complete solution, covering not just TCP and UDP but ICMP and
tunneled IPv4 and IPv6. The idea is to put L4 information missing
in 2nd and subsequent framgments into IPv6 options, thereby making
it readily available to stateless filtering devices, load balancers,
and the like.
One significant concern that jumps out at me is that the option(s)
defined in this draft are hop-by-hop options. Quoting from
draft-ietf-6man-ext-transmit Section 2.2:
However, it is to be expected that high performance routers will
either ignore it, or assign packets containing it to a slow
processing path. Designers planning to use a Hop-by-Hop option
need to be aware of this likely behaviour.
To me it seems highly undesirable to risk putting one's traffic on
the slow path of a core router, especially when the L4 information
is probably not needed there, but in middleboxes closer to the edge.
However, I don't see any reason why these options could not go into
a destination options header. The standard order in RFC 2460
(excluding Mobility and Shim6 headers) would work,
IPv6 header
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
upper-layer header
though "note 1" would need to be changed as follows:
note 1: for options to be processed by the first destination
that appears in the IPv6 Destination Address field
plus subsequent destinations listed in the Routing
header or by forwarding nodes needing to inspect
options containing layer 4 header information.
There is precedent for refinement to the placement of Destination
Options headers; see, e.g., RFC 6275 and the Home Address Option.
In answer to to the open questions, I would suggest using a single
option code and making the protocol explicit. The strategy of
leaving the protcol implicit leads to ambigiuities (e.g., between
TCP, UDP, and UDP-lite). I would also suggest judicious use of
padding to align 4 and 8 bytes quantities on natural boundaries.
Mike Heard
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
