Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

From: <[email-masked]>
Date: Sat, 2 Feb 2013 05:45:01 -0800 (PST)

A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-ipid-needed. Please take a look at it and comment.

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Feb 2013 01:21:39 +0900

a strange document, a plea for ipid in v6.  i kinda like[d] ipid and we
did some reasearch measurements on it.  actually, i think we are still
collecting and have some years of longitudinal data.

but i would think that this document would be in 6man, where putting
ipid in the v6 header does not have a snowball's chance in hell.

randy

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 2 Feb 2013 16:37:34 +0000

Thanks for the comments Randy.   We would be interested in your measurements and any other related info/thoughts/insights you may have!

We are new to IETF and if we should be working with other or additional Working Groups, we are certainly open to that.  

I am curious why you feel 6man would not be open to this?  

Thanks again!

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Saturday, February 02, 2013 11:22 AM
To: Fred Baker
Cc: IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

a strange document, a plea for ipid in v6.  i kinda like[d] ipid and we did some reasearch measurements on it.  actually, i think we are still collecting and have some years of longitudinal data.

but i would think that this document would be in 6man, where putting ipid in the v6 header does not have a snowball's chance in hell.

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

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Feb 2013 14:03:43 -0800 (PST)

----- Original Message -----
> From: "Ackermann, Michael" <[email-masked]>
> To: Randy Bush <[email-masked]>; Fred Baker <[email-masked]>
> Cc: IETF v6ops list <[email-masked]>
> Sent: Sunday, 3 February 2013 3:37 AM
>T hanks for the comments Randy.   We would be interested in your measurements and 
> any other related info/thoughts/insights you may have!
> 

Randy is probably talking about proposed changes to the fixed portion of the IPv6 header. The extension header approach you've take is the correct one to extend IPv6, although new extension header transparency over the Internet can be a problem as some (most? all?) firewalls drop what they don't understand.

I've had a brief look at your drafts, one thing I'm a bit confused about is exactly how the IPID field is used. Part of the reason I ask is that it reads like your draft is saying that the IPID field always has useful values. My understanding is that the IPID field only has to have useful values if the packet is carrying a fragment. Here's what RFC791 says:

  Identification:  16 bits

    An identifying value assigned by the sender to aid in assembling the
    fragments of a datagram.

Are you artificially setting the value of the IPID field in your test traffic, or do you happen to have traffic sources that set the IPID field value regardless of whether the packet contains a fragment or not?

Have you considered the IPv6 Flow Label field for your purpose? It might suit your requirement.

Regards,
Mark.

> a strange document, a plea for ipid in v6.  i kinda like[d] ipid and we did some 
> reasearch measurements on it.  actually, i think we are still collecting and 
> have some years of longitudinal data.
> 
> but i would think that this document would be in 6man, where putting ipid in the 
> v6 header does not have a snowball's chance in hell.
> 
> randy
> The information contained in this communication is highly confidential and is 
> intended solely for the use of the individual(s) to whom this communication is 
> directed. If you are not the intended recipient, you are hereby notified that 
> any viewing, copying, disclosure or distribution of this information is 
> prohibited. Please notify the sender, by electronic mail or telephone, of any 
> unintended receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
> nonprofit corporations and independent licensees of the Blue Cross and Blue 
> Shield Association.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 2 Feb 2013 22:23:18 +0000

>     An identifying value assigned by the sender to aid in assembling the

It actually has to go farther than that.

Suppose, just for fun, that the RFC 791 sender is always sending ipid=0, and some router en route is fragmenting every third datagram. If the router doing that leaves lipid alone, they will all appear to be fragments of the same datagram. If the router is updating lipid, what should it update lipid to?

No, the RFC 791 sender is on the hook to give datagrams within the same session (e.g., having the same source, destination, and protocol number) differing ipid values, since it doesn't know whether a router mid-stream will need to manipulate the packet.

There are some interesting ramifications that can come into play there. It is legal for an implementation to maintain some kind of counter and simply enumerate the packets it sends, and that is the usual procedure AFAIK. It would also be legal for a UDP application or a TCP/SCTP/DCCP transport to keep a similar counter for the session, as long as it knew that there were no other sessions with the same peer.

In IPv6, since only the originator fragments, the whole point is kind of moot. If the fragment header is there, the id field had bester be written in, and it *is* meaningful.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sun, 3 Feb 2013 00:26:59 +0000

Thanks Mark.

I think you are already aware that if Fragmentation is required, The Fragmentation Header will be there and IPID will be in there and is needed for reassembly.   But are big issues is that for certain situations, the IPID has be a very valuable diagnostic tool.   Thus we feel it is needed even in situations were fragmentation is not required.   

We are open to what the best implementation or way to achieve that is, but we have included one possible solution in our RFC. 

Mike

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Saturday, February 02, 2013 5:04 PM
To: Ackermann, Michael; Fred Baker
Cc: IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

----- Original Message -----
>T hanks for the comments Randy.   We would be interested in your 
>measurements and  any other related info/thoughts/insights you may have!
> 
> We are new to IETF and if we should be working with other or 
> additional Working Groups, we are certainly open to that.
> 

  Identification:  16 bits

Regards,
Mark.

> a strange document, a plea for ipid in v6.  i kinda like[d] ipid and 
> we did some reasearch measurements on it.  actually, i think we are 
> still collecting and have some years of longitudinal data.
> 
> ipid in the
> The information contained in this communication is highly confidential 
> and is intended solely for the use of the individual(s) to whom this 
> communication is directed. If you are not the intended recipient, you 
> are hereby notified that any viewing, copying, disclosure or 
> distribution of this information is prohibited. Please notify the 
> sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan 
> are nonprofit corporations and independent licensees of the Blue Cross 
> and Blue Shield Association.

---

From: Owen DeLong <[email-masked]>
Date: Sat, 2 Feb 2013 16:33:28 -0800

It seems to me that in most of the situations you described, the flow label could be used
as a valid substitute.

Am I wrong?

Owen

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 3 Feb 2013 02:05:10 +0000

> It seems to me that in most of the situations you described, the flow label could be used

I think you are. I may be wrong. Chair hat most definitely off.

An ipid is by definition a field that contains a number that is *different* for every reassembled datagram headed from point A to point B using a given transport protocol. The intended use case is fragmentation and reassembly A Flow Label is by definition a field that contains a number that is the *same* for every datagram headed from point A to point B that is within the same flow, whatever a flow is. We have a number of RFCs that try to describe use cases, but it's hard for me to describe the flow label as having a real consensus behind it apart from that sentence.

Now, you could argue (and get some significant debate from some in 6man) that an operator is within his rights to overwrite the usually-zero flow label with a number of his choosing and use it in whatever way he might. From Nalini's perspective, if I understand it correctly, this is also counter-productive; if she wants to know about the order packets actually arrive in, that action would, at least in the ipid case, remove that information from the data stream. If one assumes that ipid simply counts, which is an undocumented and unrequired assumption, and the packets were out of order at the time they arrived at the thing stomping on the flow label, they would now appear to be in order.

Yes, you could use the field. How you would use it would depend a lot on the assumptions you were making and what you hoped to learn from it.

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Feb 2013 18:15:52 -0800 (PST)

Hi Fred,

----- Original Message -----
> From: Fred Baker (fred) <[email-masked]>
> To: Mark Smith <[email-masked]>
> Cc: "Ackermann, Michael" <[email-masked]>; IETF v6ops list <[email-masked]>
> Sent: Sunday, 3 February 2013 9:23 AM
  
<snip>

>>  I've had a brief look at your drafts, one thing I'm a bit confused 
> about is exactly how the IPID field is used. Part of the reason I ask is that it 
> reads like your draft is saying that the IPID field always has useful values. My 
> understanding is that the IPID field only has to have useful values if the 
> packet is carrying a fragment. Here's what RFC791 says:
>> 
>>    Identification:  16 bits
>> 
> Suppose, just for fun, that the RFC 791 sender is always sending ipid=0, and 
> some router en route is fragmenting every third datagram. If the router doing 
> that leaves lipid alone, they will all appear to be fragments of the same 
> datagram. If the router is updating lipid, what should it update lipid to?
> 
> No, the RFC 791 sender is on the hook to give datagrams within the same session 
> (e.g., having the same source, destination, and protocol number) differing ipid 
> values, since it doesn't know whether a router mid-stream will need to 
> manipulate the packet.
> 
> There are some interesting ramifications that can come into play there. It is 
> legal for an implementation to maintain some kind of counter and simply 
> enumerate the packets it sends, and that is the usual procedure AFAIK.

I also asked the question because I thought I read somewhere that Linux set the ID field to zeros when the packet didn't contain a fragment. My memory is vague, however perhaps that is the case when the DF bit is set on the packet, so the ID field will never be used to defragment.

The reason I think I remember this is because it seemed like an unusual optimisation. I'm doing some digging around to see if I can confirm my memory is correct or not.

>  It would 

> also be legal for a UDP application or a TCP/SCTP/DCCP transport to keep a 
> similar counter for the session, as long as it knew that there were no other 
> sessions with the same peer.
> 
> In IPv6, since only the originator fragments, the whole point is kind of moot. 

> If the fragment header is there, the id field had bester be written in, and it 
> *is* meaningful.
> 
>>  Are you artificially setting the value of the IPID field in your test 
> traffic, or do you happen to have traffic sources that set the IPID field value 
> regardless of whether the packet contains a fragment or not?
>> 
>> 
>>>  From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Randy 
>>>  Bush
> did some 
> and is 
> are

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Feb 2013 11:21:09 +0900

> Thanks for the comments Randy.  We would be interested in your

what is left of my memory is that the first paper on using ipid was

    "Touring the internet in a TCP sidecar" Rob Sherwood & Neil Spring
    IMC 2006 Proceedings of the 6th ACM SIGCOMM conference on Internet
    measurement

but that could have been their record route paper.  been too long.
sorry.

> additional Working Groups, we are certainly open to that.

that is generally called 'venue shopping.'  in a culture as small as the
ietf, it is quite noticeable and frowned upon.

