Re: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-chain-04>

["C. M. Heard" <[e-mail]>]

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