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

From: Ole Troan <[email-masked]>
Date: Tue, 13 Aug 2013 22:13:43 +0200

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 19 Aug 2013 17:58:04 -0700 (PDT)

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:
> 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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Aug 2013 01:02:58 -0300

Hi, Mike

> which have overlapping or at least related subject matter.

Because what's in draft-ietf-6man-oversized-header-chain is what the wg
agreed upon over time.

For instance, some earlier version of
draft-ietf-6man-oversized-header-chain enforced an upper limit t the
size of the extension header length (1280 bytes, at the time) but such
limit was removed from the document in responses to wg consensus.

> constraint specified by draft-ietf-6man-oversized-header-chain.

And it was agred by this wg that this limit would be an operational BCP,
but not a protocol update. That's thy these items are kept in different
documents.

> draft-bonica-6man-frag-deprecate.

The wg discussed this, and I seem to recall that the outcome was that we
were not ready to ban the use of fragmentation, but rather that we
should move away from it.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Aug 2013 16:23:51 +1200

> Because what's in draft-ietf-6man-oversized-header-chain is what the wg

And because taking baby steps when playing with such a basic aspect
of the protocol seems wiser. I don't think the topics overlap; saying
that the header chain must not be fragmented seems straightforward and
non-controversial. The other drafts are more contentious.

   Brian

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 20 Aug 2013 13:33:32 +0000

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: [email-masked] [mailto:[email-masked]] 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,
> 
> 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"
> 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:
> 
> > support for advancing this document should be directed to the mailing
> > list.  Editorial suggestions can be sent to the authors.
> encourage
> > volunteers to act as document shepherds. Please contact the chairs
> > directly.
> >
> > Regards,
> >
> > Bob Hinden & Ole Trøan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Aug 2013 08:17:00 +1200

Hi Ron,

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

...

> 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. T…

Architecturally, we have (I think) decided to say that header chains MUST NOT
be fragmented (this draft) and SHOULD be forwarded (draft-ietf-6man-ext-transmit).
I'm still a bit leery about making X bytes a rule rather than a health
warning - who knows when someone might come up with a silicon-based solution
that doesn't have an X bytes limitation? A carefully worded BCP that makes
it clear that X bytes is a current engineering limit rather than an
architectural limit seems about right.

Keeping the documents separate provides flexibility for the future, too.

   Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 20 Aug 2013 23:04:18 -0700 (PDT)

On Wed, 21 Aug 2013, Brian E Carpenter wrote:
> > 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.
> 

A contrary point of view is that standards-track specs, above 
everything else, are instructions to implementors, and other things 
being equal, having things in fewer places rather than more 
simplifies life for the implementor.  I say this from the 
perspective of one who (many years ago) came late to the IPv4 party 
and found it a struggle to ferret out the necessary information.

I agree that advice like "be prepared to handle header chains of at 
least X bytes" should be a health warning rather than a normative 
rule, and for that alone a BCP would be fine.  But if we acknowledge 
that for the present, some implementations have a limit to the size 
of header chains that they can process, would it not be reasonable 
to provide guidance -- which I think would need to be in a standards 
track spec -- as to what kind of ICMPv6 message is appropriate if 
their limit is hit?  (I previously suggested type = Parameter 
Problem, code = IPv6 header chain exceeds implementation's capacity; 
I neglected to say anything about the pointer; it should probably 
point to the first header byte that could not be processed.)

All that being said, it is certainly possible to get our work done 
with separate documents (of whatever type).

Incidentally, I could not find guidance in 
draft-ietf-6man-oversized-header-chain-04 as to how the set the 
pointer field of an ICMPv6 message sent when a first-fragment with 
an incomplete header chain is descarded.  Left to my own devices I 
would probably make it point to the Payload Length in the IPv6 
header, but it would be best for the spec to spell this out.

Thanks,

Mike Heard

P.S.  Thanks for keeping the pushback gentle :-)

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Aug 2013 12:47:26 +0000

Mike,

Good point! The pointer field in the ICMPv6 Parameter Problem Message needs to carry some value.

My first guess would be to point at the first byte of the Fragment Header, because the packet is improperly fragmented. I would not point at the Payload Length in the IPv6 header, because the Payload Length is correct.

Does that work for everybody?

                             Ron

> draft-ietf-6man-oversized-header-chain-04 as to how the set the pointer
> field of an ICMPv6 message sent when a first-fragment with an
> incomplete header chain is descarded.  Left to my own devices I would
> probably make it point to the Payload Length in the IPv6 header, but it
> would be best for the spec to spell this out.
>

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 21 Aug 2013 07:29:21 -0700 (PDT)

The reason I didn't suggest pointing at the Fragment Header is 
because it would carry the same information that it would in a 
correctly fragmented packet, namely M=1 and Fragment Offset=0 (the 
signature of an initial fragment).  The Payload Length field is what 
indicates that the fragment is too short to contain all the 
extension headers and the upper layer header; its value would have 
to be different in a legitimate packet.  Hence my suggestion to 
point there.