> I am curious why you feel 6man would not be open to this?

because ipv6 is perfect, especially the address model and the header.
lack of usability is the fault of the operators, vendors, application
developers, users, and the people in the black helicopters.
< /dripping sarcasm >

randy

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Feb 2013 18:39:13 -0800 (PST)

<snip>
> 
> I also asked the question because I thought I read somewhere that Linux set the 
> ID field to zeros when the packet didn't contain a fragment. My memory is 
> vague, however perhaps that is the case when the DF bit is set on the packet, so 
> the ID field will never be used to defragment.
> 
> The reason I think I remember this is because it seemed like an unusual 
> optimisation. I'm doing some digging around to see if I can confirm my 
> memory is correct or not.
> 
> 

I wasn't right about the ID field being set to zeros under Linux, however it is kept constant for DF packets. Here's some of the comment text at the top of "inetpeer.c" under <src>/net/ipv4/ in the Linux kernel -

/*

 *              INETPEER - A storage for permanent information about peers
 *

...
/*
 *  Theory of operations.
 *  We keep one entry for each peer IP address.  The nodes contains long-living
 *  information about the peer which doesn't depend on routes.
 *  At this moment this information consists only of ID field for the next
 *  outgoing IP packet.  This field is incremented with each packet as encoded
 *  in inet_getid() function (include/net/inetpeer.h).
 *  At the moment of writing this notes identifier of IP packets is generated
 *  to be unpredictable using this code only for packets subjected
 *  (actually or potentially) to defragmentation.  I.e. DF packets less than
 *  PMTU in size uses a constant ID and do not use this code (see
 *  ip_select_ident() in include/net/ip.h).

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Feb 2013 18:48:42 -0800 (PST)

----- Original Message -----
> From: Randy Bush <[email-masked]>
> To: Michael Ackermann <[email-masked]>
> Sent: Sunday, 3 February 2013 1:21 PM

Or pragmatically, too much deployed running code. The only option now available with the fixed IPv6 header fields is to change their meaning in a backward compatible way, similar to how the original ToS field was changed to DSCP in IPv4. Otherwise, an IPv6 extension header, or it'd have to wait until a future version of IP.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 3 Feb 2013 03:40:30 +0000

> I also asked the question because I thought I read somewhere that Linux set the ID field to zeros when the packet didn't contain a fragment. My memory is vague, however perhaps that is the case whe…

If DF is set, no router should ever be fragmenting. I could imagine that.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 03 Feb 2013 00:15:02 -0800

> Or pragmatically, too much deployed running code. The only option now available with the fixed IPv6 header fields is to change their meaning in a backward compatible way, similar to how the origina…
It's probably not reasonable to expect intermediate hops on a network to 
look at extension headers, except for hop by hop, options they're not 
supposed to anyway. it's hard enough to find the upper layer header when 
you need it if there are extension headers or fragmentation that starts 
to get messy..

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2013 08:51:51 +0000

> It seems to me that in most of the situations you described, the flow label could be used

I don't see how. By definition, the flow label is identical for all
packets of a given flow. Therefore, it doesn't distinguish packets
such as split or duplicated packets.

However, the authors might look at RFC 6437 carefully to see if
it helps.

    Brian

---

From: Warren Kumari <[email-masked]>
Date: Sun, 3 Feb 2013 08:34:01 -0500

> I am curious why you feel 6man would not be open to this?  

You may want to (re)read: 
http://www.ietf.org/mail-archive/web/v6ops/current/msg10260.html

I suspect almost exactly the same arguments will be made…

W

--
Credo quia absurdum est.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Feb 2013 08:50:55 -0800

Hi,

Two drafts the authors should be aware of are "Updated
Specification of the IPv4 ID Field":

https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/

and "The Subnetwork Encapsulation and Adapation Layer (SEAL)":

https://datatracker.ietf.org/doc/draft-templin-intarea-seal/

The former is a revised specification of the use of the IPv4
ID field and defines the cases in which the ID field does and
does not contain useful information. The latter is a means for
adding a 32-bit ID field during encapsulation, where the ID
appears in an extension header similar to the way the IPv6
fragment header currently appears.

Point being that the IPv4 ID was never intended for purposes
such as ensuring uniqueness other than for the fragmentation
and reassembly process. And, for IPv6, there are already ways
to add an ID to a packet if one is needed.

Thanks - Fred
[email-masked]

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 4 Feb 2013 17:53:16 +0000

Thanks for your comments Fred!

The first draft you reference seems to highlight the need for an IPID field larger than 16 bits (v4) or 32 bits (v6), due to the much faster networks we have today.   We agree and that is very lightly referenced in our RFC.   The reason for only lightly, is that we chose to focus on the need for IPID at all, since many at the IETF did not agree this was an issue when we first introduced it.   Our original proposal suggested going to 64 bits as part of the solution, but for now we have backed off on solutions and are focused on convincing the IETF that the elimination of IPID as a diagnostic facility, would be bad for end user organizations.  

The second draft you referenced is one I was not aware of but is very impressive and well written!   I know it was focused on tunnels and encapsulation, but among many other things it seems to promote the value of uniquely identifying packets, in particular ones that could be duplicate, improper or even malicious.    If I am interpreting properly, then we are in full agreement.   

Our main issue is that information such as provided by IPID can be critical to reliably running sophisticated networks today. 

Thanks again!

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, February 04, 2013 11:51 AM
To: IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

Hi,

Two drafts the authors should be aware of are "Updated Specification of the IPv4 ID Field":

The former is a revised specification of the use of the IPv4 ID field and defines the cases in which the ID field does and does not contain useful information. The latter is a means for adding a 32-bit ID field during encapsulation, where the ID appears in an extension header similar to the way the IPv6 fragment header currently appears.

Point being that the IPv4 ID was never intended for purposes such as ensuring uniqueness other than for the fragmentation and reassembly process. And, for IPv6, there are already ways to add an ID to a packet if one is needed.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Feb 2013 10:17:12 -0800

Hi Michael,

Forgot to mention that here is another one you would want to cite:

http://datatracker.ietf.org/doc/rfc4963/

Thanks - Fred

> From: Ackermann, Michael [mailto:[email-masked]]
> Sent: Monday, February 04, 2013 9:53 AM
> To: Templin, Fred L; IETF v6ops list
> Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> 
> The first draft you reference seems to highlight the need for an IPID
> field larger than 16 bits (v4) or 32 bits (v6), due to the much faster
> networks we have today.   We agree and that is very lightly referenced in
> our RFC.   The reason for only lightly, is that we chose to focus on the
> need for IPID at all, since many at the IETF did not agree this was an
> issue when we first introduced it.   Our original proposal suggested going
> to 64 bits as part of the solution, but for now we have backed off on
> solutions and are focused on convincing the IETF that the elimination of
> IPID as a diagnostic facility, would be bad for end user organizations.
> 
> The second draft you referenced is one I was not aware of but is very
> impressive and well written!   I know it was focused on tunnels and
> encapsulation, but among many other things it seems to promote the value
> of uniquely identifying packets, in particular ones that could be
> duplicate, improper or even malicious.    If I am interpreting properly,
> then we are in full agreement.
> 
> Our main issue is that information such as provided by IPID can be
> critical to reliably running sophisticated networks today.
> 
> Thanks again!
> 
> Mike
> 
> 
> 
> The former is a revised specification of the use of the IPv4 ID field and
> defines the cases in which the ID field does and does not contain useful
> information. The latter is a means for adding a 32-bit ID field during
> encapsulation, where the ID appears in an extension header similar to the
> way the IPv6 fragment header currently appears.
> 
> Point being that the IPv4 ID was never intended for purposes such as
> ensuring uniqueness other than for the fragmentation and reassembly
> process. And, for IPv6, there are already ways to add an ID to a packet if
> one is needed.
> 
> Thanks - Fred
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
> 
> nonprofit corporations and independent licensees of the Blue Cross and
> Blue Shield Association.

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 4 Feb 2013 20:20:32 -0800 (PST)

Fred,

Thanks so much for your comments.  I have not yet finished completely analyzing your RFC but I have some questions for you:

In your SEAL RFC, would an IPID would only exist in the tunneled header used to traverse the MPLS backbone network?

Would every IPv6 packet then need this header?
 
Thanks,

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

----- Original Message -----
From: "Templin, Fred L" <[email-masked]>
To: "Ackermann, Michael" <[email-masked]>; IETF v6ops list <[email-masked]>
Cc: 
Sent: Monday, February 4, 2013 10:17 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

Hi Michael,

Thanks - Fred

---

From: joel jaeggli <[email-masked]>
Date: Mon, 04 Feb 2013 23:01:14 -0800

> The first draft you reference seems to highlight the need for an IPID field larger than 16 bits (v4) or 32 bits (v6), due to the much faster networks we have today.   We agree and that is very ligh…
To be clear IPv6 never  had an analogous facility except in the 
fragmentation header, so that state of affairs has been on the books for 
about 18 years.

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Feb 2013 23:26:02 -0800

Hi, all,

On 2/4/2013 11:01 PM, joel jaeggli wrote:
>> networks we have today.   We agree and that is very lightly referenced
>> in our RFC.   The reason for only lightly, is that we chose to focus
>> on the need for IPID at all, since many at the IETF did not agree this
>> was an issue when we first introduced it.   Our original proposal
>> suggested going to 64 bits as part of the solution, but for now we
>> have backed off on solutions and are focused on convincing the IETF
>> that the elimination of IPID as a diagnostic facility, would be bad
>> for end user organizations.
 >

It's also important to note that IPv4 networks have tolerated traffic 
with trivially repeating IDs for many years (from cellphones, in specific).

We just convinced the IETF to catch up with that reality and to 
recognize that IPv4 IDs are unique only when fragmentation has already 
occurred or is possible, i.e., in a very similar way to IPv6. Any 
suggestion that these IDs need to be re-established for atomic packets 
(not fragmented, not fragmentable) is a step backwards.

IMO, if you think it is important to have a diagnostic identifier, you 
really should create your own with the semantics you seek.

...
>> critical to reliably running sophisticated networks today.

How critical can it be if the ID is already not present or not unique in 
a lot of traffic?

Joe

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 5 Feb 2013 11:56:37 +0100 (CET)

Joe,

as someone who repeatedly used the (trivially incrementing, 
non-necessarily-unique) IP ID to solve customer issues, I feel 
compelled to chime in with my 2 cents...

On Mon, 4 Feb 2013, Joe Touch wrote:

> It's also important to note that IPv4 networks have tolerated traffic with 
> trivially repeating IDs for many years (from cellphones, in specific).

As soon as it is not a constant number in all the packets, it can be good 
enough.

>
> We just convinced the IETF to catch up with that reality and to recognize 
> that IPv4 IDs are unique only when fragmentation has already occurred or is 
> possible, i.e., in a very similar way to IPv6. Any suggestion that these IDs 
> need to be re-established for atomic packets (not fragmented, not 
> fragmentable) is a step backwards.
>
> IMO, if you think it is important to have a diagnostic identifier, you really 
> should create your own with the semantics you seek.

...and convince everyone worldwide to put it into their endpoints. (*)

The convenience of the IPv4 ID was that it was already there and it was 
reasonably well understood, had very few uses beyond frag/reasm, and was 
most frequently not touched by a lot of middleboxes that did the "fast 
switching" of the packets. Moreover, due to "insecure" mechanisms with 
which it was generated, sometimes you could infer about the other traffic 
the endpoint was generating. Handy.

> How critical can it be if the ID is already not present or not unique in a 
> lot of traffic?

Does not matter. The use case for this is having two sniffer traces with 
200 packets on one side, and 199 packets on the other side - and being 
able to quickly match by ID which packet did not make it; or by a series 
of mismatching IDs be able to say when a middlebox went into a "full 
proxy" mode as opposed to shuffling the packets around in fastpath with 
minor modifications.

It did not have to be perfect to be good enough to save the day.

That said - for IPv6 and ID, I think Elvis has left the building.
Assuming everyone could make any changes to basic format or handling at 
this point is a bit unrealistic.

I suppose all this means I agree with you, even for the entirely different 
set of reasons. :-)

@authors:

The above said, I think there is a good value in rephrasing the draft as 
"These are the use cases that were solved by the way IP ID was handled in IPv4. 
What can we come up with in IPv6 in order to get same or better ways to 
troubleshoot?", as opposed to asking for IP ID or its IPv6 twin 
immediately.

In other words, do not come with a precompiled solution, but rather with a 
problem statement. And, use this draft to accumulate the use cases that 
were made simpler to debug with the IPv4 ID. Maybe there is a way to make 
it even better with IPv6...

The solution you propose in the draft is not something I would advocate 
for - because if the header generation/consumption is optional, it will 
necessarily be done by a different code paths, and especially for this 
case I foresee more of heisenbugs than help for diagnostics.

--a

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 05 Feb 2013 11:28:39 +0000

On 05/02/2013 10:56, Andrew Yourtchenko wrote:
> "These are the use cases that were solved by the way IP ID was handled in
> IPv4. What can we come up with in IPv6 in order to get same or better ways
> to troubleshoot?", as opposed to asking for IP ID or its IPv6 twin
> immediately.

+1

Nick

---

From: Shane Amante <[email-masked]>
Date: Tue, 5 Feb 2013 07:17:31 -0700

Question to the authors of this draft: why are TCP sequence numbers insufficient for your use case(s)?  Or, can TCP sequence numbers be made "good enough" for your use case(s)?

I realize the answer above doesn't help in the case of traffic encapsulated in UDP; but, is that really critical to your use case(s)?  Given UDP does not provide any "ordering" guarantee/semantics, I'm not sure that any such sequence numbers, at the Transport layer, would be useful ...

-shane

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 5 Feb 2013 15:21:27 +0000

Or even atomic fragments (used in NAT64 scenario): where the fragmentation header is always added with the flags set as being the first and last fragment. Then, nothing to change except on the sender

-éric

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shane Amante
> Sent: mardi 5 février 2013 15:18
> To: IETF v6ops list
> Question to the authors of this draft: why are TCP sequence numbers
> insufficient for your use case(s)?  Or, can TCP sequence numbers be made
> "good enough" for your use case(s)?
> 
> I realize the answer above doesn't help in the case of traffic encapsulated
> in UDP; but, is that really critical to your use case(s)?  Given UDP does
> not provide any "ordering" guarantee/semantics, I'm not sure that any such
> sequence numbers, at the Transport layer, would be useful ...
> 
> -shane
> 
> 
> >> The above said, I think there is a good value in rephrasing the draft
> >> as "These are the use cases that were solved by the way IP ID was
> >> handled in IPv4. What can we come up with in IPv6 in order to get
> >> same or better ways to troubleshoot?", as opposed to asking for IP ID
> >> or its IPv6 twin immediately.
> >
> > +1
> >
> > Nick
> >

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 05 Feb 2013 15:30:52 +0000

> Or even atomic fragments (used in NAT64 scenario): where the fragmentation header is always added with the flags set as being the first and last fragment. Then, nothing to change except on the send…

or (finally a use!) ipsec AH?

Nick

-- 
Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698
3 Westland Square    | INEX - Internet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland    | Exchange Association    | Email: [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 5 Feb 2013 15:35:54 +0000

I very much agree with Andrew here, including the conclusion of the need
for a problem statement.

This thread reminded me of this other one
http://www.ietf.org/mail-archive/web/v6ops/current/msg10266.html

Thanks,

-- Carlos.

On 2/5/13 5:56 AM, "Andrew Yourtchenko (ayourtch)" <[email-masked]>
wrote:

>>with 
>>recognize 
>>really 
>IPv4.

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 07:56:22 -0800 (PST)

Fragmentation header always added is a fine solution.   I believe that what we seek is support from other IETFers on the eventual solution and then if we all agree on this and there are not security implications then we can start to ask the stack vendors to implement this.  
 
Thanks,

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

----- Original Message -----
From: Eric Vyncke (evyncke) <[email-masked]>
To: Shane Amante <[email-masked]>; IETF v6ops list <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Tuesday, February 5, 2013 7:21 AM
Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

-éric

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 08:15:43 -0800 (PST)

Please see my comments inline.
 
Thanks,

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

________________________________
 From: Shane Amante <[email-masked]>
To: IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 6:17 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
 
>  Question to the authors of this draft: why are TCP sequence numbers insufficient for your use case(s)?  Or, can TCP sequence numbers be made "good enough" for your use case(s)?

The reason TCP sequence numbers (and hashing, for that matter) is not good enough is because there can be valid duplicate TCP packets.   These duplicates will have the same TCP sequence and ack numbers.  Yes, TTL can be different but sometimes not.  In diagnosing problems of congestion, it is important to know how many duplicates there are so that you can see how bad the network flow is.   I have also worked on devices which provided packet traces and duplicated (falsely!) only certain packets.

The situation is often that by the time my company is called in or, other of my compadres, the problem is quite serious.  Emotions are running high and the more evidence I have that certain packets are true duplicates and others coming from a 'spoofing' device in the middle of the path, etc, the better.  IPID has been quite helpful here.

Also, changing how TCP sequence numbers are sent hardly seems easier than a solution around IPID!

> I realize the answer above doesn't help in the case of traffic encapsulated in UDP; but, is that really critical to your use case(s)?  Given UDP does not provide any "ordering" guarantee/semantics,…

Actually, we have had cases where we used IPID to diagnose UDP traffic problems.   In large end user companies, UDP is used sometimes to encapsulate quite complex protocols such as High Performance Routing (HPR). (http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.znetwork/znetwork_218.htm)  This is an implementation used by IBM Enterprise Extender.   Such packets do need to be in a sequence, etc.  The embedded protocol (RTP) is what does the sequencing.

UDP is rightfully used as it is lightweight and HPR is a very comprehensive and complex protocol.  Having said that, sequencing and packet loss in HPR is extremely difficult to diagnose.  Again, we are looking for time savings here.  We have found IPID helpful to see where packets are being lost and 'driving HPR crazy'!

-shane

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 08:16:15 -0800 (PST)

Great idea!  Thanks for the suggestion.
 
Thanks,

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

________________________________
 From: Nick Hilliard <[email-masked]>
To: Andrew Yourtchenko <[email-masked]> 
Cc: IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 3:28 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

+1

Nick

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 5 Feb 2013 16:19:11 +0000

Thanks Joel.

Your comment highlights our more general issue, which is that large enterprises are not very active at IETF, so would not see issues such as this until they deploy IPV6 in production and have a problem where facilities could be shown to be missing or inadequate.   And yes, ideally speaking, that is way to late in the process.  

This issue is somewhat separate from our RFC, but is a situation we seek to address by getting more large organizations involved in IETF.   We believe that would be a win/win situation, benefiting not only the large organizations themselves, but IETF and networking in general as well! 

I hope you agree?

Thanks again!

Mike

-----Original Message-----
From: joel jaeggli [mailto:[email-masked]] 
Sent: Tuesday, February 05, 2013 2:01 AM
To: Ackermann, Michael; Templin, Fred L; IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

> The first draft you reference seems to highlight the need for an IPID field larger than 16 bits (v4) or 32 bits (v6), due to the much faster networks we have today.   We agree and that is very ligh…
To be clear IPv6 never  had an analogous facility except in the fragmentation header, so that state of affairs has been on the books for about 18 years.
> Of Templin, Fred L

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 08:21:57 -0800 (PST)

Andrew,

I wonder if possible solutions can be worked out at a brainstorming session at the IETF in Orlando.  We would like to get a group together to think about solutions because I can tell you, we internally have gone around with each other on different solutions and their drawbacks!  Performance, security and implementation difficulties being some of the problems involved.

I will ask the chairs if we can have a BOF, if this is not possible, then maybe we can all find a venue with beer and chips available!   I will post.
 
Thanks,

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

________________________________
 From: Andrew Yourtchenko <[email-masked]>
To: Joe Touch <[email-masked]> 
Cc: IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 2:56 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
 
Joe,

as someone who repeatedly used the (trivially incrementing, non-necessarily-unique) IP ID to solve customer issues, I feel compelled to chime in with my 2 cents...

On Mon, 4 Feb 2013, Joe Touch wrote:

> It's also important to note that IPv4 networks have tolerated traffic with trivially repeating IDs for many years (from cellphones, in specific).

As soon as it is not a constant number in all the packets, it can be good enough.

> 
> We just convinced the IETF to catch up with that reality and to recognize that IPv4 IDs are unique only when fragmentation has already occurred or is possible, i.e., in a very similar way to IPv6. Any suggestion that these IDs need to be re-established for atomic packets (not fragmented, not fragmentable) is a step backwards.
> 
> IMO, if you think it is important to have a diagnostic identifier, you really should create your own with the semantics you seek.

The convenience of the IPv4 ID was that it was already there and it was reasonably well understood, had very few uses beyond frag/reasm, and was most frequently not touched by a lot of middleboxes that did the "fast switching" of the packets. Moreover, due to "insecure" mechanisms with which it was generated, sometimes you could infer about the other traffic the endpoint was generating. Handy.

> How critical can it be if the ID is already not present or not unique in a lot of traffic?

Does not matter. The use case for this is having two sniffer traces with 200 packets on one side, and 199 packets on the other side - and being able to quickly match by ID which packet did not make it; or by a series of mismatching IDs be able to say when a middlebox went into a "full proxy" mode as opposed to shuffling the packets around in fastpath with minor modifications.

That said - for IPv6 and ID, I think Elvis has left the building.
Assuming everyone could make any changes to basic format or handling at this point is a bit unrealistic.

I suppose all this means I agree with you, even for the entirely different set of reasons. :-)

@authors:

The above said, I think there is a good value in rephrasing the draft as "These are the use cases that were solved by the way IP ID was handled in IPv4. What can we come up with in IPv6 in order to get same or better ways to troubleshoot?", as opposed to asking for IP ID or its IPv6 twin immediately.

In other words, do not come with a precompiled solution, but rather with a problem statement. And, use this draft to accumulate the use cases that were made simpler to debug with the IPv4 ID. Maybe there is a way to make it even better with IPv6...

The solution you propose in the draft is not something I would advocate for - because if the header generation/consumption is optional, it will necessarily be done by a different code paths, and especially for this case I foresee more of heisenbugs than help for diagnostics.

--a

---

From: joel jaeggli <[email-masked]>
Date: Tue, 05 Feb 2013 08:28:36 -0800

On 2/5/13 8:21 AM, Nalini Elkins wrote:
> Andrew,
>
> I wonder if possible solutions can be worked out at a brainstorming 
> session at the IETF in Orlando.  We would like to get a group together 
> to think about solutions because I can tell you, we internally have 
> gone around with each other on different solutions and their 
> drawbacks!  Performance, security and implementation difficulties 
> being some of the problems involved.
>
> I will ask the chairs if we can have a BOF, if this is not possible, 
> then maybe we can all find a venue with beer and chips available!   I 
> will post.
BOF(s) are scheduled by the IESG. You are free to schedule an informal 
meeting of interested parties whenever you choose.
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>
> ------------------------------------------------------------------------
> *From:* Andrew Yourtchenko <[email-masked]>
> *To:* Joe Touch <[email-masked]>
> *Cc:* IETF v6ops list <[email-masked]>
> *Sent:* Tuesday, February 5, 2013 2:56 AM
> *Subject:* Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
>
> Joe,
>
> > It's also important to note that IPv4 networks have tolerated 
> traffic with trivially repeating IDs for many years (from cellphones, 
> in specific).
>
> > IMO, if you think it is important to have a diagnostic identifier, 
> you really should create your own with the semantics you seek.
>
> The convenience of the IPv4 ID was that it was already there and it 
> was reasonably well understood, had very few uses beyond frag/reasm, 
> and was most frequently not touched by a lot of middleboxes that did 
> the "fast switching" of the packets. Moreover, due to "insecure" 
> mechanisms with which it was generated, sometimes you could infer 
> about the other traffic the endpoint was generating. Handy.
>
> >
> > ...
> Does not matter. The use case for this is having two sniffer traces 
> with 200 packets on one side, and 199 packets on the other side - and 
> being able to quickly match by ID which packet did not make it; or by 
> a series of mismatching IDs be able to say when a middlebox went into 
> a "full proxy" mode as opposed to shuffling the packets around in 
> fastpath with minor modifications.
>
> handled in IPv4. What can we come up with in IPv6 in order to get same 
> or better ways to troubleshoot?", as opposed to asking for IP ID or 
> its IPv6 twin immediately.
>
> In other words, do not come with a precompiled solution, but rather 
> with a problem statement. And, use this draft to accumulate the use 
> cases that were made simpler to debug with the IPv4 ID. Maybe there is 
> a way to make it even better with IPv6...
>
> The solution you propose in the draft is not something I would 
> advocate for - because if the header generation/consumption is 
> optional, it will necessarily be done by a different code paths, and 
> especially for this case I foresee more of heisenbugs than help for 
> diagnostics.
>
> --a
>
> >
> > Joe
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Feb 2013 08:36:04 -0800

Hi Nalini,

> From: Nalini Elkins [mailto:[email-masked]]
> Sent: Monday, February 04, 2013 8:21 PM
> To: Templin, Fred L; Ackermann, Michael; IETF v6ops list
> Thanks so much for your comments.  I have not yet finished completely
> analyzing your RFC but I have some questions for you:
> 
> In your SEAL RFC, would an IPID would only exist in the tunneled header
> used to traverse the MPLS backbone network?

SEAL deals with IP-in-IP encapsulation. With SEAL, there is an
outer IP header, a mid-layer SEAL header and an inner IP header.
The outer IP header and SEAL header are only present over the
portion of the path that traverses the region of encapsulation
(aka the "tunnel"). The inner IP header is present over the full
end-to-end path.

> Would every IPv6 packet then need this header?

Only those IPv6 packets that are taken in for encapsulation.

Note that if you wanted to require all IPv6 packets to include a
fragment header, there is a draft that talks about "atomic IPv6
fragments":

https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/

Thanks - Fred
 
> in
> Of
> > Templin, Fred L
> and

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Feb 2013 08:48:36 -0800

Following up on my own:

> Sent: Tuesday, February 05, 2013 8:36 AM
> To: Nalini Elkins; Ackermann, Michael; IETF v6ops list

SEAL is also compatible with a transport mode of operation in which
the end systems would need to negotiate the use of a SEAL header that
travels end-to end. Sort of how IPsec supports both tunnel- and
transport modes of operation.

Thanks - Fred

> > > Two drafts the authors should be aware of are "Updated Specification
> of
> > > the IPv4 ID Field":
> > >
> > > process. And, for IPv6, there are already ways to add an ID to a
> packet
> > if
> > > one is needed.
> > >
> > > Thanks - Fred

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 08:49:49 -0800 (PST)

Thanks, Fred.  

The atomic fragments RFC may be what should be pushed for adoption.  At the stage we are now, this may be one of the only viable solutions.

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

________________________________
 From: "Templin, Fred L" <[email-masked]>
To: Nalini Elkins <[email-masked]>; "Ackermann, Michael" <[email-masked]>; IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 8:36 AM
Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
 
Hi Nalini,

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 08:50:58 -0800

FWIW, there are two obvious solutions that work for both IPv4 and IPv6:

1) send fragmented (or fragmentable) packets
	presuming you have control over a source

2) compare either full packets or hashes of the full packets

"convenience" of an existing field that is not always available isn't a 
solution.

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 08:56:18 -0800 (PST)

Comparing hashes or packets is not really a workable solution because there can be true duplicate packets.  A hash will only show if the packets are the same.   Unless I am missing something.   Sometimes the problem we are trying to diagnose is how many duplicates there are.  This is an indication of congestion.   Some devices create 'false' duplicates.  That is a packet trace taken at that point will show that the packet is the same but it is only the device or the trace mechanism tracing incorrectly.  Believe me, this is not an infrequent problem.
 
Thanks,

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

________________________________
 From: Joe Touch <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Andrew Yourtchenko <[email-masked]>; IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 8:50 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

"convenience" of an existing field that is not always available isn't a solution.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 09:07:39 -0800

On 2/5/2013 8:56 AM, Nalini Elkins wrote:
> Comparing hashes or packets is not really a workable solution because
> there can be true duplicate packets.  A hash will only show if the
> packets are the same.   Unless I am missing something.

You are correct. However, since the ID in IPv4 can (and is) repeated 
quickly, and because some sources just use a constant value, there's no 
loss of information.

I.e., just because you see the same packet with the same ID doesn't mean 
it's a duplicate.

> Sometimes the
> problem we are trying to diagnose is how many duplicates there are.

That's not always possible.

>   This is an indication of congestion.

Duplication is an indication of many things, but congestion is indicated 
most accurately by loss, not duplication.

> Some devices create 'false'
> duplicates.  That is a packet trace taken at that point will show that
> the packet is the same but it is only the device or the trace mechanism
> tracing incorrectly.  Believe me, this is not an infrequent problem.

If you see a lot of packets that are exactly the same in content and 
header then you probably do have a problem.

In the end, such analysis is already based on statistics, so adjusting 
the statistics to account for the possibility of legitimate duplicate 
content shouldn't be a big deal.

Joe

> *From:* Joe Touch <[email-masked]>
> *To:* Nalini Elkins <[email-masked]>
> *Cc:* Andrew Yourtchenko <[email-masked]>; IETF v6ops list
> <[email-masked]>
> *Sent:* Tuesday, February 5, 2013 8:50 AM

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 5 Feb 2013 18:08:01 +0100 (CET)

Nalini,

On Tue, 5 Feb 2013, Nalini Elkins wrote:

> Andrew,
> 
> I wonder if possible solutions can be worked out at a brainstorming session at the IETF in Orlando.  We would like to get a group
> together to think about solutions because I can tell you, we internally have gone around with each other on different solutions and
> their drawbacks!  Performance, security and implementation difficulties being some of the problems involved.
> 

I won't make it to Orlando, but I still think that we should try to 
squeeze as much of a problem space in terms of problem definition, and 
the qualities a potential solution should have, before going to define 
the solutions themselves.

My quick sketch at how a potential solution's photorobot should look like, 
includes at least the following two traits:

1) be a property of every packet
2) be always present (i.e. not require a separate 'switch it on' knob that 
would trigger a different code path)
3) be frugal in terms of any packet space it occupies (0 bytes being the best)

Probably there's a couple more - and then the rest of the traits should 
come out from the distilled use cases that the IP ID was used for.

Such a list could then make a framework for evaluation of the 
potential solutions.

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 5 Feb 2013 18:22:22 +0100 (CET)

Nalini, Joe,

This two-mail exchange vividly illustrates why it's beneficial to
describe the problem better, and the properties of the ideal 
solution (starting with that of IP ID, but not necessarily limited to it), 
but not jump to solutions themselves straight away.

Otherwise it's too easy to get into a situation of a fish and a gull 
arguing about the sea water.

--a

On Tue, 5 Feb 2013, Nalini Elkins wrote:

> Comparing hashes or packets is not really a workable solution because there can be true duplicate packets.  A hash will only show if
> the packets are the same.   Unless I am missing something.   Sometimes the problem we are trying to diagnose is how many duplicates
> there are.  This is an indication of congestion.   Some devices create 'false' duplicates.  That is a packet trace taken at that
> point will show that the packet is the same but it is only the device or the trace mechanism tracing incorrectly.  Believe me, this
> is not an infrequent problem.
> 
> Thanks,
> 
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
> 
> ___________________________________________________________________________________________________________________________________________

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 09:25:43 -0800 (PST)

Andrew,

I like the idea of truly defining the problem space very much!   I have to say, the one problem I had with adding a fragmentation header to each packet is the number of bytes it would take add to each packet.  I know people are already talking of potential performance impacts of the additional bytes just in the IPv6 main header!   We may not have any choice at this point, but the fewer bytes added the better.

I can certainly host a webcast where anyone interested can join in and comment on what qualities a possible solution should have.   Is that a possibility for you?  Then, we don't even need to wait for Orlando!
 
Thanks,

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

Sent: Tuesday, February 5, 2013 9:08 AM
 
Nalini,

> I will ask the chairs if we can have a BOF, if this is not possible, then maybe we can all find a venue with beer and chips

I won't make it to Orlando, but I still think that we should try to squeeze as much of a problem space in terms of problem definition, and the qualities a potential solution should have, before going to define the solutions themselves.

My quick sketch at how a potential solution's photorobot should look like, includes at least the following two traits:

1) be a property of every packet
2) be always present (i.e. not require a separate 'switch it on' knob that would trigger a different code path)
3) be frugal in terms of any packet space it occupies (0 bytes being the best)

Probably there's a couple more - and then the rest of the traits should come out from the distilled use cases that the IP ID was used for.

Such a list could then make a framework for evaluation of the potential solutions.

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 5 Feb 2013 18:51:21 +0100 (CET)

Nalini,

I took a stab at the initial version of the list here:

https://docs.google.com/document/d/1TnONzdbicxwktuFzfjsZADdFSSNghK0GBzvPKAFneOc/edit?usp=sharing

I marked the doc as world-editable, and it has chat. So, both synchronous 
(with chat for coordination) and asynchronous editing is possible, and 
it's open for anyone regardless of the timezone, so should ease the 
logistics.

Let's see if this approach works in lieu of fully synchronous 
things like meetings and webcasts.

--a

On Tue, 5 Feb 2013, Nalini Elkins wrote:

> Andrew,
> 
> I like the idea of truly defining the problem space very much!   I have to say, the one problem I had with adding a fragmentation
> header to each packet is the number of bytes it would take add to each packet.  I know people are already talking of potential
> performance impacts of the additional bytes just in the IPv6 main header!   We may not have any choice at this point, but the fewer
> bytes added the better.
> 
> I can certainly host a webcast where anyone interested can join in and comment on what qualities a possible solution should have. 
> Is that a possibility for you?  Then, we don't even need to wait for Orlando!
> 
> Thanks,
> 
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
> 
> I won't make it to Orlando, but I still think that we should try to squeeze as much of a problem space in terms of problem
> definition, and the qualities a potential solution should have, before going to define the solutions themselves.
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 10:20:58 -0800

Hi, Andrew,

I completely agree; I look forward to a description of the problem.

Joe

On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote:
> describe the problem better, and the properties of the ideal solution
> (starting with that of IP ID, but not necessarily limited to it), but
> not jump to solutions themselves straight away.
>
>> there can be true duplicate packets.  A hash will only show if
>> the packets are the same.   Unless I am missing something.   Sometimes
>> the problem we are trying to diagnose is how many duplicates
>> there are.  This is an indication of congestion.   Some devices create
>> 'false' duplicates.  That is a packet trace taken at that
>> point will show that the packet is the same but it is only the device
>> or the trace mechanism tracing incorrectly.  Believe me, this

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 10:25:04 -0800

PS - I'm particularly interested in an explanation of why duplicate 
packets would be an indication of congestion, FWIW.

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 11:26:52 -0800 (PST)

Andrew,

This is wonderful!!   Thank you so much!   Let me get my crew to take a look and comment and then, if we need a synchronous meeting, then we can do it.
 
Thanks,

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

Sent: Tuesday, February 5, 2013 9:51 AM
 
Nalini,

I marked the doc as world-editable, and it has chat. So, both synchronous (with chat for coordination) and asynchronous editing is possible, and it's open for anyone regardless of the timezone, so should ease the logistics.

Let's see if this approach works in lieu of fully synchronous things like meetings and webcasts.

--a

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 5 Feb 2013 19:27:59 +0000

Andrew,

What a great start and very well done!!!

One comment.   Regards to 2.   I personally would like to see IPID always present, but there are others that feel it should be able to be switched on or off to save on overhead.   

Great start on thanks!

Mike 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Yourtchenko
Sent: Tuesday, February 05, 2013 12:51 PM
To: Nalini Elkins
Cc: IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

Nalini,

--a

On Tue, 5 Feb 2013, Nalini Elkins wrote:

> Andrew,
> 
> I like the idea of truly defining the problem space very much!   I 
> have to say, the one problem I had with adding a fragmentation header 
> to each packet is the number of bytes it would take add to each 
> packet.  I know people are already talking of potential performance impacts of the additional bytes just in the IPv6 main header!   We may not have any choice at this point, but the fewer bytes added the better.
> 
> ______________________________________________________________________
> _____________________________________________________________________
> > session at the IETF in Orlando.  We would like to get a group 
> > together to think about solutions because I can tell you, we 
> > internally have gone around with each other on different solutions
> and
> > then maybe we can all find a venue with beer and chips available!   I will post.
> 
> squeeze as much of a problem space in terms of problem definition, and the qualities a potential solution should have, before going to define the solutions themselves.
> 
> 2) be always present (i.e. not require a separate 'switch it on' knob 
> that would trigger a different code path)
> Probably there's a couple more - and then the rest of the traits 
> should come out from the distilled use cases that the IP ID was used for.
>

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 11:28:59 -0800 (PST)

Joe,

Well, duplicate packets are often retransmissions.   If you have retransmissions, then the other end (or the network) is not absorbing the flow properly.  Then, on our end, we need to see if we have allocated enough bandwidth, it is going over a sub-optimal route, etc.
 
Thanks,

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

________________________________
 From: Joe Touch <[email-masked]>
To: Andrew Yourtchenko <[email-masked]> 
Cc: Nalini Elkins <[email-masked]>; IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 10:25 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

Joe

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Feb 2013 11:29:42 -0800 (PST)

----- Original Message -----
> To: joel jaeggli <[email-masked]>; "Templin, Fred L" <[email-masked]>; IETF v6ops list <[email-masked]>
> Cc: 
> Sent: Wednesday, 6 February 2013 3:19 AM
>T hanks Joel.
> Your comment highlights our more general issue, which is that large enterprises 
> are not very active at IETF, so would not see issues such as this until they 
> deploy IPV6 in production and have a problem where facilities could be shown to 
> be missing or inadequate.   And yes, ideally speaking, that is way to late in 
> the process.  
> 

In the distant past I've worked in enterprise, and then more recently at ISPs. Enterprise networks used to be far more controlled than ISPs' networks, because in ISP networks customers bring along their own equipment and run applications of their own choosing. Troubleshooting should be harder in ISP networks because of this variety, yet reading through your use cases, it seems not to be any more.

Reading though your use cases, it seems like quite a number of them are related to faulty middle boxes, which have probably arisen in Enterprise networks since I've worked on them. The IETF advises against middle boxes because of these sorts of issues (see RFC4924). It'd be good to get more exact details of the devices that caused the issues, in particular, the devices in use cases 2 and 3.

I'm also curious how you came up with your estimates of the time saved by using IPID. For example, I'd have used standard ping with a few different packet sizes to troubleshoot the VPN packet loss issue in use case 4. For a typical packet loss issue, I'm confident I'd have identified a packet loss issue within 15 to 30 minutes (more likely 5 to 10), and identified where it was occurring along the VPN traffic path within an hour or two. So a saving of 9 hours by using IPID verses ping wouldn't be possible.

Regards,
Mark.

> This issue is somewhat separate from our RFC, but is a situation we seek to 
> address by getting more large organizations involved in IETF.   We believe that 
> would be a win/win situation, benefiting not only the large organizations 
> themselves, but IETF and networking in general as well! 
> 
> I hope you agree?
> 
> Thanks again!
> 
> Mike
> 
> 
> 
>>  The first draft you reference seems to highlight the need for an IPID field 
> larger than 16 bits (v4) or 32 bits (v6), due to the much faster networks we 
> have today.   We agree and that is very lightly referenced in our RFC.   The 
> reason for only lightly, is that we chose to focus on the need for IPID at all, 
> since many at the IETF did not agree this was an issue when we first introduced 
> it.   Our original proposal suggested going to 64 bits as part of the solution, 
> but for now we have backed off on solutions and are focused on convincing the 
> IETF that the elimination of IPID as a diagnostic facility, would be bad for end 
> user organizations.
> To be clear IPv6 never  had an analogous facility except in the fragmentation 
> header, so that state of affairs has been on the books for about 18 years.
>> 
> encapsulation, but among many other things it seems to promote the value of 
> uniquely identifying packets, in particular ones that could be duplicate, 
> improper or even malicious.    If I am interpreting properly, then we are in 
> full agreement.
>> 
>>  Our main issue is that information such as provided by IPID can be critical 
> to reliably running sophisticated networks today.
>> 
>>  Thanks again!
>> 
>>  Mike
>> 
>> 
>> 
> of the IPv4 ID Field":
> encapsulation, where the ID appears in an extension header similar to the way 
> the IPv6 fragment header currently appears.
>> 
> ensuring uniqueness other than for the fragmentation and reassembly process. 
> And, for IPv6, there are already ways to add an ID to a packet if one is needed.
>> 
>>  Thanks - Fred
> is intended solely for the use of the individual(s) to whom this communication 
> is directed. If you are not the intended recipient, you are hereby notified that

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 11:40:25 -0800

On 2/5/2013 11:28 AM, Nalini Elkins wrote:
> Joe,
>
> Well, duplicate packets are often retransmissions.

TCP should be issuing the retransmissions, at which point IP should be 
issuing new IDs.

RFC1122 recommends against TCP resending the same segment with the same 
IP ID, and RFC 6484 confirms this.

 > If you have
> retransmissions, then the other end (or the network) is not absorbing
> the flow properly.
...

If you have retransmissions, the network is losing segments. Loss can be 
the result of a transmission error OR congestion. TCP reacts to those 
losses as if they were congestion only because it is more conservative.

I.e.:
	- if you see exact duplicates, it's because a device
	is duplicating packets
		that device needs to be fixed, but that's
		rare as has already been noted

	- if you see segment retransmissions, you know there
	is loss, but you don't know why yet

Joe

> *To:* Andrew Yourtchenko <[email-masked]>
> *Cc:* Nalini Elkins <[email-masked]>; IETF v6ops list
> <[email-masked]>
> *Sent:* Tuesday, February 5, 2013 10:25 AM
>  >>> www.insidethestack.com <http://www.insidethestack.com/>
>  >>>
>  >>>
>  >>> From: Joe Touch <[email-masked] <mailto:[email-masked]>>
>  >>> To: Nalini Elkins <[email-masked]
> <mailto:[email-masked]>>
>  >>> Cc: Andrew Yourtchenko <[email-masked]
> <mailto:[email-masked]>>; IETF v6ops list
>  >>> <[email-masked] <mailto:[email-masked]>>

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Feb 2013 11:42:25 -0800 (PST)

> From: Nalini Elkins <[email-masked]>
>To: Joe Touch <[email-masked]>; Andrew Yourtchenko <[email-masked]> 
>Sent: Wednesday, 6 February 2013 6:28 AM

This can be quite easily determined by comparing sent packet counts at one end with received packet counts at the other. I'd consider doing that to be much easier than capturing 1000s of packets and then looking through them with an analyser to try to spot duplicate packets. I consider using a packet analyser to be a last resort when troubleshooting because you're usually dealing with 1000s, 10 000s or 100 000s of packets, and trying to spot a trend or pick the bad individual packet. It can also be quite onerous to setup the packet capture and the volume of data can huge.

Some of these examples are starting sound like you've been taking the approach of "how can we use IPID to troubleshoot this" rather than "what is the most effective tool to troubleshoot this", of which IPID might be one for a particular situation. 

>
>
>  If you have retransmissions, then the other end (or the network) is not absorbing the flow properly.  Then, on our end, we need to see if we have allocated enough bandwidth, it is going over a sub-optimal route, etc.
> 
>Thanks,
>
>
>Nalini Elkins
>Inside Products, Inc.
>(831) 659-8360
>www.insidethestack.com
>
>
>

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 11:42:20 -0800 (PST)

Mark,

The VPN issue, which we have run into several times, was an intermittent problem where different parties owned different parts of the infrastructure.  Pings are out of the question.   They are blocked.

These problems often go on for weeks with much finger pointing happening.   The 9 hours is an estimate.
 
Thanks,

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

________________________________
 From: Mark Smith <[email-masked]>
To: "Ackermann, Michael" <[email-masked]>; joel jaeggli <[email-masked]>; "Templin, Fred L" <[email-masked]>; IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 11:29 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

----- Original Message -----

Regards,
Mark.

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 11:48:18 -0800 (PST)

>>TCP should be issuing the retransmissions, at which point IP should be issuing new IDs.

EXACTLY!   Without a new ID, where are we?

Thanks,

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

Sent: Tuesday, February 5, 2013 11:40 AM

...

I.e.:

Joe

>  > Hi, Andrew,
>  >
>  > I completely agree; I look forward to a description of the problem.
>  >
>  > Joe
>  >
>  > On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote:
>  >> Nalini, Joe,
>  >>
>  >> This two-mail exchange vividly illustrates why it's beneficial to
>  >> describe the problem better, and the properties of the ideal solution
>  >> (starting with that of IP ID, but not necessarily limited to it), but
>  >> not jump to solutions themselves straight away.
>  >>
>  >> Otherwise it's too easy to get into a situation of a fish and a gull
>  >> arguing about the sea water.
>  >>
>  >> --a
>  >>
>  >>
>  >> On Tue, 5 Feb 2013, Nalini Elkins wrote:
>  >>
>  >>> Comparing hashes or packets is not really a workable solution because
>  >>> there can be true duplicate packets.  A hash will only show if
>  >>> the packets are the same.  Unless I am missing something.  Sometimes
>  >>> the problem we are trying to diagnose is how many duplicates
>  >>> there are.  This is an indication of congestion.  Some devices create
>  >>> 'false' duplicates.  That is a packet trace taken at that
>  >>> point will show that the packet is the same but it is only the device
>  >>> or the trace mechanism tracing incorrectly.  Believe me, this
>  >>> is not an infrequent problem.
>  >>>
>  >>> Thanks,
>  >>>
>  >>> Nalini Elkins
>  >>> Inside Products, Inc.
>  >>> (831) 659-8360
>  >>> www.insidethestack.com <http://www.insidethestack.com/>
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> From: Joe Touch <[email-masked] <mailto:[email-masked]>>
>  >>> To: Nalini Elkins <[email-masked]
>  >>> Cc: Andrew Yourtchenko <[email-masked]
>  >>> <[email-masked] <mailto:[email-masked]>>
>  >>> Sent: Tuesday, February 5, 2013 8:50 AM
>  >>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
>  >>>
>  >>> FWIW, there are two obvious solutions that work for both IPv4 and IPv6:
>  >>>
>  >>> 1) send fragmented (or fragmentable) packets
>  >>>    presuming you have control over a source
>  >>>
>  >>> 2) compare either full packets or hashes of the full packets
>  >>>
>  >>> "convenience" of an existing field that is not always available isn't
>  >>> a solution.
>  >>>
>  >>> Joe
>  >>>
>  >>>
>  >>>
>  >>>
>
>

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Feb 2013 11:53:23 -0800 (PST)

Mark,

Tools are a different topic.   A number of companies, including mine, have intelligent packet analyzers.   For us, there is nothing our products like better than thousands of packets that we can read in and then help the customer to pinpoint problems to the exact packet.  This is the trend of the future.  The volume of data and packets soon outpaces what we mere humans can do.  We need a partnership between intelligent tools and intelligent humans.

I would actually love to have a discussion at some point on best practices in troubleshooting.   Our ultimate goal is to have the right performance and troubleshooting metrix built right into the protocols from the get-go!
 
Thanks,

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

________________________________
 From: Mark Smith <[email-masked]>
To: Nalini Elkins <[email-masked]>; Joe Touch <[email-masked]>; Andrew Yourtchenko <[email-masked]> 
Cc: IETF v6ops list <[email-masked]> 
Sent: Tuesday, February 5, 2013 11:42 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 5 Feb 2013 20:25:55 +0000

Great questions!   
Here are some less than great answers:  :)

In many of the situations highlighted here, in particular some of the use case examples,   IPID was instrumental in determining where a problem existed and sometimes even IF one existed.   The user may claim unacceptable performance but sometimes the monitors and reports do not indicate a problem.   

IPID has many times allowed us, at the endpoints, show that a problem was occurring somewhere in the middle boxes.  Often these middle boxes are run by other organizations, which may be reluctant to consider they may be responsible  for any issues or degradation.   Thus, any facility, such as IPID, that can more clearly illustrate the case, can not only save time but even bring those to the table who may not want to be.    
Thus, from my perspective, IPID may be more important to end users (such as me), than to ISP's and vendors. 

I will see if more detail on the devices in cases 2 and 3 can be provided.

The time estimates are tricky and difficult to establish in many cases.   In almost every case, all of us contributing felt we estimated low to avoid any reduction in believability.    But when you add up the time to establish that there is a problem, then add the time to find where you think it might be (especially given that you don't own/control the entire network path), and then add the biggest chunk of time,  which is getting the responsible party(s) fully engaged,   you begin to see where ANY information/facility/view that can help,  can easily save you multiple hours.   These multiple hours cost large enterprises lots of $$$$.    

Most of these hours occur when a middle box responsible party checks their management system and reports  "NO PROBLEM".   It is the problems that do not appear highly visible to management systems, or are logical (vs. physical) in nature, that accrue time in these situations, while those responsible are "Convinced" to look deeper or consider things outside their normal paradigm. 

I know every situation is unique but IPID has definitely helped us and others in select situations, which is why we would hate to see it eliminated.  

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Tuesday, February 05, 2013 2:30 PM
To: Ackermann, Michael; joel jaeggli; Templin, Fred L; IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

----- Original Message -----
> To: joel jaeggli <[email-masked]>; "Templin, Fred L" 
> <[email-masked]>; IETF v6ops list <[email-masked]>
> Cc: 
> Your comment highlights our more general issue, which is that large 
> enterprises are not very active at IETF, so would not see issues such 
> as this until they deploy IPV6 in production and have a problem where 
> facilities could be shown to be missing or inadequate.   And yes, 
> ideally speaking, that is way to late in the process.
> 

Regards,
Mark.

> This issue is somewhat separate from our RFC, but is a situation we 
> seek to address by getting more large organizations involved in IETF.   
> We believe that would be a win/win situation, benefiting not only the 
> large organizations themselves, but IETF and networking in general as well!
> 
> I hope you agree?
> 
> Thanks again!
> 
> Mike
> 
> 
> 
> larger than 16 bits (v4) or 32 bits (v6), due to the much faster 
> that the elimination of IPID as a diagnostic facility, would be bad for end user organizations.
> fragmentation header, so that state of affairs has been on the books for about 18 years.
>> 
> encapsulation, but among many other things it seems to promote the 
> value of uniquely identifying packets, in particular ones that could 
> be duplicate, improper or even malicious.    If I am interpreting 
> properly, then we are in full agreement.
>> 
>> critical
> defines the cases in which the ID field does and does not contain 
> useful information. The latter is a means for adding a 32-bit ID field 
> during encapsulation, where the ID appears in an extension header 
> similar to the way the IPv6 fragment header currently appears.
>>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 5 Feb 2013 20:35:49 +0000

Regards to trying to use IPID to solve problems.  

I feel kind of the opposite.    I would really prefer NOT to use it.   

It is only a select, rare breed of problems, where we would  need to utilize IPID at all.  

Unfortunately, these rare problems are the tough ones, the important ones and the ones where you need anything you can get to resolve them. 

So I view these situations, and the use of IPID, as a last and sometimes desperate attempt to get something fixed or as stated earlier to convince someone else  to get engaged. 

So, I think you are RIGHT ON, in that we should always employ the tool or technique, which can address the issue at hand as quickly and effectively as possible.   In some cases this has been IPID, which is why we do not want it taken away in IPV6.

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 12:44:12 -0800

> EXACTLY!   Without a new ID, where are we?

Well, to be more precise:

	- a TCP segment retransmission should not result in the reuse
	of an ID

However, that's not true for IPv6 if the packet isn't already 
fragmented. Nor has it been true for a long time for packets from some 
cellphones, which reuse 0 as the ID. Nor has it been true for a long 
time for sources that are fairly modest (>7 Mbps for 1500-byte MTUs). 
Nor is not now true as allowed by RFC 6864 (which should be coming out 
of the pub queue shortly).

It's only true when a packet is fragmented (IPv4 or IPv6), or can be 
(IPv4, or IPv6 in a 6-to-4 scenario).

So assuming this is true is a bad idea. Again, the question is "what 
problem are you trying to solve".

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 12:51:15 -0800

On 2/5/2013 12:25 PM, Ackermann, Michael wrote:
...
> I know every situation is unique but IPID has definitely helped us and others in select situations, which is why we would hate to see it eliminated.

As has already been pointed out, it's already gone - both in IPv6 and in 
IPv4.

If such a tool is instrumental in analyzing network anomalies, it would 
be useful to propose an alternative. However, it's trivial to have a 
controlled source send packets with traceable contents, and I doubt we 
need to have the entire Internet send information needed to trace 
problems such as this.

Keep in mind that in IP, packet duplication is *allowed*. It's not 
desired, but unless it's a very high traffic rate, nothing should break.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 12:53:47 -0800

One observation on this doc's discussion:

a middlebox that emits non-atomic (already fragmented or DF=0) packets 
on its public side MUST already rewrite the ID; otherwise, it's already 
doesn't comply with RFC 791.

So if you're looking for a bug to fix, that's a very easy one to find.

Joe

On 2/5/2013 9:51 AM, Andrew Yourtchenko wrote:
> I marked the doc as world-editable, and it has chat. So, both
> synchronous (with chat for coordination) and asynchronous editing is
> possible, and it's open for anyone regardless of the timezone, so should
> ease the logistics.
>
>> have to say, the one problem I had with adding a fragmentation
>> header to each packet is the number of bytes it would take add to each
>> packet.  I know people are already talking of potential
>> performance impacts of the additional bytes just in the IPv6 main
>> header!   We may not have any choice at this point, but the fewer
>> bytes added the better.
>>
>> I can certainly host a webcast where anyone interested can join in and
>> comment on what qualities a possible solution should have. Is that a
>> possibility for you?  Then, we don't even need to wait for Orlando!
>>
>> Thanks,
>>
>> Nalini Elkins
>> Inside Products, Inc.
>> (831) 659-8360
>> www.insidethestack.com
>>
>> > their drawbacks!  Performance, security and implementation
>> difficulties being some of the problems involved.
>> >
>> squeeze as much of a problem space in terms of problem
>> definition, and the qualities a potential solution should have, before
>> going to define the solutions themselves.
>>
>> My quick sketch at how a potential solution's photorobot should look
>> like, includes at least the following two traits:
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Feb 2013 12:58:08 -0800

Hi Joe,

> Joe Touch
> Sent: Tuesday, February 05, 2013 12:54 PM
> To: Andrew Yourtchenko
> Cc: IETF v6ops list

Sad but true, but I suspect there are plenty of middleboxes
that already violate this requirement.

Thanks - Fred

> __________________________________________________________________________
> _________________________________________________________________
> >>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 5 Feb 2013 21:07:41 +0000

Hi joe,

Why do you say it is gone in IPV4?   
I just used it to help me diagnose an issue last week.  

I think I am in agreement with what you are saying, in that I also do not want to add any unnecessary overhead or other unnecessary processing or function.  

I do know that IPID has been a very valuable diagnostic tool to me in many critical situations over the years in v4. 
That is why I am in currently in favor of focusing this RFC on the lack of IPID in v6, as an issue and not focusing so much on what the specific solution should be at this point.
I am hopeful that if the IETF accepts this as something needing attention, that greater minds than mine can craft an optimal solution.   
Certainly sounds to me like you could/should be one of those?   

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, February 05, 2013 3:51 PM
To: Ackermann, Michael
Cc: Mark Smith; joel jaeggli; Templin, Fred L; IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

> I know every situation is unique but IPID has definitely helped us and others in select situations, which is why we would hate to see it eliminated.

As has already been pointed out, it's already gone - both in IPv6 and in IPv4.

If such a tool is instrumental in analyzing network anomalies, it would be useful to propose an alternative. However, it's trivial to have a controlled source send packets with traceable contents, and I doubt we need to have the entire Internet send information needed to trace problems such as this.

Keep in mind that in IP, packet duplication is *allowed*. It's not desired, but unless it's a very high traffic rate, nothing should break.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 13:07:44 -0800

> that already violate this requirement.

Certainly. But right now I would like to point out that:

	- there are boxes violating specs left and right
	and they're not hard to find or explain what's wrong

	- there are other boxes that are occasionally duplicating
	packets, and that's consistent with current specs

So what's broken can already be identified.

And what isn't broken doesn't warrant a new solution to detect.

IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Feb 2013 13:24:19 -0800

> I just used it to help me diagnose an issue last week.

It *can* help when it's there and when it's unique, but you can't rely 
on either one.

> Certainly sounds to me like you could/should be one of those?

I would gladly support the idea of an optional fingerprint for network 
analysis. However, the IP ID - in IPv4 or IPv6 - is not and never was 
such a fingerprint. The fact that it has been misused this way, and that 
this has proven helpful is insufficient to suggest that this mechanism 
to support fragment reassembly is appropriate for network analysis.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 Feb 2013 09:44:16 -0500

On Feb 5, 2013, at 2:53 PM, Nalini Elkins <[email-masked]> wrote:

> Mark,
> 
> Tools are a different topic.   A number of companies, including mine, have intelligent packet analyzers.  

I believe you sell packet analyzers, no? (The word "have" in the above made it sound like you purchased / own a packet analyzer from someone else).

> For us, there is nothing our products like better than thousands of packets that we can read in and then help the customer to pinpoint problems to the exact packet.  This is the trend of the future.

Ahhhh! The trend of the future. Well, that's all alright then….

>  The volume of data and packets soon outpaces what we mere humans can do.  We need a partnership between intelligent tools and intelligent humans.
> 

Oh dear…  "volume of data and packets soon outpaces what we mere humans can do".  That's worrying, because up till now I've been picking bits off the wire with an oscilloscope, scribbling them down on a piece of paper *really quickly*, converting the bits to hex in my head and then reassembling the packets and streams… Sometimes calculating the checksum on my fingers is tricky, but I usually get it right the second or third time. Oh, and don't even get me started on trying to do this with VoIP or video -- the codec designers really should take into account how hard decoding is for a human…

> I would actually love to have a discussion at some point on best practices in troubleshooting.  

So….

The last time this came up (around August 2011 in the "draft-elkins-6man-ipv6-diagnostic-header" thread, part of which is here: http://www.ietf.org/mail-archive/web/v6ops/current/msg10275.html) a number of operators who actually *do* troubleshooting provided a number of ideas.

AFACT / AFAIR, none of them said that they use IPID in v4 very often at all. They did provide a number of their troubleshooting techniques for these sorts of issues...

Some snippets from that thread:
From yourself in http://www.ietf.org/mail-archive/web/v6ops/current/msg10260.html:
"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."

We didn't see your "large corporate customers" (nor, I suspect did we really want to), but we did have a number of folk present a bunch of ideas (many of them operators who perform troubleshooting on large networks on a daily basis)

For example, Carlos suggested (http://www.ietf.org/mail-archive/web/v6ops/current/msg10266.html):
"To compare packets, we could potentially have the
network protocol analyzer (e.g., Wireshark) compute a hash on invariant
fields of the packet (i.e., exclude Hop Limit, etc), and present that as
packet metadata that is not actually carried on the wire."

you replied:
"Well, that is a really good idea that we had explored also.  Now, we ourselves make an intelligent packet analyzer and work with the WireShark folks.  If I look at this selfishly for having an extra selling point for my products, then I can say, 'Yes, we allow you to do this!  Buy my product!'  But, I was trying to be a good citizen and allow all to do this without our products.  Now, if our proposal is not adopted, then we will do the checksum or hash on the packets in our products as I think it is needed for diagnostics. "

Did you implement this? (I'd like to note that this exact same suggestion came up in this thread).

Shane Amante suggested (in http://www.ietf.org/mail-archive/web/v6ops/current/msg10270.html 
"Have you taken a look at flow-spec for IPv4:
http://tools.ietf.org/html/rfc5575

... and, flow-spec for IPv6:
http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00

(Both the RFC and I-D are within the IDR WG).

In summary, using flow-spec one can define an ACL that then get distributed across all routers within an ASN, via BGP, that can then be used to count matching packets, log packet header information, etc.  It's up to the operator to decide what ACL to be applied and what 'action' (logging, counting, etc.) to be taken for packets that match a given 'rule'.  

From where I'm sitting, this seems like it might already solve the problem you're having, without having to invent a wholly new IPv6 Destination Header Option.  So, I would like to know if you have taken a look at flow-spec and, if so, why it was ruled out?"

and then answered a bunch of your questions (from which it seemed you hadn't read the references he sent). 
Shane also suggested sFlow / NetFlow / IPFIX and ACLs with RSPAN.

Did you investigate / implement these? I don't see a flow collector / span endpoint lester in your products...

As was said in the previous go-round on this, and in this thread, it is unclear what exactly the problem statement is. 
Apart from feeling very markety[0], much of this sounds like "If all you have is a hammer, everything looks like a nail".

A simple, clear, concise description of *what* problem you are trying to solve (without any references to how much time you have saved using IPID, how it is the most wonderful, awesomest thing ever, etc) would help a bunch...

W

[0]: Which might be causing much of my grumpiness in this response...

> Our ultimate goal is to have the right performance and troubleshooting metrix built right into the protocols from the get-go!
>  
> Thanks,
> 
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
> 

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
-- Terry Pratchett

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 6 Feb 2013 07:44:38 -0800 (PST)

Warren,

I will answer few of your comments (hopefully!) in a more positive spirit than yours.

1.  Your comment: We didn't see your "large corporate customers" (nor, I suspect did we really want to), 

My answer:  Really?   Why in the world would you not want to?   What would make you say something like that?  I was under the impression that the IETF was open to everyone with concerns.  BTW, there are two large corporate customers who have actually co-authored the RFC - Blue Cross Blue Shield of Michigan and US Bank.   The other co-author is IBM.  You may have heard of them.   I wonder why you think they participated in this effort.

2.   I investigated doing a hash on the packets and it will not work.  It only indicates if there are duplicate packets.  At least one problem with that is that I have run into middleware which creates duplicate packets in traces which are really not on the wire.  I believe we discussed why hashing would not work in the RFC that we submitted.

3.  Netflow, ACLs, logs, etc are all often quite impossible to do because we do not necessarily own the network end to end or it may be a network where a business partner is involved.

3.  I suspect that the troubleshooting the operators at the IETF perform is possibly not end-to-end.  So, they may not have run into the problems that we have.

4.   A better statement of the problem is actually a good idea and you may want to look the positive approach taken by Andrew Y.

We will be updating the above document with our thoughts.

To end with, please do me the courtesy of thinking that I am not merely trying to market my products.   I believe there are other venues that would be more cost effective than the email list of the IETF.   

Thanks,

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

________________________________
 From: Warren Kumari <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Warren Kumari <[email-masked]>; Mark Smith <[email-masked]>; Joe Touch <[email-masked]>; Andrew Yourtchenko <[email-masked]>; IETF v6ops list <[email-masked]> 
Sent: Wednesday, February 6, 2013 6:44 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

So….

you replied:

W

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 6 Feb 2013 16:11:31 +0000

Two  quick reactions  to the discourses below:

#3,  These would appear to be proprietary solutions.   As a customer I would prefer to NOT depend on anything proprietary if possible and would greatly prefer  Standard solutions  intended to work on all platforms and situations.

Regards to this being an effort for Nalini to market her products.   I may be terribly confused, but I would think just the opposite.   As a customer, if I begin to lose tried and true facilities such as IPID, which have been instrumental in solving some of our more complex situations, then I would see myself becoming more dependant and reliant on products such as Nalini’s Company markets.    I view her actions/involvement as what should be best for end users and networks in general.

Thanks,

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: Wednesday, February 06, 2013 10:45 AM
To: Warren Kumari
Cc: IETF v6ops list
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

Warren,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com<http://www.insidethestack.com>
________________________________
From: Warren Kumari <[email-masked]<mailto:[email-masked]>>
To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>
Cc: Warren Kumari <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>; Joe Touch <[email-masked]<mailto:[email-masked]>>; Andrew Yourtchenko <[email-masked]<mailto:[email-masked]>>; IETF v6ops list <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 6, 2013 6:44 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

So….

you replied:

W

> www.insidethestack.com<http://www.insidethestack.com>
>
> From: Mark Smith <[email-masked]<mailto:[email-masked]>>
> To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>; Joe Touch <[email-masked]<mailto:[email-masked]>>; Andrew Yourtchenko <[email-masked]<mailto:[email-masked]>>
> Cc: IETF v6ops list <[email-masked]<mailto:[email-masked]>>
> > From: Nalini Elkins <[email-masked]<mailto:[email-masked]>>
> >To: Joe Touch <[email-masked]<mailto:[email-masked]>>; Andrew Yourtchenko <[email-masked]<mailto:[email-masked]>>
> >Cc: IETF v6ops list <[email-masked]<mailto:[email-masked]>>
> >www.insidethestack.com<http://www.insidethestack.com>
> >
> >
> >
> > From: Joe Touch <[email-masked]<mailto:[email-masked]>>
> >To: Andrew Yourtchenko <[email-masked]<mailto:[email-masked]>>
> >Cc: Nalini Elkins <[email-masked]<mailto:[email-masked]>>; IETF v6ops list <[email-masked]<mailto:[email-masked]>>
> >>>> www.insidethestack.com<http://www.insidethestack.com>
> >>>>
> >>>> From: Joe Touch <[email-masked]<mailto:[email-masked]>>
> >>>> To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>
> >>>> Cc: Andrew Yourtchenko <[email-masked]<mailto:[email-masked]>>; IETF v6ops list
> >>>> <[email-masked]<mailto:[email-masked]>>
> >[email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Feb 2013 11:50:29 -0800 (PST)

>To: Mark Smith <[email-masked]>; Joe Touch <[email-masked]>; Andrew Yourtchenko <[email-masked]> 
>Sent: Wednesday, 6 February 2013 6:53 AM
>Tools are a different topic.

I don't think they are. You are proposing changes to IPv6 to suit troubleshooting and troubleshooting tools, and nothing more. Your changes make no improvements to the performance or utility of the protocol when it is operating and being used correctly. Networks run well most of the time (when built with devices that comply with the specifications), so the threshold of acceptance for fundamental changes that just benefit troubleshooting to the already deployed implementations of protocols is going to be high.

>  A number of companies, including mine, have intelligent packet analyzers.   For us, there is nothing our products like better than thousands of packets that we can read in and then help the customer to pinpoint problems to the exact packet.

Do you give those packet analysers away for free? The tools I commonly use (ping and traceroute) are free. 

Change creates opportunities for failure. Changing a device to perform traffic mirroring, or inserting a packet analyser inline with traffic may or will disrupt services. In a properly run network, these changes will have to be done during a scheduled maintenance window of some form. In the case of enabling traffic mirroring, considering what it is asking the device to do, considering the volume of traffic it might be asked to mirror, and how different it is from it's normal operation, there is a reasonable risk the device will fail when it is enabled, causing a service outage. So the safe thing to do is make these changes outside of core operating hours. At a residential ISP that was between 5.30 am and 6.30 am. Organising that is onerous, even if you give me one of your packet analysers for free. I'm going to try to use my free tools and ones that don't require any changes to the operation of my devices or my network, and no scheduled maintenance
 window, before I'm going to resort to change management procedures and out of hours work. I'm sure my users want that too, because I can diagnose their problem sooner, reducing the mean time to repair for the fault.

>  This is the trend of the future.  The volume of data and packets soon outpaces what we mere humans can do.

That's always been the case for me. I can't even process 300 baud at line rate.

 > We need a partnership between intelligent tools and intelligent humans.
>I would actually love to have a discussion at some point on best practices in troubleshooting.   Our ultimate goal is to have the right performance and troubleshooting metrix built right into the pr…

The get-go for IPv6 was in the mid 1990s.

Yourself and others seem to be assuming that it is impossible to troubleshoot IP networks without IPID, in particular with statements such as :

"Our main issue is that information such as provided by IPID can be critical to reliably running sophisticated networks today."

Yet if IPID was the only way to troubleshoot these problems, it wouldn't be a new technique to me (it'd have been taught to me when I learned ping and traceroute), and I have and do work on "sophisticated networks" that have had critical reliability requirements. IPID isn't as essential as it is being made out to be.

>This can be quite easily determined by comparing sent packet counts at one end with received packet counts at the other. I'd
consider doing that to be much easier than capturing 1000s of packets and then looking through them with an analyser to try to spot duplicate packets. I consider using a packet analyser to be a last resort when troubleshooting because you're usually dealing with 1000s, 10 000s or 100 000s of packets, and trying to spot a trend or pick the bad individual packet. It can also be quite onerous to setup the packet capture and the volume of data can huge.
>>PS - I'm particularly
interested in an explanation of why duplicate 
--a
Thanks,