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

[Ronald Bonica <[e-mail]>]

Hi Mike,

Thanks for your review of all three documents. The following is some gentle pushback. 

At IETF 87, the 6man WG was pretty clear that they are not ready to deprecate IPv6 fragmentation. So, within the next few weeks, I will update that document so that it makes only the following points:

- IPv6 fragmentation doesn't work well because fragments are blocked on many paths
- The IETF should not standardize any new protocols that rely on IPv6 fragmentation
- Some legacy protocols can break their reliance on fragmentation, others cannot. Legacy protocols that can break their reliance on fragmentation should consider doing so.
- Legacy protocols and implementations thereof will continue to send fragments for a long time to come.

Since fragmentation will be with us for a while, we need to deal with its issues. Currently, we see two issues:

- the tiny fragment problem
- the long header problem

The two problems are orthogonal to one another. It is possible for a packet to display either problem without displaying the other. 

Also, there is a very concrete solution for the tiny fragment problem. This solution constitutes an UPDATE to RFC 2460 regarding sending and handling tiny fragments. Since we are updating 2460, we need to publish a PS document.

There is no real solution to the long header problem. The best that we can do is to put a stake in the ground, saying that implementations should forward packets with header chains up to X bytes. There is no need to UPDATE RFC 2460, or to publish a PS document. A BCP is good enough.

I hope that this helps.

                                      Ron




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> C. M. Heard
> Sent: Monday, August 19, 2013 8:58 PM
> To: IPv6
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-
> chain-04>
> 
> 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