Subject: Re: [v6ops] IPv6 Diagnostic Option

From: Roland Bless <[email-masked]>
Date: Fri, 22 Jul 2011 07:41:45 +0200

Hi,

On 22.07.2011 06:38, [email-masked] wrote:
> Would love to get feedback on an Internet Draft we have submitted.

> The issue we are addressing is that the IP Identification field which
> was available with IPv4 in the main header is available with IPv6
> only in the Fragment Header.

I don't think that your proposed solution is necessary, since
IPv6 has the Flow Label, that - if set by the source - may be
very well suited for your purpose (tracking flows along a path).
Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/
for more details.

Kind regards,
 Roland

---

From: Erik Kline <[email-masked]>
Date: Fri, 22 Jul 2011 15:35:37 +0900

> Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/

Agreed.

I also think use of the flowlabel will prove operationally simpler.
Some devices drop IPv6 packets that have any kind of headers, even
fragment headers, since they lack the ability to look beyond these
headers at line rate.

---

From: Roland Bless <[email-masked]>
Date: Fri, 22 Jul 2011 09:59:46 +0200

Hi Erik,

> I also think use of the flowlabel will prove operationally simpler.

Yes, fully agree since
a) the Flow Label is part of the standard common IPv6 header, thus
   always present and easier to process (even in the fast path) as
   you also pointed out.
b) Useful Flow Label support in end-systems (i.e., setting the Flow
   Label correctly) is more likely than support for this newly
   suggested additional option, once it would have been adopted.
c) it is really unclear how you would enable the use of the proposed
   option in end-systems on demand. In case of debugging a network
   problem you need to enable this option later, if not too late.

Regards,
 Roland

---

From: Arturo Servin <[email-masked]>
Date: Fri, 22 Jul 2011 08:37:06 -0300

Nalini

	Basically I agree with what others said.

	If there were any reason for not using the flow label, I think you should state it very clearly in the document. 

Regards,
.as

On 22 Jul 2011, at 04:59, Roland Bless wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: [email-masked]
Date: Fri, 22 Jul 2011 09:03:06 -0700 (PDT)

Thanks to all for your comments.  But, there may be some confusion as to what we are trying to achieve.  The Proposed Flow Label field, in our opinion, does not meet our requirements. The reasons are as follows:

1.  The Flow Label, as defined, is a unique and (generally speaking) static identifier per flow.  Its purpose is to distinguish one flow from another.  

2.  Our proposed field increments per packet WITHIN a flow.  The intended purpose is to distinguish one packet from another not one flow from another.

3.  The Flow Label is only 20 bits which is not sufficient to hold even the existing 32 bit ID.  We are proposing a 64-bit ID. 

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

--- On Thu, 7/21/11, Roland Bless <[email-masked]> wrote:

> From: Roland Bless <[email-masked]>
> Subject: Re: [v6ops] IPv6 Diagnostic Option
> To: [email-masked]
> Cc: [email-masked]
> Date: Thursday, July 21, 2011, 10:41 PM
> Hi,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Karl Auer <[email-masked]>
Date: Sat, 23 Jul 2011 08:42:50 +1000

On Fri, 2011-07-22 at 08:37 -0300, Arturo Servin wrote:
> If there were any reason for not using the flow label, I think you
> should state it very clearly in the document. 

Well, the obvious ones are

a) your diagnostic may not be tracking a flow, but single packets or
groups of packets that are only part of a flow. It may even be trying to
figure out why a flow is not working.

b) something else may be using the flow label such that modifying it for
debugging purposes is impossible.

> >   always present and easier to process (even in the fast path) as

True, but if it is in use, you have a flow you can't diagnose (at least
not by using the flow label). Bear in mind that the flow label may even
change in transit (if I read the burbling, ever-changing discussion on
flow labels correctly, which I may well not have).

> >   suggested additional option, once it would have been adopted.

Not sure I see your point here. As soon as the flow label is being used
by end systems - correctly OR incorrectly - it can no longer be used by
diagnostic tools, or at least not if they need to modify the flow label
values.

> >   problem you need to enable this option later, if not too late.

Presumably debugging tools would be able to do it. Having a debugging
tool after the fact is still better than having no tool at all.

My chief worry is that if you start inserting headers in a packet stream
to debug it, you are changing what it is you are debugging - for
example, possibly causing fragmentation where none was occurring before.
The flow label has the nice property that it is in every packets anyway.
However, there are plenty of classes of problem where an additional
header would not affect the situation, and for those problems, this
seems like a useful addition.

As a generic debugging tool, it seems to me the diagnostic header is the
most general and flexible, for all that it is not appropriate in some
situations. And it doesn't seem to actually *hurt* anything, or at least
no more than any other headers might.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Jul 2011 11:06:56 +1200

> flow labels correctly, which I may well not have).

Since it's not protected by any checksum, it may be changed maliciously
and undetectably.

The 3697bis draft being reviewed now by the IESG states that it must not
be changed once it has been set to a non-zero value, but also recognises
that certain (relatively paranoid) firewalls may change it anyway.

More to the point, 3697bis makes very specific recommendations as to how
the flow label should be set by default. It is not a set of free bits.

> diagnostic tools, or at least not if they need to modify the flow label

Exactly.

   Brian

> ------------------------------------------------------------------------
>

---

From: Roland Bless <[email-masked]>
Date: Sat, 23 Jul 2011 22:48:04 +0200

Hi Karl,

> figure out why a flow is not working.

The draft was lacking a clear problem statement so that wasn't clear to me.

> not by using the flow label). Bear in mind that the flow label may even

Depends on what you want to diagnose.

> flow labels correctly, which I may well not have).

That shouldn't be the case though, see Brian's reply.

> diagnostic tools, or at least not if they need to modify the flow label

My point was referring to the case when the flow label is being used
as intended, not for other purposes.

> tool after the fact is still better than having no tool at all.

My point was that you cannot assume that every end-system has such
debugging tool installed and that you can turn it on remotely.
So using special end-systems as debugging tools sending
these special packets out is IMHO a different setting...

> to debug it, you are changing what it is you are debugging - for

Yes.

Regards,
 Roland

---

From: Karl Auer <[email-masked]>
Date: Sun, 24 Jul 2011 10:39:36 +1000

> The draft was lacking a clear problem statement so that wasn't clear to me.

The proposer has put a fairly clear one into this discussion, hope it
ends up in the next draft :-)

> Depends on what you want to diagnose.

That's always true. No tool will fit all situations. The question about
this one, as for all such things, is simply "is it worth having?"

> That shouldn't be the case though, see Brian's reply.

"Shouldn't be the case" is a far cry from "won't be the case". And the
cases where what you expect is not what you get are exactly the cases
where a flow-label-independent tool would likely be Very Nice To Have.

> as intended, not for other purposes.

And my point was that "as intended" is very far from clear (and IMO
rather unlikely ever to be clear).

> debugging tool installed and that you can turn it on remotely.

This is true of all end-to-end debugging tools...?

I suppose I'm saying that you've not convinced me as to why we should
NOT have a diagnostic header. Your arguments all say, in one way or
another, that there are situations where it won't be useful. But that is
true for all such things. To convince me to be against this proposal, I
would need to see

- arguments that show how it is a bad thing
- arguments that show how it is a useless thing
- arguments that show how it will not work
- arguments that show how it is not needed

"Not needed" is different from "useless". "Not needed" means that while
the thing it does is useful, that thing can be done using an existing
tool.

I think most of your points are well-made, I just don't think they are
showstoppers for this proposed new header.

Regards, K.