Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)

On Aug 14, 2011, at 1:31 PM, nalini.elkins@insidethestack.com wrote:

> 
> I am working on contacting a number of our large corporate customers to weigh in on this topic.  I think that the biggest issue here is that when a large commercial network is having problems, anything that can help speed diagnostics is worth doing. Outages and poor performance can cost a great deal of money.  
> 
> Situations such as comparing packets at various points on the network to determine packet loss is a necessary part of network problem determination.  I am working to get the technicians from the corporations themselves to get onto this email list and tell their opinions themselves.
> 
> I wish that the IPID was in the main IPv6 header.  That would be the best place for it.  That is not possible, so what we are looking at is doing our best under the circumstances.  One problem with having a Fragmentation Header generated is that it skews statistics on fragmentation.

I presume that if one is parsing that far into the optional headers, that you can distinguish between a fragment header that has an offset of zero and a more fragments flag of 0 which would indicate the existence of a fragmentation header but that no other fragments exist and the other possible combinations.

>  Many corporate networks keep track of how much fragmentation is on their networks and if we generate a spurious indication, then this invalidates the real fragmentation.

should be straight forward to distinguish between the two use-cases.

> Nalini
> 
> 
> --- On Sun, 8/14/11, Carlos Pignataro <cpignata@cisco.com> wrote:
> 
>> From: Carlos Pignataro <cpignata@cisco.com>
>> Subject: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)
>> To: v6ops@ietf.org
>> Date: Sunday, August 14, 2011, 10:03 AM
>> Hi,
>> 
>> I believe there was one further point raised in regards to
>> draft-elkins-6man-ipv6-diagnostic-header (though I don't
>> recall if it
>> was at the mike by Andrew Y., in a corridor, or only in my
>> head): the
>> Heisenbug principle -- if this is used in debugging (and
>> diagnostics),
>> the issue being studied or attempted to reproduce alters
>> its behavior or
>> goes away when modifying the packet (like compiling with
>> different -o).
>> I think this is one of the most important arguments against
>> this
>> proposal. The use of fragment header is interesting, a new
>> header could
>> show much more pronounced deviation of observed behaviour
>> than without it.
>> 
>> For completeness, I did ask some services escalation
>> engineers about how
>> they use the ip-id in IPv4 for troubleshooting, and
>> basically got two
>> main uses for very corner case situations in: i. identify
>> middleboxes
>> and their characteristics (by check IP ID increment
>> patterns, find if
>> packets generated by the same box), and ii. track set of
>> packets along
>> different points in the network (e.g., back-to-back packets
>> and see
>> rate, drops, out of order). But it's built into the v4
>> header.
>> 
>> Thanks,
>> 
>> -- Carlos.
>> 
>> On 8/2/2011 1:24 PM, Joel Jaeggli wrote:
>>> * Presentation - RFC for IPv6 IP identification field
>> (header) - Mike Ackerman
>>>          http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt
>>>          http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header
>>> 
>>> Fred B - Question for the group, do you use the IPID
>> in ipv4? (no
>>> respondants other than presenters)
>>> 
>>> Weg G - We use it all the time? I've never heard of
>> it...
>>> 
>>> Francis D - it's potentially a covert channel, also
>> why not use the
>>> fregmentation header?
>>> 
>>> Bob H - We diefintently want to hear if this is
>> useful. I don't know
>>> who puts this header in the packet?
>>> 
>>> Nalini ? - The host clearly
>>> 
>>> Andrei Y - typical use case for this header would be
>> to see if a
>>> middle box is modifying the packet. 
>>> 
>>> Fred B - What I'm out of this discussion is that the
>> application isn't
>>> a bad one, it could be simulated in a fregment.
>>> 
>>> Fred Baker - Meeting complete, go to Lunch
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 