Greetings,
My main question is why this draft is not better integrated with
draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate,
which have overlapping or at least related subject matter.
The thrust of draft-ietf-6man-oversized-header-chain is to require
that all extension headers and the upper layer header appear in the
first IPv6 fragment and to define an ICMPv6 error message that may
be sent when that condtion is violated (type = Parameter Problem,
code = IPv6 first-fragment has incomplete IPv6 header chain).
The thrust of draft-wkumari-long-headers-01 is the claim that
operators have a requirement to filter at Layer 3 and Layer 4, at
line rate, in the network, and that in order to be able to do that,
the entire header chain needs to appear within a relatively short
initial segment of the IPv6 datagram -- the draft suggests 128
bytes. This is MUCH shorter that the "within the first fragment"
constraint specified by draft-ietf-6man-oversized-header-chain.
There is also a strong hint (though not an explicit statement) in
draft-wkumari-long-headers-01 that entities that do in-network
line-rate filtering need to see layer 3 and 4 information in ALL
datagrams, which is at the heart of the subject matter of
draft-bonica-6man-frag-deprecate.
In my view, draft-ietf-6man-oversized-header-chain should not go to
the IESG until:
1.) This WG decides what to do with draft-bonica-6man-frag-deprecate.
If the decision is to admit that IPv6 frgmentation works so
poorly in pratice that new protocols must not use it and
existing protocols should try not to use it, then a stronger
recommendation than just confining the header chain to the
initial fragment is probably in order -- perhaps something like
what's in draft-wkumari-long-headers.
2.) This WG decides whether the ideas in draft-wkumari-long-headers
are basically sound. If so, then it would make sense (to me,
anyway) to merge it with draft-ietf-6man-oversized-header-chain.
The two drafts already agree (with admirable precision) on the
definition of what a complete IPv6 header chain is. One way to
merge the documents would be to add a section to
draft-ietf-6man-oversized-header-chain recognizing that there
are likely to be stringent limits on the size of a header chain
that an implementation can process and defining an ICMPv6 error
message that may be sent when these limits are exceeded (type =
Parameter Problem, code = IPv6 header chain exceeds
implementation's capacity). A recommendation on the minimum
size header chain that an implementation should support would
then be in order.
Thanks,
Mike Heard
On Tue, 13 Aug 2013, Ole Troan wrote:
> All,
>
> This message starts the second two week 6MAN Working Group on advancing:
>
> Title : Implications of Oversized IPv6 Header Chains
> Author(s) : F. Gont, V. Manral, R. Bonica
> Filename : draft-ietf-6man-oversized-header-chain-04
> Pages : 13
> Date : 2013-08-13
>
> http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-04
>
>
> as a Proposed Standard. Substantive comments and statements of
> support for advancing this document should be directed to the
> mailing list. Editorial suggestions can be sent to the authors.
> This last call will end on August 27, 2013.
>
> The chairs would like to solicit one or two people in the working
> group to do a detailed review of the document. We would also
> encourage volunteers to act as document shepherds. Please contact
> the chairs directly.
>
> Regards,
>
> Bob Hinden & Ole Trøan--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