//cmh

On Wed, 21 Aug 2013, Ronald Bonica wrote:
> My first guess would be to point at the first byte of the Fragment 
> Header, because the packet is improperly fragmented. I would not 
> point at the Payload Length in the IPv6 header, because the 
> Payload Length is correct.
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 21 Aug 2013 16:36:40 +0200

> to be different in a legitimate packet.  Hence my suggestion to 

or set the pointer field to 0? given that there really isn't an octet offset where an error has been detected.

cheers,
Ole

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Aug 2013 14:39:03 +0000

Mike,

I can see the argument both ways. Does anybody else have an opinion?

                                   Ron

> Sent: Wednesday, August 21, 2013 10:29 AM
> To: IPv6
> Subject: RE: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-
> chain-04>
> 
> The reason I didn't suggest pointing at the Fragment Header is because
> it would carry the same information that it would in a correctly
> fragmented packet, namely M=1 and Fragment Offset=0 (the signature of
> an initial fragment).  The Payload Length field is what indicates that
> the fragment is too short to contain all the extension headers and the
> upper layer header; its value would have to be different in a
> legitimate packet.  Hence my suggestion to point there.
> 
> //cmh
> 
> point
> > at the Payload Length in the IPv6 header, because the Payload Length
> > is correct.
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Aug 2013 14:40:23 +0000

This works, too. But now we have three participants in the discussion and three opinions!

Let's just pick one! Does anybody have a coin?

                               Ron

> Ole Troan
> Sent: Wednesday, August 21, 2013 10:37 AM
> To: C.M.Heard
> Cc: IPv6
> because

---

From: Ole Troan <[email-masked]>
Date: Wed, 21 Aug 2013 16:56:02 +0200

> Let's just pick one! Does anybody have a coin?

who calls "edge"? ;-)

cheers,
Ole

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Aug 2013 15:04:43 +0000

I am happy to set the pointer field to 0 if Mike agrees.

                            Ron

> From: Ole Troan [mailto:[email-masked]]
> Sent: Wednesday, August 21, 2013 10:56 AM
> To: Ronald Bonica
> Cc: C.M.Heard; IPv6
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Ole Troan
> >>> fragmented packet, namely M=1 and Fragment Offset=0 (the signature
> >>> of an initial fragment).  The Payload Length field is what
> indicates
> >> that
> >> or set the pointer field to 0? given that there really isn't an
> octet
> >> offset where an error has been detected.
> >>
> >> cheers,
> >> Ole
> >

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 21 Aug 2013 09:00:44 -0700 (PDT)

Works for me.

//cmh

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Aug 2013 16:03:13 +0000

Then 0 it is!

       Ron

> From: C. M. Heard [mailto:[email-masked]]
> Sent: Wednesday, August 21, 2013 12:01 PM
> To: Ronald Bonica
> Cc: Ole Troan; IPv6
> > > > This works, too. But now we have three participants in the
> > > > discussion
> > > and three opinions!
> > > >
> > > >> From: [email-masked] [mailto:[email-masked]] On
> > > >> Behalf Of Ole Troan
> > > >>> fragmented packet, namely M=1 and Fragment Offset=0 (the
> > > >>> the fragment is too short to contain all the extension headers
> > > >>> and
> > > >> the

---

From: "George, Wes" <[email-masked]>
Date: Wed, 21 Aug 2013 16:16:56 -0400

Ron, et. Al:
I made a similar observation to Mike's about the amount of overlap between the drafts in v6ops this AM (http://www.ietf.org/mail-archive/web/v6ops/current/msg17431.html)
So how does draft-taylor-v6ops-fragdrop fit into this ? And for that matter, draft-andrews-6man-fragopt?
Apologies for not making the linkage on the first message, order of operations problem as I slogged through mail...

Could the authors (many of which also overlap) and WG chairs of one or both groups get together and sort out what is going where to address the issues, and map it to the (to be updated) drafts, identify to be abandoned drafts, etc? One cannot solve a problem of too many layers of abstraction with another layer of abstraction, and I fear we're headed in that direction with this group of drafts and all of the voluminous email threads discussing this set of problems all in one mass, across 2 WGs.
I vote for consolidating down to as few drafts as possible within the confines of the need to keep standards/protocol changes in 6man and address other procedural minutae.

Thanks,

Wes George

> Ronald Bonica
> Sent: Tuesday, August 20, 2013 9:34 AM
> To: C. M. Heard; IPv6
> Subject: RE: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-chain-
> 04>
>
> Hi Mike,
>
> 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:
>
> - Some legacy protocols can break their reliance on fragmentation,
> others cannot. Legacy protocols that can break their reliance on
> fragmentation should consider doing so.
> Since fragmentation will be with us for a while, we need to deal with
> its issues. Currently, we see two issues:
>
> 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
>
>
>
>
> Of
> operators
Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.