On Mon, 19 Aug 2013, C. M. Heard wrote:
> On Tue, 6 Aug 2013, Mark Andrews wrote:
> > http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt
...
> 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.
It occurs to me that instead of having a different option format for
every single upper-layer protocol, one could instead just package
the portion of the header chain (extension headers, if any, and
upper-layer header) that appears after the fragmentation header in
the initial fragment. That would require only a single option code,
would apply to all present and future upper-layer protocols, and
would provide the requisite upper-layer information in a form that
those who want it must already know how to parse. The option would
look like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|1| (TBD) | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Portion of header chain following offset=0 fragment header +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type would be chosen to indicate that the option is mutable and
is to be skipped if it is not recognized. The alignment requirement
would be 8n+6, since the upper-layer header and any preceding
extension headers always are aligned on 8-octet boundaries.
Here are some other suggestions:
- Make this a destination option that appears before the
fragmentation header, not a hop-by-hop option, as discussed in a
previous e-mail in this thread.
- This option MUST NOT appear in an initial fragment (or in an
unfragmented fatagram). That avoids the possibiity that a
middlebox will interpret a datagram differently from an end system
(or another middlebox).
- New end-system implementations MUST have the capability to insert
this option in non-initial fragments. That capability MUST be
configurable, and the default SHOULD be to insert the option.
- If a forwarding node discards a packet containing this option, it
MUST be the result of a configurable policy, and not just the
result of a failure to recognize the option. By default, the
policy SHOULD be the same that the node would apply to an initial
fragment with the same header chain that is in the option, and
that in turn SHOULD be the same policy that the node would apply
to an unfragmented datagram with the same header chain (less the
fragmentation header).
- A forwarding node that rewrites the flow label MAY use the
information available in this option for that purpose.
- An end system is not required to process this option. However, if
it does, it SHOULD ensure that the copies the upper-layer in the
various fragments match what appears in the initial fragment, and
that the option does not appear in an initial fragment (or in an
unfragmented datagram). [Define codes and pointers for an ICMPv6
Parameter Problem message that indicates these situations.]
Acknowledgments to draft-ietf-6man-ext-transmit-03 for some stolen
text.
Item for discussion: does it really matter whether or not this
option is marked as mutable? It would not be covered by an
Authetication Header in any case since "AH is applied only to whole
IP datagrams (not to IP fragments)" [RFC 2402] and this option is
inserted only after fragmentation. A NAT does not respect
immutability (as defined in RFC 2402), so the possibility of a NAT
being on the path does not seem like a good reason to mark it
mutable. On the other hand, what benefit could there be from
marking it as immutable?
Mike Heard
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
