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

From: joel jaeggli <[email-masked]>
Date: Thu, 14 Mar 2013 11:13:58 -0400

some more thoughts since the presentation.

Noted that I consulted the earlier draft, discussion in 6-man and 
appendix a in the slides.

http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00

was the previous one.

The request is not really for the ipv4 IPID/frag header in v6. it's for 
a unique per packet value over a given sample interval.

The utility of ipid in ipv4 for this context has eroded over time, (this 
is not knock againt the draft I'm just trying to describe my 
understanding of the utility). IPID's in the context of mobile 
phones/mobile networks are typically unvarrying (due to header 
compresssion). rfc 6864 exists because modern implmentations cannot (and 
therefore don't) honor requirements for uniqueness in rfc791,rfc1122 
e.g. the duration over which 16 bit IPID is valid for uniqueness is 
bounded by the size of the flow because if it were limited by the MDL it 
would limit that speed of a flow. a 10Gb/s flow with 1500 byte packets 
overflows a 16 bit value every 78 or so ms. if your capture is longer 
than that you can reasonably expect duplicate IPIDS to show up which are 
readily identifiable as not being duplicate packets.

desirable properties of a unique per packet value to my mind...

* That it doesn't cost us anything - it strikes me as undesirable that 
packets should in general have larger headers then they do today that 
adds cost all over the place. extension header processing or indeed 
fragmentation header use has conquences.

see http://tools.ietf.org/html/draft-wkumari-long-headers-00

for dicussion that has come up about header processing in modern routers.

and

http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00

for a similar discussion about fragmentation headers.

neither of these represent any form of consensus document, so take that 
with a grain of salt.

* That it is applied to every packet - part of the stated utility of the 
ipv4 ipid is that it's present (with my noted caveats) you don't have to 
turn it on. likewise this implies that the application of the value does 
not impact the observation, having the packet size change because you're 
doing debugging means imho that you're not doing the

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 14 Mar 2013 14:52:36 -0700 (PDT)

Joel,

Thanks so much for your feedback.   One of the alternatives that we are looking at to provide a Packet Sequence Number is a 'SHIM' such as that provided by SEAL.

http://tools.ietf.org/html//rfc5320

This header (if I am reading this correctly!) would be between the TCP or UDP header and the application payload.

One of the things that SEAL provides is:

SEAL_ID - a 32-bit Identification value, randomly initialized and monotonically incremented for each SEAL protocol packet

So, this might provide exactly what we are looking for!   

We do understand that there are a number of issues with IPv6 extension headers.   We are not wedded to a particular implementation and whatever will provide the information we need is perfect!   But, we have just found out about this RFC and need to study it more to see if there are any drawbacks.

Thanks,

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

________________________________
From: joel jaeggli <[email-masked]>
To: IPv6 Ops WG <[email-masked]> 
Sent: Thursday, March 14, 2013 8:13 AM
Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Noted that I consulted the earlier draft, discussion in 6-man and appendix a in the slides.

was the previous one.

The request is not really for the ipv4 IPID/frag header in v6. it's for a unique per packet value over a given sample interval.

The utility of ipid in ipv4 for this context has eroded over time, (this is not knock againt the draft I'm just trying to describe my understanding of the utility). IPID's in the context of mobile phones/mobile networks are typically unvarrying (due to header compresssion). rfc 6864 exists because modern implmentations cannot (and therefore don't) honor requirements for uniqueness in rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for uniqueness is bounded by the size of the flow because if it were limited by the MDL it would limit that speed of a flow. a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or so ms. if your capture is longer than that you can reasonably expect duplicate IPIDS to show up which are readily identifiable as not being duplicate packets.

* That it doesn't cost us anything - it strikes me as undesirable that packets should in general have larger headers then they do today that adds cost all over the place. extension header processing or indeed fragmentation header use has conquences.

and

neither of these represent any form of consensus document, so take that with a grain of salt.

* That it is applied to every packet - part of the stated utility of the ipv4 ipid is that it's present (with my noted caveats) you don't have to turn it on. likewise this implies that the application of the value does not impact the observation, having the packet size change because you're doing debugging means imho that you're not doing the
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Mar 2013 22:27:36 +0000

Hi Nalini,

Just to clarify, RFC5320 will soon be obsoleted by 'draft-templin-intarea-seal'.
But, also note that the source and destination would both need to be SEAL-aware,
so the complexity would be worse than just asking the source to unconditionally
include an IPv6 fragment header with a well-behave ID.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nalini Elkins
> Sent: Thursday, March 14, 2013 2:53 PM
> To: joel jaeggli; IPv6 Ops WG
> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
> 
> Joel,
> 
> Thanks so much for your feedback.   One of the alternatives that we are
> looking at to provide a Packet Sequence Number is a 'SHIM' such as that
> provided by SEAL.
> 
> SEAL_ID - a 32-bit Identification value, randomly initialized and
> monotonically incremented for each SEAL protocol packet
> 
> We do understand that there are a number of issues with IPv6 extension
> headers.   We are not wedded to a particular implementation and whatever
> will provide the information we need is perfect!   But, we have just found
> out about this RFC and need to study it more to see if there are any
> drawbacks.
> 
> Thanks,
> 
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
> 
> 
> 
> The request is not really for the ipv4 IPID/frag header in v6. it's for a
> unique per packet value over a given sample interval.
> 
> is not knock againt the draft I'm just trying to describe my understanding
> of the utility). IPID's in the context of mobile phones/mobile networks
> are typically unvarrying (due to header compresssion). rfc 6864 exists
> because modern implmentations cannot (and therefore don't) honor
> requirements for uniqueness in rfc791,rfc1122 e.g. the duration over which
> 16 bit IPID is valid for uniqueness is bounded by the size of the flow
> because if it were limited by the MDL it would limit that speed of a flow.
> a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or
> so ms. if your capture is longer than that you can reasonably expect
> duplicate IPIDS to show up which are readily identifiable as not being
> duplicate packets.
> 
> packets should in general have larger headers then they do today that adds
> cost all over the place. extension header processing or indeed

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 14 Mar 2013 15:37:30 -0700 (PDT)

Fred,

Thanks for your comments.

We are getting a lot of comments from people that the reality of the situation is that many firewalls drop packets with IPv6 extension headers.   Including fragment header.   People seem to feel there are a lot of security issues with IPv6 extension headers.  I do feel that adding an atomic fragment header with each packet would have been a great solution but does not seem to have much support.   We have not ruled anything out but I am just telling you what we are hearing.

BTW, any chance of getting a timestamp in the SEAL header?
 
Thanks,

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

________________________________
 From: "Templin, Fred L" <[email-masked]>
To: Nalini Elkins <[email-masked]>; joel jaeggli <[email-masked]>; IPv6 Ops WG <[email-masked]> 
Sent: Thursday, March 14, 2013 3:27 PM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Hi Nalini,

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 14 Mar 2013 15:38:32 -0700

Hi, all,

SEAL wraps IP packets. If you put a shim above the transport layer 
(between TCP/UDP and the app payload), then you might not get the 
semantics you want.

Wrapping UDP messages is fine - presuming you look at the wrapper only 
at the endpoints; IP fragmentation may mean the wrapper isn't available 
for some datagrams.

Wrapping TCP segments is a bad idea IMO, and doesn't make sense.

TCP segments exist only at the TCP layer, and those boundaries are 
invisible to the application layer. The boundaries of what is written, 
transmitted, received, and, read may differ (the middle two due to 
rewriting proxies, which are evil but real).

If you want/need a network identifier for diagnostics, it has to exist 
at the network layer.

NB - as we noted during the discussion of RFC6864, the IPv6 ID can exist 
*either* when the source fragments *or* when a 6-to-4 translation is 
required even for datagrams that otherwise fit in an IPv6 MTU. You might 
update your intro accordingly:

    ...The IPv6 fragment
    header is present only when a datagram has been fragmented, or when
    the source has received a "packet too big" ICMPv6 error message
    indicating that the path cannot support the required minimum
    1280-byte IPv6 MTU and is thus subject to translation [RFC2460]
    [RFC4443].  The latter case is relevant only for IPv6 datagrams sent
    to IPv4 destinations to support subsequent fragmentation after
    translation to IPv4.

Regarding this draft, it would be useful to explain why using the entire 
packet (or a hash thereof) isn't nearly as useful in most cases (and 
that would not require a new ID).

Again, note that most IPv4 implementations do not implement the ID 
uniqueness requirements in RFC791, and some use repeated IDs (even that 
don't compress headers).

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Mar 2013 00:50:50 +0000

Hi Joe,

> Joe Touch
> Sent: Thursday, March 14, 2013 3:39 PM
> To: Nalini Elkins
> Cc: IPv6 Ops WG

Isn't it true that network middleboxes like NATs might even
take it upon themselves to rewrite the IP_ID field for packets
in flight? For example, if there are many hosts inside the NAT
that might want to talk to the same server outside of the NAT
then the packets from multiple hosts would use a shared source
address of the NAT and the same destination address and so could
experience significant collisions in IP_ID if the NAT did not
rewrite. I have seen it suggested somewhere that NATs should
rewrite the IP_ID to a random value, but I'm not sure if many
implementations do that. What has been your experience?

Thanks - Fred 

> > This header (if I am reading this correctly!) would be between the TCP
> or UDP header and the application payload.
> >

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Mar 2013 09:17:50 -0400

Le 2013-03-14 20:50, Templin, Fred L a écrit :
> I have seen it suggested somewhere that NATs should

Here's one implementation that does that:
http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf

>      random-id
>            Replaces the IPv4 identification field with random values to
>            compensate for predictable values generated by many hosts.  This
>            option only applies to packets that are not fragmented after the
>            optional fragment reassembly.

Off by default.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Dan Wing <[email-masked]>
Date: Fri, 15 Mar 2013 10:36:27 -0400

> http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf

Perhaps a reaction to Bellovin's "A Technique for Counting NATted Hosts", https://www.cs.columbia.edu/~smb/papers/fnat.pdf

-d

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Mar 2013 14:49:10 +0000

Hi Dan,

> Perhaps a reaction to Bellovin's "A Technique for Counting NATted Hosts",
> https://www.cs.columbia.edu/~smb/papers/fnat.pdf

Thanks for that reference. I read that document years ago but lost
the URL, and that was where my comment originated from.

Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Mar 2013 09:43:03 -0700

>>            optional fragment reassembly.

FWIW, that's a violation of RFC 791.

NATs, as the source of IP packets with their address, need to reassemble 
incoming datagram fragments and send packets with unique IDs.

Picking "random" values can/will potentially interfere with 
fragmentation and reassembly, especially when those values don't 
consider how they might step on values used by fragments OR when 
'random' isn't unique as expected if the DF bit isn't set.

Joe

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Mar 2013 12:50:32 -0400

Only if the default reassembly behaviour is turned off. See:

>      set reassemble
>              The reassemble option is used to enable or disable the reassembly
>              of fragmented packets, and can be set to yes (the default) or no.
>              If no-df is also specified, fragments with the dont-fragment bit
>              set are reassembled too, instead of being dropped; the
>              reassembled packet will have the dont-fragment bit cleared.

> 'random' isn't unique as expected if the DF bit isn't set.

It might be a documentation bug. Here's the description of the function 
used for generating a "random ID". It's not really random...

> /*
>  * Return a random IP id.  Shuffle the new value we get into the previous half
>  * of the ip_shuffle ring (-32767 or swap with ourself), to avoid duplicates
>  * occuring too quickly but also still be random.
>  *
>  * 0 is a special IP ID -- don't return it.
>  */
> u_int16_t
> ip_randomid(void)
> {
>...

Does pf get the IETF seal of approval now? ;)

Simon

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Mar 2013 10:55:46 -0700

Hi, Simon,

On 3/15/2013 9:50 AM, Simon Perreault wrote:
> Only if the default reassembly behaviour is turned off.

Reassembly should be required at NATs; otherwise, they can't ensure that 
fragments can be reassembled (because they might give them different 
IDs, or might go through different NATs).

> See:

"avoiding duplicates too quickly" is not compliant. The rule is to 
**ensure** that IDs are not duplicated during the maximum datagram 
lifetime (typically considered 2 minutes; related to the max reassembly 
lifetime). That includes throttling the generation of new IDs when 
necessary.

> Does pf get the IETF seal of approval now? ;)

Nope, as per above. The rules aren't stated as "SHOULD NOT" repeat; they 
are "MUST NOT" -- when DF=0. The rules for handling NATs and IDs, as 
well as ID uniqueness, were stated in such terms in RFC 6864, and the 
ink is barely dry on that.

Joe

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 15 Mar 2013 21:32:45 +0000

And at the risk of being flamed, I am fully supportive for firewalls (if you need one) to drop anything that they are unable to understand.

This does not mean that I am not supportive of solving the problem raised by Nalini of course

-éric

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: jeudi 14 mars 2013 23:38
To: Templin, Fred L; joel jaeggli; IPv6 Ops WG
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Fred,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com<http://www.insidethestack.com>
________________________________
From: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>; IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 14, 2013 3:27 PM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi Nalini,

Thanks - Fred
[email-masked]<mailto:[email-masked]>

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Nalini Elkins
> http://tools.ietf.org/html//rfc5320<http://tools.ietf.org/html/rfc5320>
>
> www.insidethestack.com<http://www.insidethestack.com/>
>
>
>
> From: joel jaeggli <[email-masked]<mailto:[email-masked]>>
> To: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Nalini Elkins <[email-masked]>
Date: Sat, 16 Mar 2013 06:36:40 -0700 (PDT)

Correct me if I am wrong, but I have to think that most firewalls are only dropping packets that they are TOLD to drop.  That is, an option has been set by the network operator to drop certain packets.  Maybe these packets include IPv6 extension headers (fragment or otherwise).   It is, of course, possible that some firewalls (or other middle boxes) do not understand certain packets and drop them or feel that ANY packets containing IPv6 extension headers are suspect.  This, I find to be an over-reaction.   How is this OK? 

I understand that this is likely indeed the case, and primary allegiance must be to reality or what is ACTUALLY happening on real networks, but wouldn't some level of nuance or discrimination be better behavior?   Yes, I know that many security attacks can be launched using IPv6 extension headers and I can give you a detailed list of many of them.    

Having said that, I was just at a site yesterday where they have been using IPv6 for quite a few years.  They tell me that they see quite a few IPv6 Fragment Headers on DNSSEC responses on their internal network.   BUT, they do not have tons of firewalls internally.   When they connect to a partner, they can indeed see that packets containing fragment headers are being dropped.   

So, whatever behavior one may choose on one's own internal network, one cannot dictate to a business partner.   This is what is bringing up thoughts of alternative solutions to our problems.   I will detail those in the response to Joe Touch's list entry.

Thanks,

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

________________________________
 From: Eric Vyncke (evyncke) <[email-masked]>
To: Nalini Elkins <[email-masked]>; "Templin, Fred L" <[email-masked]>; joel jaeggli <[email-masked]>; IPv6 Ops WG <[email-masked]> 
Sent: Friday, March 15, 2013 5:32 PM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

 
 
-éric
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: jeudi 14 mars 2013 23:38
To: Templin, Fred L; joel jaeggli; IPv6 Ops WG
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Fred,

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

From:"Templin, Fred L" <[email-masked]>
To: Nalini Elkins <[email-masked]>; joel jaeggli <[email-masked]>; IPv6 Ops WG <[email-masked]> 
Sent: Thursday, March 14, 2013 3:27 PM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi Nalini,

Thanks - Fred

> http://tools.ietf.org/html/rfc5320
>

---

From: Owen DeLong <[email-masked]>
Date: Sun, 17 Mar 2013 03:13:16 -0700

> Correct me if I am wrong, but I have to think that most firewalls are only dropping packets that they are TOLD to drop.  That is, an option has been set by the network operator to drop certain pack…

Hopefully quite the reverse… A firewall should drop any packet it has not been told to pass.

The operator should set options to pass certain packets.

If the firewall doesn't provide sufficient interface knobs to accept certain packets (e.g. IPv6, Fragments, extension headers, etc.), then it may not be possible to cause the firewall not to drop them.

If your default is to drop all packets that you are not configured to accept and you lack the UI to be configured to accept some forms of packets, there is no way you can pass those packets. This is quite acceptable and expected. What is neither acceptable nor expected at this point is the abysmal state of firewall development WRT IPv6.

Owen

---

From: Nalini Elkins <[email-masked]>
Date: Sun, 17 Mar 2013 04:24:09 -0700 (PDT)

Owen - well said!
 
Thanks,

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

________________________________
 From: Owen DeLong <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Eric Vyncke (evyncke) <[email-masked]>; "Templin, Fred L" <[email-masked]>; joel jaeggli <[email-masked]>; IPv6 Ops WG <[email-masked]> 
Sent: Sunday, March 17, 2013 6:13 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Owen

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sun, 17 Mar 2013 15:45:25 +0000

ECHO!!!!!!!!!!

And unfortunately until Firewalls and other security devices “Catch up”,   deployments at installations such as mine will be slowed (or worse).    ☹

From: Nalini Elkins [mailto:[email-masked]]
Sent: Sunday, March 17, 2013 7:24 AM
To: Owen DeLong
Cc: Eric Vyncke (evyncke); Templin, Fred L; joel jaeggli; IPv6 Ops WG
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Owen - well said!

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com<http://www.insidethestack.com>
________________________________
From: Owen DeLong <[email-masked]<mailto:[email-masked]>>
To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>
Cc: Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>>; "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>; joel jaeggli <[email-masked]<mailto:[email-masked]>>; IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, March 17, 2013 6:13 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

On Mar 16, 2013, at 6:36 AM, Nalini Elkins <[email-masked]<mailto:[email-masked]>> wrote:

Owen

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: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Mar 2013 15:45:11 +0000

Hi Joe,

> Sent: Friday, March 15, 2013 10:56 AM
> To: Simon Perreault
> Cc: [email-masked]

True, the NAT should collect up all of the fragments of a fragmented
datagram before forwarding them. However, RFC1812 says:

   "A router MUST NOT reassemble any datagram before forwarding it."

For that reason, NATs should do virtual fragment reassembly, i.e.,
collect up the fragments but then forward them on without reassembly
once all fragments arrive.

This is important, because the source and destination may have some
sort of mutual understanding that packets will be sent and received
as multiple IP fragments. If the NAT steps into the middle and does
reassembly, then this understanding is violated.

This is starting to veer off into an IPv4 topic, but I think the
same considerations would apply also for IPv6.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2013 09:07:33 -0700

Hi, Fred,

>     "A router MUST NOT reassemble any datagram before forwarding it."

A NAT isn't a router. It acts like a host for the purposes of RFC1812, 
because it sources packets with its own IP address (to the public side), 
and acts as the sink of public addresses (to the private side).

> once all fragments arrive.

That may be a useful optimization, but its the same net effect. The only 
difference is whether the fragment boundaries are the same before/after 
the NAT, and that doesn't matter for the purposes of PMTUD, etc.

> reassembly, then this understanding is violated.

Source and dest exchange IP packets, not fragments. Any other 
understanding between the endpoints is already violated by the NAT 
process itself.

> same considerations would apply also for IPv6.

Agreed; most of the considerations I'm discussing are applicable to both 
v4 and v6.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Mar 2013 16:22:19 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, March 18, 2013 9:08 AM
> To: Templin, Fred L
> Cc: Simon Perreault; [email-masked]
> >>>>>>             Replaces the IPv4 identification field with random
> values
> >> to
> >>>>>>             compensate for predictable values generated by many
> hosts.
> >>>>>> This

I had a feeling you would say that, but a NAT is really a
hybrid of sorts that exhibits some host functions and some
router functions. For the purpose of handling fragments, it
needs to behave as a router.

> the NAT, and that doesn't matter for the purposes of PMTUD, etc.

It isn't an optimization; the NAT still has to dedicate reassembly
resources for all of the fragments even though it won't be reassembling.
Instead, it is the only correct behavior permissible by RFC1812.

It also does not have the same net effect. With *real* reassembly,
the destination sees only whole IP packets and has no notion that
the packets may have been fragmented at some earlier hop(s) of the
path from the source. With *virtual* reassembly, the destination
gets to see that the packets were fragmented.

> understanding between the endpoints is already violated by the NAT

I disagree. If the source has some reason to send the destination
fragmented packets, it should reasonably expect that they will
arrive at the destination as fragments and not as whole packets.
That is what virtual fragment reassembly is all about.

> Agreed; most of the considerations I'm discussing are applicable to both

OK.

Thanks - Fred

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 18 Mar 2013 10:31:35 -0700 (PDT)

Guys,

Maybe it would be best to back up a bit, and start with what we want, why we want it and what we know to be some of the problems.

1.   There is a class of applications for which the time for diagnostics,  performance and ability to manage is critical.  These may be financial (as ours are) but they may also be 911 in a city government, law enforcement, and others.   

2.   The platform may be IBM-mainframe based, Windows, Unix or cell phone.

3.   Often problems are reported after the fact.  As in, the Wire Transfer from xxx organization was too slow or did not complete properly.

4.   Again, often, packet traces are either available or are the easiest way to diagnose such problems.  Packet traces may be available because all packets are sometimes stored for regulatory reasons (ex.  all stock trades must be saved, etc).   Packet traces are often easiest because the organization does not necessarily own all the equipment and middle boxes or because a business partner is involved.   An organization which owns all the hardware can do diagnostics differently.  I used to work for such an organization and we would likely have stuck a hardware probe on immediately.  This is quite often not an option in many organizations.

5.  In IPv4, one of the fields we used was the IP ID.  Even though, this field was meant for fragmentation, one of the properties it had (on many platforms) was sequentiality.   We used it as a de-facto packet sequence number and also an eye catcher to know when the packet trace that we are looking at is corrupted or has potential inaccuracies.   What can happen is that middle boxes can sometimes duplicate packets ONLY FOR SOME nodes or when we extract packets from one of the devices which are continuously capturing packets, the extract itself is wrong.   This is actually why hash of the packets will not work and why we need it for TCP.

6.  Packet sequence number turns out to be quite an interesting and useful number - with all the drawbacks it has of potential wrapping, etc.   Taken in conjunction with TTL and other fields, it can often reduce problem diagnostic time considerably.   Our motto is: do not let the perfect be the enemy of the good.  

Now, because IP ID is not in the main IP header in IPv6 and may not be available in IPv4, we are looking for a potential solution.  We are not going to deal with IPv4 - we will only move forward to IPv6.  Let me detail some of the known problems with solutions we have looked at:

1.   Use IPv6 Fragment extension header with # of fragments set to 0 (atomic fragments).   The problem with this is that many firewalls (and possibly other devices) drop these.   You may be able to control this in your network but cannot in other peoples.  That is, business partners.

2.  Use IPv6 Dest Options extension header: similar issues as above but possibly even more as this may be even more unrecognized by middle boxes.  Also, I have been told that adding IPv6 extension headers will make the routing of the packets through routers and middle boxes route at a software rather than hardware layer, thus slowing the performance.  Guys, am I right?

3.  So, now, we are trying to go back up the layers and consider the SHIM possibility.  That is, introduce a header that is between TCP and UDP and the application. The idea of a SHIM was brought to us by Ron Bonica (Ron, we owe you a beer in Berlin!).   This seems attractive in that only those applications which wish to employ this can do it.  It also I believe gets us away from the IP layer.   It seems that changes at the IP layer are quite problematic.

4.  Then, we thought, if we are adding fields, something we would REALLY like is a timestamp in every packet.   So, we are considering designing a PD-SHIM (Performance and Diagnostics SHIM) which will have a number of these quite interesting fields.  This is when we started looking at Fred Templin's SEAL implementation.  But, it we may need different fields.  

BTW,  we are physically located in the Monterey and San Francisco Bay areas.  So, Joe, if you have time, we can certainly drive down to Southern California and maybe we can chat for an hour or two.  I will contact you offline about that.

Thanks,

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

________________________________
 From: Joe Touch <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: joel jaeggli <[email-masked]>; IPv6 Ops WG <[email-masked]> 
Sent: Thursday, March 14, 2013 3:38 PM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Hi, all,

NB - as we noted during the discussion of RFC6864, the IPv6 ID can exist 
*either* when the source fragments *or* when a 6-to-4 translation is 
required
 even for datagrams that otherwise fit in an IPv6 MTU. You might 
update your intro accordingly:

    ...The IPv6 fragment

Again, note that most IPv4 implementations do not implement the ID 
uniqueness requirements
 in RFC791, and some use repeated IDs (even that 
don't compress headers).

Joe

On 3/14/2013 2:52 PM, Nalini Elkins wrote:
> We do understand that there are a number of issues with IPv6 extension headers.   We are not wedded to a particular implementation and whatever will
 provide the information we need is perfect!   But, we have just found out about this RFC and need to study it more to see if there are any drawbacks.
> The utility of ipid in ipv4 for this context has eroded over time, (this is not knock againt the draft I'm just trying to describe my understanding of the utility). IPID's in the context of mobile phones/mobile networks are typically unvarrying (due to header compresssion). rfc 6864 exists because modern implmentations cannot (and therefore don't) honor requirements for uniqueness in rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for uniqueness is bounded by the size of the flow because if it were limited by the MDL it would limit that speed of a flow. a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or so ms. if your capture is longer than that you
 can reasonably expect duplicate IPIDS to show up which are readily identifiable as not being duplicate packets.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 18 Mar 2013 10:51:05 -0700

On 3/18/13 10:31 AM, Nalini Elkins wrote
>
> 2.  Use IPv6 Dest Options extension header: similar issues as above 
> but possibly even more as this may be even more unrecognized by middle 
> boxes.  Also, I have been told that adding IPv6 extension headers will 
> make the routing of the packets through routers and middle boxes route 
> at a software rather than hardware layer, thus slowing the 
> performance.  Guys, am I right?
This characterization extends back in time to when there was a software 
forwarding path, and while there may still be devices that have one,the 
class of high performance routers and L3 switches doing the heavy 
lifting effectively have a choice between asic-based-forwarding and no 
forwarding. If headers can safely beignored, great. if the addition of 
extensionheaders perturbs the the forwarding decision in some fashion 
(can't find the L4 header for example) the forwarding decision may be 
different, (or result in the packet being dropped) than the forwarding 
decision made without that header.

---

From: james woodyatt <[email-masked]>
Date: Mon, 18 Mar 2013 11:21:42 -0700

On Mar 18, 2013, at 10:51 , joel jaeggli <[email-masked]> wrote:
>> 2.  Use IPv6 Dest Options extension header [...]
> 
> ...if the addition of extension headers perturbs the the forwarding decision in some fashion (can't find the L4 header for example)...

So... if adding a destination option header makes it impossible for interior routers to find the upper layer transport header in their hardware forwarding path... then what exactly is it we think we are doing here?  I'm not being entirely facetious.

--
james woodyatt <[email-masked]>
core os networking

---

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Mar 2013 14:54:35 -0400

On Mar 18, 2013, at 2:21 PM, james woodyatt <[email-masked]> wrote:

> So... if adding a destination option header makes it impossible for interior routers to find the upper layer transport header in their hardware forwarding path... then what exactly is it we think we are doing here?

Dunno what you are doing, but a number of folk are dropping the packet…. ;-)

>  I'm not being entirely facetious.

Me neither - http://tools.ietf.org/html/draft-wkumari-long-headers-00

If a router cannot see the L4 header (because it is a fragment or because the header is simply past the cell size), and you want to only allow known traffic into your network, you have no real choice but to assume it is bad and toss it...

W

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. 
   ---maf

Warren Kumari
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2013 13:43:01 -0700

Hi, Fred,

...
> needs to behave as a router.

Routers should NEVER aggregate the fragments before forwarding, nor 
should it expect to see the whole set of fragments.

I agree that a NAT is a hybrid in some ways - e.g., it should decrement 
the hopcount - but regarding IDs, fragments, etc - it MUST behave as a 
host exactly because it either sources packets or acts as if it were the 
sink.

> Instead, it is the only correct behavior permissible by RFC1812.

NATs should do reassembly, period. There's no reason to do anything 
else, and it is the only permissible behavior by RFC1122. This is 
governed by that RFC because the NAT is a source or (false) sink of the 
addresses.

> gets to see that the packets were fragmented.

It cannot possibly matter. If you have the time to see all the 
fragments, you have time to reassemble - and refragment - them.

Fragment boundaries are semantically meaningful - and should only be 
visible - to IP anyway.

> That is what virtual fragment reassembly is all about.

They arrive at the destination IP layer as fragments, but at the next 
layer up as whole packets anyway. I don't see a good reason why fragment 
boundaries are sacrosanct but IP addresses and ports can be rewritten. 
Once you rewwrite, you act as a the source anyway, and all bets of what 
the orignal source intended are off.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2013 13:49:56 -0700

I'm lost on one key point - why not use the packets themselves? Why 
focus on a single field?

Regardless, it seems like your business model is based on assumptions 
that were never sound (assuming sequential IDs), have become even less 
sound (no ID in most IPv6 and even some IPv4), and are now approved as 
not sound (RFC 6864). Maybe it's time to change your assumptions ;-)

Joe

On 3/18/2013 10:31 AM, Nalini Elkins wrote:
> Guys,
>
> Maybe it would be best to back up a bit, and start with what we want,
> why we want it and what we know to be some of the problems.
>
> 1.   There is a class of applications for which the time for
> diagnostics,  performance and ability to manage is critical.  These may
> be financial (as ours are) but they may also be 911 in a city
> government, law enforcement, and others.
>
> 3.   Often problems are reported after the fact.  As in, the Wire
> Transfer from xxx organization was too slow or did not complete properly.
>
> 4.   Again, often, packet traces are either available or are the easiest
> way to diagnose such problems.  Packet traces may be available because
> all packets are sometimes stored for regulatory reasons (ex.  all stock
> trades must be saved, etc).   Packet traces are often easiest because
> the organization does not necessarily own all the equipment and middle
> boxes or because a business partner is involved.   An organization which
> owns all the hardware can do diagnostics differently.  I used to work
> for such an organization and we would likely have stuck a hardware probe
> on immediately.  This is quite often not an option in many organizations.
>
> 5.  In IPv4, one of the fields we used was the IP ID.  Even though, this
> field was meant for fragmentation, one of the properties it had (on many
> platforms) was sequentiality.   We used it as a de-facto packet sequence
> number and also an eye catcher to know when the packet trace that we are
> looking at is corrupted or has potential inaccuracies.   What can happen
> is that middle boxes can sometimes duplicate packets ONLY FOR SOME nodes
> or when we extract packets from one of the devices which are
> continuously capturing packets, the extract itself is wrong.   This is
> actually why hash of the packets will not work and why we need it for TCP.
>
> 6.  Packet sequence number turns out to be quite an interesting and
> useful number - with all the drawbacks it has of potential wrapping,
> etc.   Taken in conjunction with TTL and other fields, it can often
> reduce problem diagnostic time considerably.   Our motto is: do not let
> the perfect be the enemy of the good.
>
> Now, because IP ID is not in the main IP header in IPv6 and may not be
> available in IPv4, we are looking for a potential solution.  We are not
> going to deal with IPv4 - we will only move forward to IPv6. Let me
> detail some of the known problems with solutions we have looked at:
>
> 1.   Use IPv6 Fragment extension header with # of fragments set to 0
> (atomic fragments).   The problem with this is that many firewalls (and
> possibly other devices) drop these.   You may be able to control this in
> your network but cannot in other peoples.  That is, business partners.
>
> 2.  Use IPv6 Dest Options extension header: similar issues as above but
> possibly even more as this may be even more unrecognized by middle
> at a software rather than hardware layer, thus slowing the performance.
>   Guys, am I right?
>
> 3.  So, now, we are trying to go back up the layers and consider the
> SHIM possibility.  That is, introduce a header that is between TCP and
> UDP and the application. The idea of a SHIM was brought to us by Ron
> Bonica (Ron, we owe you a beer in Berlin!).   This seems attractive in
> that only those applications which wish to employ this can do it.  It
> also I believe gets us away from the IP layer.   It seems that changes
> at the IP layer are quite problematic.
>
> 4.  Then, we thought, if we are adding fields, something we would REALLY
> like is a timestamp in every packet.   So, we are considering designing
> a PD-SHIM (Performance and Diagnostics SHIM) which will have a number of
> these quite interesting fields.  This is when we started looking at Fred
> Templin's SEAL implementation.  But, it we may need different fields.
>
> BTW,  we are physically located in the Monterey and San Francisco Bay
> areas.  So, Joe, if you have time, we can certainly drive down to
> Southern California and maybe we can chat for an hour or two.  I will
> contact you offline about that.
>
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com <http://www.insidethestack.com/>
>
> ------------------------------------------------------------------------
> *From:* Joe Touch <[email-masked]>
> *To:* Nalini Elkins <[email-masked]>
> *Cc:* joel jaeggli <[email-masked]>; IPv6 Ops WG <[email-masked]>
> *Sent:* Thursday, March 14, 2013 3:38 PM
> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
>
> Hi, all,
>
>  > Thanks so much for your feedback.  One of the alternatives that we
> are looking at to provide a Packet Sequence Number is a 'SHIM' such as
> that provided by SEAL.
>  >
>  > This header (if I am reading this correctly!) would be between the
> TCP or UDP header and the application payload.
>  >
>  > We do understand that there are a number of issues with IPv6
> extension headers.  We are not wedded to a particular implementation and
> whatever will provide the information we need is perfect!  But, we have
> just found out about this RFC and need to study it more to see if there
> are any drawbacks.
>  >
>  > Thanks,
>  >
>  > Nalini Elkins
>  > Inside Products, Inc.
>  > (831) 659-8360
>  > www.insidethestack.com <http://www.insidethestack.com/>
>  >
>  >
>  >
>  > From: joel jaeggli <[email-masked] <mailto:[email-masked]>>
>  > To: IPv6 Ops WG <[email-masked] <mailto:[email-masked]>>
>  > The request is not really for the ipv4 IPID/frag header in v6. it's
> for a unique per packet value over a given sample interval.
>  >
>  > The utility of ipid in ipv4 for this context has eroded over time,
> (this is not knock againt the draft I'm just trying to describe my
>  > * That it doesn't cost us anything - it strikes me as undesirable
> that packets should in general have larger headers then they do today
> that adds cost all over the place. extension header processing or indeed
>  > * That it is applied to every packet - part of the stated utility of
> the ipv4 ipid is that it's present (with my noted caveats) you don't
> have to turn it on. likewise this implies that the application of the
> value does not impact the observation, having the packet size change
> because you're doing debugging means imho that you're not doing the
>  > [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Mar 2013 21:04:52 +0000

Hi Joe,

> Sent: Monday, March 18, 2013 1:43 PM
> To: Templin, Fred L

I think host vs router wrt to reassembly may be a matter of opinion
and it sounds like our opinions differ. Be that as it may, there are
certainly implementations of virtual fragment reassembly out there
but I don't know how widely deployed they are nor whether they are
on-by-default. Do you know what is the state of affairs for widely
deployed NATs? The three options seem to be 1) real reassembly,
2) virtual reassembly, 3) no reassembly.
 
> governed by that RFC because the NAT is a source or (false) sink of the

The NAT is also forwarding packets that weren't explicitly addressed
to itself, which would say that the normative reference is RFC1812.
And, RFC1812 says that a router is not permitted to reassemble packets
not addressed to itself.
 
> fragments, you have time to reassemble - and refragment - them.

Yes, it can matter. If the final destination is monitoring its
reassembly cache to see if any packets are arriving fragmented
then it matters.

> the orignal source intended are off.

The destination may need to know that fragmentation is occurring
in the network so that it can inform the source to start sending
smaller packets. You know - as in SEAL.

Thanks - Fred

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 18 Mar 2013 21:37:41 +0000

Since beginning to explore this issue of IPID, it has become clear how valuable IPID has been to our organization and many like us.    I have personally not talked with everyone about this, but to those I have, the preponderance would not like to see this beneficial diagnostic feature lost.   

As a result, most of us do not view this as an assumption, but as a reality experienced for many years now and one we would like to continue to benefit from,   I recognize that this reality is in conflict with the original intent of this field, but at a certain point isn't proven field value of equal or greater significance that original intent?  

Having said that I know how challenging this will be, but I continue to hope we can find the optimal solution that provides and works for all.  

As far as using the packet itself, it would still need a way to uniquely identify it and make it's relative or absolute order in a sequence clear, to facilitate related diagnostics.   This could be done with add on software or techniques, which may be great for vendors or software developers, but as a lowly (and poor) end user, I would very much like to see this capability inherent in the protocol as it is today in IPV4.  

Thanks,

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Monday, March 18, 2013 4:50 PM
To: Nalini Elkins
Cc: IPv6 Ops WG
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

I'm lost on one key point - why not use the packets themselves? Why focus on a single field?

Regardless, it seems like your business model is based on assumptions that were never sound (assuming sequential IDs), have become even less sound (no ID in most IPv6 and even some IPv4), and are now approved as not sound (RFC 6864). Maybe it's time to change your assumptions ;-)

Joe

On 3/18/2013 10:31 AM, Nalini Elkins wrote:
> diagnostics,  performance and ability to manage is critical.  These 
> may be financial (as ours are) but they may also be 911 in a city 
> for such an organization and we would likely have stuck a hardware 
> probe on immediately.  This is quite often not an option in many organizations.
>
> 5.  In IPv4, one of the fields we used was the IP ID.  Even though, 
> this field was meant for fragmentation, one of the properties it had (on many
> is that middle boxes can sometimes duplicate packets ONLY FOR SOME 
> nodes or when we extract packets from one of the devices which are
> available in IPv4, we are looking for a potential solution.  We are 
> not going to deal with IPv4 - we will only move forward to IPv6. Let 
> me detail some of the known problems with solutions we have looked at:
>
> a PD-SHIM (Performance and Diagnostics SHIM) which will have a number 
> of these quite interesting fields.  This is when we started looking at 
> Fred Templin's SEAL implementation.  But, it we may need different fields.
>
> at the endpoints; IP fragmentation may mean the wrapper isn't 
> available for some datagrams.
>
> required even for datagrams that otherwise fit in an IPv6 MTU. You 
> might update your intro accordingly:
>
>      ...The IPv6 fragment
> Regarding this draft, it would be useful to explain why using the 
> entire packet (or a hash thereof) isn't nearly as useful in most cases 
> (and that would not require a new ID).
>
> uniqueness requirements in RFC791, and some use repeated IDs (even 
> that don't compress headers).
>
> Joe
>
>
>
>
> monotonically incremented for each SEAL protocol packet  >  > So, this 
> might provide exactly what we are looking for!
>  >
> extension headers.  We are not wedded to a particular implementation 
> and whatever will provide the information we need is perfect!  But, we 
> have just found out about this RFC and need to study it more to see if 
> there are any drawbacks.
>  >
>  > Thanks,
>  >
>  > Nalini Elkins
>  > Inside Products, Inc.
>  > (831) 659-8360
>  > www.insidethestack.com <http://www.insidethestack.com/>  >  >  >  > 
> ________________________________  > From: joel jaeggli 
> <[email-masked] <mailto:[email-masked]>>  > To: IPv6 Ops WG 
> <[email-masked] <mailto:[email-masked]>>  > Sent: Thursday, March 14, 
> 2013 8:13 AM  > Subject: [v6ops] 
> draft-elkins-v6ops-ipv6-ipid-needed-00
>  >
> compresssion). rfc 6864 exists because modern implmentations cannot 
> (and therefore don't) honor requirements for uniqueness in 
> rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for 
> uniqueness is bounded by the size of the flow because if it were 
> limited by the MDL it would limit that speed of a flow. a 10Gb/s flow 
> with 1500 byte packets overflows a 16 bit value every 78 or so ms. if 
> your capture is longer than that you can reasonably expect duplicate 
> IPIDS to show up which are readily identifiable as not being duplicate packets.
>  >
> that adds cost all over the place. extension header processing or 
> indeed fragmentation header use has conquences.
>  >
>  > * That it is applied to every packet - part of the stated utility 
> of the ipv4 ipid is that it's present (with my noted caveats) you 
> don't have to turn it on. likewise this implies that the application 
> of the value does not impact the observation, having the packet size 
> change because you're doing debugging means imho that you're not doing 
> the  > _______________________________________________
>  > v6ops mailing list
>  > [email-masked] <mailto:[email-masked]>  > 
>  > [email-masked] <mailto:[email-masked]>  >

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 18 Mar 2013 21:56:22 +0000

On 18/03/2013 21:37, Ackermann, Michael wrote:
> Since beginning to explore this issue of IPID, it has become clear how
> valuable IPID has been to our organization and many like us.    I have
> personally not talked with everyone about this, but to those I have, the
> preponderance would not like to see this beneficial diagnostic feature
> lost.

Mike, Nalini,

I understand that using IPID works for you when diagnosing connectivity
problems in ipv4.  Do you understand that ipv6 extension headers cause
massive operational headaches which we cannot get around using today's
technology?  And that as a working group, the operational people here are
baulking at the idea of creating more extension headers because it makes
our lives massively more difficult?

If everyone doesn't understand each others' points of view, this
conversation is going to continue running around in circles, causing
nothing but frustration.

Nick

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 18 Mar 2013 15:39:36 -0700 (PDT)

Nick,

Totally agree with you about trying to understand each other's point of view.   We absolutely want to do that.   I think Mike was responding to the comment on the need for IPID itself.

As far as a solution, we are thinking that IPv6 extension headers are a non-starter.  For all the reasons that have been brought up.

So, we are thinking of a header higher up the layers.   For example, between the Transport Layer (TCP / UDP) and the application payload.

What are opinions from people on that?

Thanks,

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

________________________________
 From: Nick Hilliard <[email-masked]>
To: [email-masked] 
Sent: Monday, March 18, 2013 2:56 PM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Mike, Nalini,

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Mar 2013 22:53:05 +0000

Hi Nalini,

For a shim header between the transport and the application data, TCP provides
TCP options so you could consider a new TCP option. But, TCP already includes
sequence numbers that can be used for diagnostic purposes - in fact, Wireshark
(and I'm sure other network diagnostic tools) already use that. So, I don't see
a shim as a big win for TCP.

For UDP, there would need to be a new UDP port number assignment, and a
new piece of code at both the source and destination. The source would have
to insert the shim about the UDP header, and the destination would have to
remove it. That is the same model that SEAL is addressing, but SEAL is expecting
both ends to implement the protocol. So, unfortunately, there is no way to
have a source-only patch that does not also require a patch at the destination.

Thanks - Fred

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: Monday, March 18, 2013 3:40 PM
To: Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Nick,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com<http://www.insidethestack.com>
________________________________
From: Nick Hilliard <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Sent: Monday, March 18, 2013 2:56 PM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Mike, Nalini,

Nick

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 18 Mar 2013 22:54:18 +0000

Well stated Nick!

The various viewpoints here are incredibly diverse.   

I do get that we are arriving at what for IETF is the 11th hour and asking for what would likely mean significant change.   On the other hand this is zero hour to a lot of us.

I also agree that we don't want any more bits floating around (extension headers), than absolutely necessary.   So the trade off is a most challenging one.  

It's tough and confusing, and at times I feel like it may never come together in an optimal, effective way.    Not too certain about many of the associated solutions, but I do know how important this feels and I do want to be part of a best possible effort.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Monday, March 18, 2013 5:56 PM
To: [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

On 18/03/2013 21:37, Ackermann, Michael wrote:
> personally not talked with everyone about this, but to those I have, 
> the preponderance would not like to see this beneficial diagnostic 
> feature lost.

Mike, Nalini,

I understand that using IPID works for you when diagnosing connectivity problems in ipv4.  Do you understand that ipv6 extension headers cause massive operational headaches which we cannot get around using today's technology?  And that as a working group, the operational people here are baulking at the idea of creating more extension headers because it makes our lives massively more difficult?

If everyone doesn't understand each others' points of view, this conversation is going to continue running around in circles, causing nothing but frustration.

Nick

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2013 16:18:11 -0700

The IPv4 ID requirements were recently updated to reflect widespread 
operational reality. That cat has been out of the bag for a long time.

The ID never existed to support your business model, and the spec 
shouldn't be reverted for that reason. There are plenty of alternative 
ways to trace packets and packet sequences.

Joe

On 3/18/2013 2:37 PM, Ackermann, Michael wrote:
> Since beginning to explore this issue of IPID, it has become clear
> how valuable IPID has been to our organization and many like us. I
> have personally not talked with everyone about this, but to those I
> have, the preponderance would not like to see this beneficial
> diagnostic feature lost.
>
> As a result, most of us do not view this as an assumption, but as a
> reality experienced for many years now and one we would like to
> continue to benefit from, I recognize that this reality is in
> conflict with the original intent of this field, but at a certain
> point isn't proven field value of equal or greater significance that
> original intent?
>
> Having said that I know how challenging this will be, but I continue
> to hope we can find the optimal solution that provides and works for
> all.
>
> As far as using the packet itself, it would still need a way to
> uniquely identify it and make it's relative or absolute order in a
> sequence clear, to facilitate related diagnostics. This could be
> done with add on software or techniques, which may be great for
> vendors or software developers, but as a lowly (and poor) end user, I
> would very much like to see this capability inherent in the protocol
> as it is today in IPV4.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Mar 2013 10:39:42 +1100

> Fragment boundaries are semantically meaningful - and should only be 

Not true.  In both IPv4 and IPv6 you can avoid PMTU issues by setting
appropriate fragment sizes.  For IPv6 we have a socket option for
this IPV6_USE_MIN_MTU.  Nameservers use this socket option on both
UDP and TCP connections.  When you only have 2-3 seconds to do a
name resolution involving multiple lookups you don't have time for
PMTUD to work (TCP) or there is no recovery from PTB (UDP).

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2013 16:44:51 -0700

...
> appropriate fragment sizes.

You can try...

> For IPv6 we have a socket option for

This all presumes

a) the NAT relays PTB

b) the NAT doesn't rewrite the packets

Neither is universally true. PMTUD is a path issue, and if the NAT 
presents an endpoint that is capable of dealing with a larger packet 
size, then it's up to the NAT to fragment later anyway. Again, it's the 
host and/or spoofs a host, so either way it needs to be participating as 
an endpoint in these protocols.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Mar 2013 10:58:26 +1100

> an endpoint in these protocols.

You claimed that only the IP layer cares about fragmentation.
Your claim is wrong.

As for NAT relaying PTB the point of using IPV6_USE_MIN_MTU is to
never have a PTB be generated in the first place.

A NAT needs to be aware that to one side it is a router and to the
other side it is a host.  It needs to behave like both.  It can
fragment a fragmement but needs to preserve incoming fragmentation
points even if it has to reassemble a packet for something else.  

Mark

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2013 17:04:24 -0700

> You claimed that only the IP layer cares about fragmentation.

Yes, I'll concede that transport cares about this too. Apps shouldn't.

> never have a PTB be generated in the first place.

Sure.

> points even if it has to reassemble a packet for something else.

I disagree that it needs to preserve the fragmentation; it needs to 
preserve the fragment signalling and behavior together. Sometimes that 
means preserving fragmentation, but other times not.

Joe

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 00:46:43 +0000

Good comments Joe!   I suppose this exchange serves to again illustrate the different perspectives that some of us have, or a different view of what is important.  As you say different operational realities.  

Our operational reality is keeping outages to an absolute minimum.    So while I agree with you that there are other methods of tracing packets and solving problems, if one has proven to be better and faster, I certainly would like to preserve it if at all possible.   

I do understand how unpopular such new ideas must be for those of you who have been running IPV6 for some time now.  So I greatly appreciate the openness, consideration and help, for the perspective of those of us just starting on the IPV6 journey.  

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Monday, March 18, 2013 7:18 PM
To: Ackermann, Michael
Cc: Nalini Elkins; IPv6 Ops WG
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

The IPv4 ID requirements were recently updated to reflect widespread operational reality. That cat has been out of the bag for a long time.

The ID never existed to support your business model, and the spec shouldn't be reverted for that reason. There are plenty of alternative ways to trace packets and packet sequences.

Joe

On 3/18/2013 2:37 PM, Ackermann, Michael wrote:
> continue to benefit from, I recognize that this reality is in conflict 
> with the original intent of this field, but at a certain point isn't 
> proven field value of equal or greater significance that original 
> intent?
>
> sequence clear, to facilitate related diagnostics. This could be done 
> with add on software or techniques, which may be great for vendors or 
> software developers, but as a lowly (and poor) end user, I would very 
> much like to see this capability inherent in the protocol as it is 
> today in IPV4.

>> way to diagnose such problems.  Packet traces may be available 
>> because all packets are sometimes stored for regulatory reasons (ex.  all stock
>> Now, because IP ID is not in the main IP header in IPv6 and may not 
>> be available in IPv4, we are looking for a potential solution.  We 
>> are not going to deal with IPv4 - we will only move forward to IPv6. 
>> Let me detail some of the known problems with solutions we have looked at:
>>
>> but possibly even more as this may be even more unrecognized by 
>> middle boxes.  Also, I have been told that adding IPv6 extension 
>> headers will make the routing of the packets through routers and 
>> middle boxes route at a software rather than hardware layer, thus slowing the performance.
>>    Guys, am I right?
>>
>> SHIM possibility.  That is, introduce a header that is between TCP 
>> and UDP and the application. The idea of a SHIM was brought to us by Ron
>> of these quite interesting fields.  This is when we started looking 
>> at Fred Templin's SEAL implementation.  But, it we may need different fields.
>>
>> ---------------------------------------------------------------------
>> -
>> --
>> Wrapping UDP messages is fine - presuming you look at the wrapper 
>> only at the endpoints; IP fragmentation may mean the wrapper isn't 
>> invisible to the application layer. The boundaries of what is 
>> written, transmitted, received, and, read may differ (the middle two 
>> due to rewriting proxies, which are evil but real).
>>
>> If you want/need a network identifier for diagnostics, it has to 
>> exist at the network layer.
>>
>> entire packet (or a hash thereof) isn't nearly as useful in most 
>> cases (and that would not require a new ID).
>>
>>   > Thanks so much for your feedback.  One of the alternatives that 
>> we are looking at to provide a Packet Sequence Number is a 'SHIM' 
>> such as that provided by SEAL.
>>   >
>>   > This header (if I am reading this correctly!) would be between 
>> the TCP or UDP header and the application payload.
>>   >
>> monotonically incremented for each SEAL protocol packet  >  > So, 
>> this might provide exactly what we are looking for!
>>   >
>> and whatever will provide the information we need is perfect!  But, 
>> we have just found out about this RFC and need to study it more to 
>> see if there are any drawbacks.
>>   >
>>   > Thanks,
>>   >
>>   > Nalini Elkins
>>   > Inside Products, Inc.
>>   > (831) 659-8360
>>   > www.insidethestack.com <http://www.insidethestack.com/>  >  >  >  
>>   > The request is not really for the ipv4 IPID/frag header in v6. 
>> it's for a unique per packet value over a given sample interval.
>>   >
>>   > The utility of ipid in ipv4 for this context has eroded over 
>> time, (this is not knock againt the draft I'm just trying to describe 
>> my understanding of the utility). IPID's in the context of mobile 
>> change because you're doing debugging means imho that you're not 
>> doing the  > _______________________________________________
>>   > v6ops mailing list

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 18 Mar 2013 17:49:16 -0700 (PDT)

Fred,

TCP sequence number is not enough because there can be duplicate segments and retransmissions.   We need a way to see if these are really sent by the device or if they are just a problem in packet tracing.

Also, in the case of resets, the SEQ and ACK may also be duplicated.  Let me give you real example:

pkt 1: seq no: 123    ack: 345     ttl: 60     IPID: 123        src addr: 1.2.3.4    dest addr : 4.5.6.7  
pkt 2: seq no: 123    ack: 345     ttl: 254   IPID:  FF2A     src addr: 1.2.3.4   dest addr:  4.5.6.7   TCP RESET flag set

The time between these two packets is quite small.  They have also been having problems with connections failing.

My conclusion would be that the second packet was NOT sent by the same device that sent the first.  Why?  Because BOTH IPID and TTL are quite different.  Very unlikely that the originating device is going to change BOTH that quickly.  I would conclude that there is a box in the middle sending a RESET for that session.  And, actually, when we replaced the device that we felt was the problem, sessions stayed up!

This is just one case.  In our draft, we had quite a few others, as you remember from the presentation.

Definitely, we need a sequence number field that is more than 16 bits.  Wrapping is a problem.

But, the point is well taken that the down side of a SHIM is that both sides have to implement.  Noted.

Thanks,

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

________________________________
 From: "Templin, Fred L" <[email-masked]>
To: Nalini Elkins <[email-masked]>; Nick Hilliard <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, March 18, 2013 3:53 PM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi Nalini,
 
For a shim header between the transport and the application data, TCP provides
TCP options so you could consider a new TCP option. But, TCP already includes
sequence numbers that can be used for diagnostic purposes – in fact, Wireshark
(and I’m sure other network diagnostic tools) already use that. So, I don’t see
a shim as a big win for TCP.

Thanks - Fred

Nick,

 

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

From:Nick Hilliard <[email-masked]>
To: [email-masked] 
Sent: Monday, March 18, 2013 2:56 PM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Mike, Nalini,

Nick

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Mar 2013 11:50:07 +1100

> Yes, I'll concede that transport cares about this too. Apps shouldn't.

Apart from TCP which handles retransmission, apps need to care about
about fragmentation when it is not being done by itermediate nodes
in the network.  For IPv6 this is any app that is using a protocol
other then TCP.

> means preserving fragmentation, but other times not.

And how can a NAT know if it can *safely* reassemble and do its own
fragmentation?  It can't.  Since it can't it needs to preserve
fragmentation.

Mark

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 18 Mar 2013 17:54:35 -0700 (PDT)

Operational realities depend on where you are sitting.  We had 6 usage cases from 5 different organizations where we used IPID to save us time in problem diagnostics.   This is starting to seem like the blind men describing the elephant.

I am afraid I don't understand the "The ID never existed to support your business model" statement.   What business model?  I thought we were talking about diagnostics.

Thanks,

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

________________________________
From: Joe Touch <[email-masked]>
To: "Ackermann, Michael" <[email-masked]> 
Cc: Nalini Elkins <[email-masked]>; IPv6 Ops WG <[email-masked]> 
Sent: Monday, March 18, 2013 4:18 PM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Joe

>>   > Joel,
>>   >
>>   > Thanks so much for your feedback.  One of the alternatives that we
>>   >
>>   > http://tools.ietf.org/html//rfc5320
>>   >
>>   > This header (if I am reading this correctly!) would be between the
>>   >
>>   > One of the things that SEAL provides is:
>>   >
>>   > SEAL_ID - a 32-bit Identification value, randomly initialized and
>>   >
>>   > We do understand that there are a number of issues with IPv6
>>   >
>>   > Thanks,
>>   >
>>   > Nalini Elkins
>>   > Inside Products, Inc.
>>   > (831) 659-8360
>>   > www.insidethestack.com <http://www.insidethestack.com/>  >  >  >  >
>>   >
>>   > some more thoughts since the presentation.
>>   >
>>   > Noted that I consulted the earlier draft, discussion in 6-man and
>>   >
>>   >
>>   >
>>   > was the previous one.
>>   >
>>   > The request is not really for the ipv4 IPID/frag header in v6. it's
>>   >
>>   > The utility of ipid in ipv4 for this context has eroded over time,
>>   >
>>   > desirable properties of a unique per packet value to my mind...
>>   >
>>   > * That it doesn't cost us anything - it strikes me as undesirable
>>   >
>>   > see http://tools.ietf.org/html/draft-wkumari-long-headers-00
>>   >
>>   > for dicussion that has come up about header processing in modern routers.
>>   >
>>   > and
>>   >
>>   > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00
>>   >
>>   > for a similar discussion about fragmentation headers.
>>   >
>>   > neither of these represent any form of consensus document, so take
>> that with a grain of salt.
>>   >
>>   > * That it is applied to every packet - part of the stated utility
>>   > v6ops mailing list
>>   > [email-masked] <mailto:[email-masked]>  >
>>   > _______________________________________________
>>   > v6ops mailing list
>>   > [email-masked] <mailto:[email-masked]>  >
>>   >

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 07:40:54 -0700

On 3/18/2013 5:50 PM, Mark Andrews wrote:
...
> fragmentation?  It can't.  Since it can't it needs to preserve

A NAT creates packets with its own IP address.
A NAT creates packets spoofed from external addresses.

A NAT sinks (consumes) packets to its IP address.
A NAT sinks packets by spoofing external addresses.

Once a fragment goes through a NAT, the information needed to reassemble 
has been destroyed (in either direction). The NAT is the only device 
that can address that issue, and only by reassembling (or virtually 
reassemblying) the packet.

Fred spoke of the utility of keeping the original fragment boundaries; 
we can debate whether this is meaningful when PTBs aren't relayed across 
a NAT. However, virtual reassembly is just reassembly and 
refragmentation that retains those boundaries - if all the fragments 
aren't seen, the packet is dropped just as if real reassembly were used.

So the difference is only in the boundaries. Either way, a NAT that 
doesn't reassemble (one way or the other) creates fragments that are 
useless anyway.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Mar 2013 14:56:14 +0000

Hi Nalini

I’ll agree that you can construct an example showing a pair of packets with the
same (src, dst, seq, ack)-tuple yet the packets are not duplicates. But, diagnostics
can’t be limited to an isolated pair of packets and need to observe a trend over
many packets. Again, diagnostic tools like Wireshark seem to be already producing
effective diagnostics based just on the information at hand – I recently used the
tool to identify a case of in-the-network packet duplication within our network.
Does anyone know what the Wireshark team thinks about this?

Thanks - Fred

From: Nalini Elkins [mailto:[email-masked]]
Sent: Monday, March 18, 2013 5:49 PM
To: Templin, Fred L; Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Fred,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>; Nick Hilliard <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Nalini,

Thanks - Fred

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: Monday, March 18, 2013 3:40 PM
To: Nick Hilliard; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Nick,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Mike, Nalini,

Nick

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 08:13:56 -0700 (PDT)

Fred,

I use Wireshark incessantly.   Believe me, IP ID is very needed in Wireshark.

As a matter of fact, we know the folks at Wireshark very well.  We help sponsor their SharkFest event.  I spoke there last year & will be again this year.  I am trying to twist people's arms at Wireshark to come to IETF and speak for themselves.  Well, maybe Berlin.

BTW, quite a while back, we asked Gerald Combs, the original developer of Wireshark, to comment on our RFC and work with us.  He supports our efforts.  I am copying his response to me here.  Janice is our contact at Riverbed who "own" Wireshark.   He is speaking of the IP ID field in the note below.

Hi Janice and Nalini,

I think this is a great idea! An explicit (and separate) diagnostic field for IPv6 would definitely be helpful for Wireshark, Pilot (particularly for its MSA feature) and many other tools. 

Two quick notes: 

You might want to add a SHOULD NOT or MUST NOT explicitly stating that gateways must not modify or remove the IPID from packets that they forward. 

Many OSes support random IP IDs (e.g. my laptop has a "net.inet.ip.random_id" sysctl which is currently enabled), primarily to improve security. Is that needed here? 

Thanks,

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

Sent: Tuesday, March 19, 2013 7:56 AM

Hi Nalini

Thanks - Fred
 
From:Nalini Elkins [mailto:[email-masked]] 
Sent: Monday, March 18, 2013 5:49 PM
To: Templin, Fred L; Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Fred,

 

 

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

 
Hi Nalini,

 
Thanks - Fred

Nick,

 

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

Mike, Nalini,

Nick

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 15:18:05 +0000

Thanks Fred.

I am sure you will hear from Nalini shortly, as she spoke to several of the Wireshark (now Riverbed) folks live on this and works with them a lot.  .   My short comment is that the inventor of Wireshark was featured in our presentation last week.   His comments (please see the slide for details),  were very supportive of IPID being retained in V6.

One other question is that during your recent diagnostic efforts you mentioned,  how did you determine if the duplicated packets were “TRUE” duplicates or false duplicates inserted extraneously by network boxes?   We find it next to impossible to make this determination without IPID.

Thanks again.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Tuesday, March 19, 2013 10:56 AM
To: Nalini Elkins; Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi Nalini

Thanks - Fred

From: Nalini Elkins [mailto:[email-masked]]
Sent: Monday, March 18, 2013 5:49 PM
To: Templin, Fred L; Nick Hilliard; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Fred,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Hi Nalini,

Thanks - Fred

Nick,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Mike, Nalini,

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Mar 2013 15:30:54 +0000

Hi Nalini,

> I use Wireshark incessantly.   Believe me, IP ID is very needed in Wireshark.

In the case I examined, a sequence of TCP segments that were conveyed in 8-10
packets was being repeated. The sequence and ack numbers in each segment were
repeated exactly. I can’t be sure, but I don’t think Wireshark even looked at the IPID
because the extra packets were flagged as “out of order” instead of duplicates. But,
examining the trend rather than an isolated packet pair left little doubt that they
were duplicates.

Thanks - Fred

From: Nalini Elkins [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 8:14 AM
To: Templin, Fred L; Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Fred,

Hi Janice and Nalini,

Two quick notes:

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Hi Nalini

Thanks - Fred

Fred,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Hi Nalini,

Thanks - Fred

Nick,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Mike, Nalini,

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Mar 2013 15:34:19 +0000

Hi Mike,

I would consider the packets as duplicates whether they came from the source or
from some network middlebox. However, I am convinced they came from the
network because I took two packet traces – one near the source and the second
near the destination. The packet trace taken near the source did not show any
duplication whereas the trace near the destination showed duplicates.

Thanks - Fred

From: Ackermann, Michael [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 8:18 AM
To: Templin, Fred L; Nalini Elkins; Nick Hilliard; [email-masked]
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Thanks Fred.

Thanks again.

Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Tuesday, March 19, 2013 10:56 AM
To: Nalini Elkins; Nick Hilliard; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi Nalini

Thanks - Fred

Fred,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Hi Nalini,

Thanks - Fred

Nick,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Mike, Nalini,

Nick

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 08:36:53 -0700

Hi, all,

Regarding my comment about the "business model", I appreciate that 
packet diagnostics are very important, but not at the expense of the 
operation of the Internet. I.e., it's not appropriate to complicate 
everyone's stack to reduce the effort of packet diagnostics designers.

IPIDs are already repeated on very short timescales, and some devices 
haven't generated unique IDs for many years.

Alternatives have been available, but require more work; they include:

	- injecting your own trace traffic (where the data is
	generated as unique over the timescales sought)

	- tracing the entire packet
	which might show some duplicates, but only rarely
	and typically as a transient

The other alternative - to require every source to support diagnostics, 
effectively - is neither efficient nor appropriate.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 08:39:01 -0700

PS - also keep in mind that before 6864, TCP was permitted to retransmit 
a segment using the same ID (see sec 4.2). So the complaint that "the ID 
is needed to differentiate TCP retransmissions" is erroneous anyway.

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 08:50:29 -0700 (PDT)

Joe,

To respond:

"Regarding my comment about the "business model", I appreciate that packet diagnostics are very important, but not at the expense of the operation of the Internet. I.e., it's not appropriate to complicate everyone's stack to reduce the effort of packet diagnostics designers."

Our effort is to reduce the time for diagnostics for network operators or companies who actually run networks.  NOT packet diagnostics designers.  Such packet diagnostics designers have in their own interest to make diagnostics harder for everyone so that people will be forced to buy their products.  NOT the other way around.

"injecting your own trace traffic (where the data is generated as unique over the timescales sought)"

1.  You are now just changing the environment that you are trying to diagnose.
2.  In the production networks that I have worked on, this is impossible to do.  For example,  do you think that the NY Stock Exchange network in daytime trading hours would ACTUALLY allow this to happen?   You must be joking.  You can't touch their networks in production.  We work with companies whose job it is to settle the stock markets and use IPID to HELP them with problems.

"tracing the entire packet which might show some duplicates, but only rarely and typically as a transient"

1. Completely not true, in my experience.

Thanks,

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

________________________________
 From: Joe Touch <[email-masked]>
To: "Ackermann, Michael" <[email-masked]> 
Cc: "Templin, Fred L" <[email-masked]>; Nalini Elkins <[email-masked]>; Nick Hilliard <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, March 19, 2013 8:36 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Hi, all,

Regarding my comment about the "business model", I appreciate that packet diagnostics are very important, but not at the expense of the operation of the Internet. I.e., it's not appropriate to complicate everyone's stack to reduce the effort of packet diagnostics designers.

IPIDs are already repeated on very short timescales, and some devices haven't generated unique IDs for many years.

The other alternative - to require every source to support diagnostics, effectively - is neither efficient nor appropriate.

Joe

---

From: Bill Jouris <[email-masked]>
Date: Tue, 19 Mar 2013 08:50:50 -0700 (PDT)

Hi Joe, 

It's not just "packet diagnostics designers" that care.  It's also the folks who are merely trying to diagnose problems by reading traces manually.  In fact, they probably care more.

Certainly nobody wants to damage the operation of the Internet.  On the other hand, people whose businesses depend on keeping their networks up and running well care very, very much about being able to diagnose problems as quickly as possible.  I'm not sure I would agree that some attention to their concerns is not appropriate.

It may well be that IPID is not the best way to make more rapid diagnosis possible.  But it does seem to be the best way *currently available* -- or, at least, the best way that most of those responsible for network support are aware of.

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Tue, 3/19/13, Joe Touch <[email-masked]> wrote:

From: Joe Touch <[email-masked]>
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
To: "Ackermann, Michael" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tuesday, March 19, 2013, 8:36 AM

Hi, all,

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 08:55:09 -0700

On 3/19/2013 8:50 AM, Bill Jouris wrote:
> Hi Joe,
>
> It's not just "packet diagnostics designers" that care.  It's also the
> folks who are merely trying to diagnose problems by reading traces
> manually.  In fact, they probably care more.
>
> Certainly nobody wants to damage the operation of the Internet.  On the
> other hand, people whose businesses depend on keeping their networks up
> and running well care very, very much about being able to diagnose
> problems as quickly as possible.  I'm not sure I would agree that some
> attention to their concerns is not appropriate.
>
> It may well be that IPID is not the best way to make more rapid
> diagnosis possible.  But it does seem to be the best way *currently
> available* -- or, at least, the best way that most of those responsible
> for network support are aware of.

Why not trace the packets by contents, i.e., the entire packet?

Joe

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 15:57:24 +0000

Thanks Fred

Great example in my view.     Great because it shows the more of the network landscape you “OWN”,  the less you probably need IPID in most situations .     If you only owned the destination in this case, then IPID would have been valuable to you.      In this case you could determine the culprit was in the middle by comparing the source and destination traces.   I would also say that iPID would frequently make that comparison easier, but not necessary in this case.

Thanks again

Mike

From: Templin, Fred L [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 11:34 AM
To: Ackermann, Michael; Nalini Elkins; Nick Hilliard; [email-masked]
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi Mike,

Thanks - Fred

From: Ackermann, Michael [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 8:18 AM
To: Templin, Fred L; Nalini Elkins; Nick Hilliard; [email-masked]<mailto:[email-masked]>
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Thanks Fred.

Thanks again.

Mike

Hi Nalini

Thanks - Fred

Fred,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Hi Nalini,

Thanks - Fred

Nick,

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360

Mike, Nalini,

Nick

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 Mar 2013 16:59:55 +0100

Hi,

> It's not just "packet diagnostics designers" that care.  It's also the folks who are merely trying to diagnose problems by reading traces manually.  In fact, they probably care more.

JFTR, I recularily diagnose problems by reading tcpdump output, and have
never used IP-ID, and have never missed it either.

Given what we have today, and that we need to roll out IPv6 "now!", not
"when all stacks have been upgraded to handle some sort of IPID change",
I see this as a fairly futile excercise.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 08:59:43 -0700

On 3/19/2013 8:50 AM, Nalini Elkins wrote:
> Joe,
>
> To respond:
>
> "Regarding my comment about the "business model", I appreciate that
> everyone's stack to reduce the effort of packet diagnostics designers."
>
> Our effort is to reduce the time for diagnostics for network operators
> or companies who actually run networks.  NOT packet diagnostics
> designers.  Such packet diagnostics designers have in their own interest
> to make diagnostics harder for everyone so that people will be forced to
> buy their products.  NOT the other way around.
>

What do you call inserting a shim?

> 2.  In the production networks that I have worked on, this is impossible
> to do.  For example,  do you think that the NY Stock Exchange network in
> daytime trading hours would ACTUALLY allow this to happen?   You must be
> joking.  You can't touch their networks in production.  We work with
> companies whose job it is to settle the stock markets and use IPID to
> HELP them with problems.
>

Sorry for the mis-implication; I meant "false duplicates". If there is 
true entire duplication, and it happens during what appear to be TCP 
retransmissions, don't you already then know what's going on? Or UDP?

IPv6 has the same problem that IPv4 now has - the ID exists only when 
there are fragments. If the endpoint tries to avoid fragments, there is 
NO way to insert a diagnostic tag short of modifying the end systems or 
injecting traffic.

Again, unless you want to entire Internet to turn on such tags to make 
your life easier. Not an option, AFAICT.

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 09:02:27 -0700 (PDT)

Fred,

Definitely, we can use TCP seq and ack to find out-of-sequence packets on some occasions but as we said in our draft there are quite a few other instances where this is not true.  And, it is definitely not true for UDP.

More and more uses are being made of UDP to embed other protocols.  Tunneling is often used for UDP.   Also one protocol we work with quite a bit is HPR over UDP.

I think maybe we will now start to work on our draft of the solution we envisage and then maybe we can have a new discussion.  We definitely will take all the suggestions into account.

Thank you all so much for spending time thinking about this issue.

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

Sent: Tuesday, March 19, 2013 8:30 AM

Hi Nalini,

 
Thanks - Fred

Fred,

 
 
Hi Janice and Nalini,

Two quick notes: 

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

 
Hi Nalini

Thanks - Fred

Fred,

 

 

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

 
Hi Nalini,

 
Thanks - Fred

Nick,

 

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

Mike, Nalini,

Nick

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 09:09:25 -0700 (PDT)

Gert,

Actually, in my experience, many companies are resisting the move to IPv6 because they see no business reason.   If we can have improved performance and diagnostics for IPv6 by the method that we envision, this may actually SPEED the move to IPv6.  At least in corporate America, which has been our world for many years.
 
Thanks,

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

________________________________
 From: Gert Doering <[email-masked]>
To: Bill Jouris <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, March 19, 2013 8:59 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Hi,

Gert Doering
        -- NetMaster

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 16:09:28 +0000

Joe,

I am certainly sensitive to not wanting to put extra bits on the Internet (or my own network for that matter).   I think this is something we all seek to optimize however/whenever we can.   However, I know these particular bits have saved many, many hours of downtime for us and that is worth many millions of dollars as we sought to demonstrate at the meeting last week.     So while I believe optimizing the number of bits sent is very important, it is not always the only consideration.   As a techie,  I may even lean in that direction.  However, working for a enterprise and knowing where my paycheck comes from, I begrudgingly have to believe that the bits are worth  the hours and the $ Million$  we have seen saved.    As frequently is the case in my world,  business value wins out over technical optimization.    

Regards to the injecting of trace traffic.   I could maybe do this in a test environment, but NEVER in production!  

I am afraid I do not know what you mean be "tracing the entire packet"?  

THanks

Mike

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, March 19, 2013 11:37 AM
To: Ackermann, Michael
Cc: Templin, Fred L; Nalini Elkins; Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi, all,

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 09:10:12 -0700 (PDT)

We propose having a SHIM present at all times.
 
Thanks,

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

Cc: "Ackermann, Michael" <[email-masked]>; "Templin, Fred L" <[email-masked]>; Nick Hilliard <[email-masked]>; "[email-masked]" <[email-masked]> 

Joe

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 Mar 2013 17:14:36 +0100

Hi,

> Actually, in my experience, many companies are resisting the move to IPv6 because they see no business reason.   If we can have improved performance and diagnostics for IPv6 by the method that we e…

If it's "bring back an ipid similar to what IPv4 has" it's not "better than
IPv4".  Not compelling enough, if all the other arguments for IPv6 are
not heeded.

But companies are moot anyway, they do what they want, and in which time
frame they want that - the Internet at large is already moving to IPv6,
and it's too late for fundamental changes to the packet format or the
stacks.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 Mar 2013 17:16:27 +0100

Hi,

> We propose having a SHIM present at all times.

Please describe how this can be done without breaking compatibility to
existing and deployed IPv6 end hosts, load balancers, firewalls, and such.

Gert Doering
        -- NetMaster

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 09:19:45 -0700

On 3/19/2013 9:09 AM, Ackermann, Michael wrote:
> Joe,
>
> I am certainly sensitive to not wanting to put extra bits on the
> Internet (or my own network for that matter). I think this is something
> we all seek to optimize however/whenever we can. However, I know these
> particular bits have saved many, many hours of downtime for us and that
> is worth many millions of dollars as we sought to demonstrate at the
> meeting last week. So while I believe optimizing the number of bits sent
> is very important, it is not always the only consideration. As a techie,
> I may even lean in that direction. However, working for a enterprise and
> knowing where my paycheck comes from, I begrudgingly have to believe
> that the bits are worth the hours and the $ Million$ we have seen saved.
> As frequently is the case in my world, business value wins out over
> technical optimization.

Well, this is why I said that the Internet isn't here to support your 
business model. Many others will gladly shave a few bits off every 
packet because they pay for capacity and complexity. Asking everyone to 
enable features used for diagnostics would be like asking everyone to 
walk around with a thermometer in their mouth, just in case a medical 
doctor needs to know.

> I am afraid I do not know what you mean be "tracing the entire packet"?

You're looking for an ID. Consider the whole packet an ID, and look for 
duplicates.

If you see duplicates on one side of a device and not the other, that 
device is duplicating them.

This is more complicated, but there are known ways to do this at very 
high speed with reasonable amounts of storage.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 09:21:40 -0700

That's a non-starter, as is assuming that there is an ID in either IPv4 
or IPv4.

Joe

On 3/19/2013 9:10 AM, Nalini Elkins wrote:
> *Cc:* "Ackermann, Michael" <[email-masked]>; "Templin, Fred L"
> <[email-masked]>; Nick Hilliard <[email-masked]>;
> "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, March 19, 2013 8:59 AM

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 Mar 2013 16:25:33 +0000

On 19/03/2013 15:18, Ackermann, Michael wrote:
> His comments (please see the slide for details),  were very supportive of
> IPID being retained in V6.  

"retained" is an argument which should have happened in 1996.  We're now at
the "retrofit a protocol change to hundreds of millions of machines" stage.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Mar 2013 16:27:23 +0000

As a TCP option, the shim could be inserted by the source and
ignored by the destination. For UDP, there is a way to include
a shim as long as both the source and destination are aware that
the shim is present. On the wire, it would look like:

  +------------------+
  |    IP header     |
  +------------------+
  |  UDP shim header |
  |    port="shim"   |
  |Next header="real"|
  +------------------+
  | Shim header with |
  |  identification  |
  +------------------+
  |  UDP real header |
  |     port="real"  |
  +------------------+
  |                  |
  ~ Application Data ~
  |                  |
  +------------------+

Not pretty, but it gets the job done. And network middleboxes that
expect to see either UDP or TCP should be happy. But, is it worth
the 12 or more bytes of extra encapsulation?

Fred

> Sent: Tuesday, March 19, 2013 9:16 AM
> To: Nalini Elkins
> Cc: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Mar 2013 16:31:30 +0000

Nick is right. People cringe when I say this, but IPv6 is in fact
a very old protocol - almost an antique. Maybe someday there will
be another IPng iteration where this could be revisited.

Thanks - Fred

> Nick Hilliard
> Sent: Tuesday, March 19, 2013 9:26 AM
> To: Ackermann, Michael
> Cc: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 Mar 2013 17:33:33 +0100

Hi,

> the shim is present. On the wire, it would look like:

That's the point: changing all endpoints.  And your UDP communication
will mysteriously fail if you happen to send a shim'ed packet to a
remote host that doesn't implement it, so you need extra logic to 
notice the "ICMP port unreachable" coming back for the shim-pseudo-port
and then fall back to "no shim", which will only work if that ICMP
actually comes, etc.

And firewalls will see the wrong UDP port, so throw away your packet.

"No go"

Gert Doering
        -- NetMaster

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 16:36:22 +0000

Joe,

As I think others have said, I do not see this as a business model.   But only as simple math.   

If I can add some number of bits to every (or many) packets,  there is a technical cost there, that I fully understand.     However, if these bits save me even 10 hours per year (and it is much more in my cases), this translates into hundreds of millions of dollars or more to my company and others.   No matter what your cost per bit is, it will never come close to that.   Not to mention the direct or indirect costs to the application or business.    So no matter what I might think as a pure technician or architect, guess what my boss or my CEO will say.   Simple math is the only math that executives understand and frequently they do not understand math at all that is not prefixed with a $.   

Regards to the whole packet technique.   My personal view is that if I have to program or buy a product, to do what the protocol inherently does today, that is a big step back and a deterrent to IPV6 deployment.    I am one of the very few pro IPV6 people in my organization and those I work with.   This would be something those fighting IPV6 would use against me.    I am out numbered enough as it is.   :)

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, March 19, 2013 12:20 PM
To: Ackermann, Michael
Cc: Templin, Fred L; Nalini Elkins; Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

On 3/19/2013 9:09 AM, Ackermann, Michael wrote:
> Internet (or my own network for that matter). I think this is 
> something we all seek to optimize however/whenever we can. However, I 
> know these particular bits have saved many, many hours of downtime for 
> us and that is worth many millions of dollars as we sought to 
> demonstrate at the meeting last week. So while I believe optimizing 
> the number of bits sent is very important, it is not always the only 
> consideration. As a techie, I may even lean in that direction. 
> However, working for a enterprise and knowing where my paycheck comes 
> from, I begrudgingly have to believe that the bits are worth the hours and the $ Million$ we have seen saved.

Well, this is why I said that the Internet isn't here to support your business model. Many others will gladly shave a few bits off every packet because they pay for capacity and complexity. Asking everyone to enable features used for diagnostics would be like asking everyone to walk around with a thermometer in their mouth, just in case a medical doctor needs to know.

> I am afraid I do not know what you mean be "tracing the entire packet"?

You're looking for an ID. Consider the whole packet an ID, and look for duplicates.

If you see duplicates on one side of a device and not the other, that device is duplicating them.

This is more complicated, but there are known ways to do this at very high speed with reasonable amounts of storage.

Joe

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Mar 2013 09:40:54 -0700

On 3/19/13 9:02 AM, Nalini Elkins wrote:
> Fred,
>
> Definitely, we can use TCP seq and ack to find out-of-sequence packets 
> on some occasions but as we said in our draft there are quite a few 
> other instances where this is not true. And, it is definitely not true 
> for UDP.
>
> More and more uses are being made of UDP to embed other protocols. 
> Tunneling is often used for UDP. Also one protocol we work with quite 
> a bit is HPR over UDP.
>
A UDP encapsulation of SNA is sensitive to duplicates?

I think that's a little more subtle than find the source of duplicates 
with different flags in a TCP stream, TCP implementations should 
fundamentally not be sensitive to duplicate packets.

 From my own foggy memory HPR has it's own duplicate detection 
reordering and retransmission mechanism (RTP), which is why it runs on 
top of UDP rather than TCP iirc. If that has limitations that send one 
to look to the ip header I guess that's a problem, but it seems like a 
relatively constrained and well understood environment would exist 
around such flows. It also seems that in that particular case the shim 
already exists (unless it's totally inadequate) but you probably are in 
a better position to describe the limitations of RTP than I.

> I think maybe we will now start to work on our draft of the solution 
> we envisage and then maybe we can have a new discussion. We definitely 
> will take all the suggestions into account.
>
> *From:* "Templin, Fred L" <[email-masked]>
> *To:* Nalini Elkins <[email-masked]>; Nick Hilliard 
> <[email-masked]>; "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, March 19, 2013 8:30 AM
> *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
>
> Hi Nalini,
> *From:*Nalini Elkins [mailto:[email-masked]]
> *Sent:* Tuesday, March 19, 2013 8:14 AM
> *To:* Templin, Fred L; Nick Hilliard; [email-masked]
> As a matter of fact, we know the folks at Wireshark very well. We help 
> sponsor their SharkFest event. I spoke there last year & will be again 
> this year. I am trying to twist people's arms at Wireshark to come to 
> IETF and speak for themselves. Well, maybe Berlin.
> BTW, quite a while back, we asked Gerald Combs, the original developer 
> of Wireshark, to comment on our RFC and work with us. He supports our 
> efforts. I am copying his response to me here. Janice is our contact 
> at Riverbed who "own" Wireshark. He is speaking of the IP ID field in 
> the note below.
> Hi Janice and Nalini,
>
> I think this is a great idea! An explicit (and separate) diagnostic 
> field for IPv6 would definitely be helpful for Wireshark, Pilot 
> (particularly for its MSA feature) and many other tools.
>
> Two quick notes:
>
> You might want to add a SHOULD NOT or MUST NOT explicitly stating that 
> gateways must not modify or remove the IPID from packets that they 
> forward.
>
> Many OSes support random IP IDs (e.g. my laptop has a 
> "net.inet.ip.random_id" sysctl which is currently enabled), primarily 
> to improve security. Is that needed here?
> Thanks,
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> *From:*"Templin, Fred L" <[email-masked] 
> <mailto:[email-masked]>>
> *To:* Nalini Elkins <[email-masked] 
> <mailto:[email-masked]>>; Nick Hilliard 
> <[email-masked] <mailto:[email-masked]>>; "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Sent:* Tuesday, March 19, 2013 7:56 AM
> *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
> Hi Nalini
> *From:*Nalini Elkins [mailto:[email-masked]]
> *Sent:* Monday, March 18, 2013 5:49 PM
> *To:* Templin, Fred L; Nick Hilliard; [email-masked] 
> <mailto:[email-masked]>
> TCP sequence number is not enough because there can be duplicate 
> segments and retransmissions. We need a way to see if these are really 
> sent by the device or if they are just a problem in packet tracing.
> The time between these two packets is quite small. They have also been 
> having problems with connections failing.
> My conclusion would be that the second packet was NOT sent by the same 
> device that sent the first. Why? Because BOTH IPID and TTL are quite 
> different. Very unlikely that the originating device is going to 
> change BOTH that quickly. I would conclude that there is a box in the 
> middle sending a RESET for that session. And, actually, when we 
> replaced the device that we felt was the problem, sessions stayed up!
> *From:*"Templin, Fred L" <[email-masked] 
> <mailto:[email-masked]>>
> *To:* Nalini Elkins <[email-masked] 
> <mailto:[email-masked]>>; Nick Hilliard 
> <[email-masked] <mailto:[email-masked]>>; "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Sent:* Monday, March 18, 2013 3:53 PM
> *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
> Hi Nalini,
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Nalini Elkins
> *Sent:* Monday, March 18, 2013 3:40 PM
> *To:* Nick Hilliard; [email-masked] <mailto:[email-masked]>
> Totally agree with you about trying to understand each other's point 
> of view. We absolutely want to do that. I think Mike was responding to 
> the comment on the need for IPID itself.
> As far as a solution, we are thinking that IPv6 extension headers are 
> a non-starter. For all the reasons that have been brought up.
> So, we are thinking of a header higher up the layers. For example, 
> between the Transport Layer (TCP / UDP) and the application payload.
> *From:*Nick Hilliard <[email-masked] <mailto:[email-masked]>>
> *To:* [email-masked] <mailto:[email-masked]>
> *Sent:* Monday, March 18, 2013 2:56 PM

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 16:41:43 +0000

The HUGE fundamental divide I see (as a new comer to IETF),  is that most of the IETF populace has been running IPV6 for years.   Most of corporate America is just learning to spell it.   And most are very resistant of it today.   

This causes us to have VERY different perspectives on many IPV6 issues.   

I can only hope we can attempt to see each others perspectives and bridge many of this gaps to jointly create overall effective solutions.   

Perhaps I sound naïve or Pollyannaish,  but I really do hope for this!  

Sorry for coming so late to this party! :)

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Tuesday, March 19, 2013 12:26 PM
To: Ackermann, Michael
Cc: [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

On 19/03/2013 15:18, Ackermann, Michael wrote:
> His comments (please see the slide for details),  were very supportive 
> of IPID being retained in V6.

"retained" is an argument which should have happened in 1996.  We're now at the "retrofit a protocol change to hundreds of millions of machines" stage.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Mar 2013 16:50:46 +0000

Hi Gert,

> From: Gert Doering [mailto:[email-masked]]
> Sent: Tuesday, March 19, 2013 9:34 AM
> To: Templin, Fred L
> Cc: Gert Doering; Nalini Elkins; [email-masked]

Yes, you are right - trying to include a UDP-encapsulated shim
all the way from the source to the destination is going to break
due to firewalls, packet filters and the like. However, if the
shim header was included by an ingress tunnel endpoint somewhere
in the network beyond the original source and then removed by an
egress tunnel endpoint somewhere else in the network before the
final destination then it should be OK. But, you lose the
ability to control the ID from either the source or destination.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 09:50:37 -0700

I think Fred and I have made our position clear.

A few bits may be millions to you or even to a few of your clients, but 
it's hundreds of billions to everyone else. That's not a business model 
that the IETF should support.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 09:53:03 -0700

Your view of IPv6 deployment seems a bit dated.

It might be useful to take a look here:

http://eggert.org/meter/ipv6

Joe

On 3/19/2013 9:41 AM, Ackermann, Michael wrote:
> mental divide I see (as a new comer to IETF),  is that most of the IETF populace has been running IPV6 for years.   Most of corporate America is just learning to spell it.   And most are very resistant of it today.
>
> Perhaps I sound

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 10:01:39 -0700 (PDT)

Guys,

"However, if the shim header was included by an ingress tunnel endpoint somewhere in the network beyond the original source and then removed by an egress tunnel endpoint somewhere else in the network before the
final destination then it should be OK. But, you lose the ability to control the ID from either the source or destination."

VERY interesting point.  And, BTW, we would like to include more "value-added" information such as timestamp, etc.   Our hope is that the value provided will overcome all the work involved.
 
Thanks,

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

________________________________
 From: "Templin, Fred L" <[email-masked]>
To: Gert Doering <[email-masked]> 
Cc: Nalini Elkins <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, March 19, 2013 9:50 AM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Hi Gert,

Thanks - Fred

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 10:04:14 -0700 (PDT)

Joel,

RTP is quite complex and intelligent.  You actually end up with 8 or so possible headers (sometimes more with optional segments) starting with the IP header until you get to the final data portion.  (Let's hope that packet was worth sending!  )

But, I used RTP as just an example of a protocol embedded within UDP.
 
Thanks,

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

________________________________
 From: joel jaeggli <[email-masked]>
To: Nalini Elkins <[email-masked]>; "Templin, Fred L" <[email-masked]>; Nick Hilliard <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, March 19, 2013 9:40 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

I think that's a little more subtle than find the source of duplicates with different flags in a TCP stream, TCP implementations should fundamentally not be sensitive to duplicate packets.

From my own foggy memory HPR has it's own duplicate detection reordering and retransmission mechanism (RTP), which is why it runs on top of UDP rather than TCP iirc. If that has limitations that send one to look to the ip header I guess that's a problem, but it seems like a relatively constrained and well understood environment would exist around such flows. It also seems that in that particular case the shim already exists (unless it's totally inadequate) but you probably are in a better position to describe the limitations of RTP than I.

> *To:* Nalini Elkins <[email-masked]>; Nick Hilliard <[email-masked]>; "[email-masked]" <[email-masked]>
> *From:*"Templin, Fred L" <[email-masked] <mailto:[email-masked]>>
> *To:* Nalini Elkins <[email-masked] <mailto:[email-masked]>>; Nick Hilliard <[email-masked] <mailto:[email-masked]>>; "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *To:* Templin, Fred L; Nick Hilliard; [email-masked] <mailto:[email-masked]>
> *From:*"Templin, Fred L" <[email-masked] <mailto:[email-masked]>>
> *To:* Nalini Elkins <[email-masked] <mailto:[email-masked]>>; Nick Hilliard <[email-masked] <mailto:[email-masked]>>; "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *From:[email-masked] <mailto:[email-masked]> [mailto:[email-masked]] *On Behalf Of *Nalini Elkins

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 10:05:37 -0700 (PDT)

"But companies are moot anyway, they do what they want, and in which time frame they want that - the Internet at large is already moving to IPv6, and it's too late for fundamental changes to the packet format or the
stacks."

Maybe.
 
Thanks,

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

________________________________
 From: Gert Doering <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Gert Doering <[email-masked]>; Bill Jouris <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, March 19, 2013 9:14 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Hi,

Gert Doering
        -- NetMaster

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 10:10:43 -0700 (PDT)

What we want is a way to make the SHIM somehow optional.

Definitely, I can see people other than us wanting to use it.   

I know kids at the local university are programming apps for Android that are for the users of Emergency Medical and Fire.   This is a critical app.  They might want reliable access and performance diagnostics.

I can imagine that if cell phone companies started offering different classes of service to the Internet (I know people will get all up in arms about this!).  But, if it is a way for them to charge more, they may want to do it.  Any time you charge more, people will want to monitor if they are getting what they paid for.   Hey, use our SHIM!

Having said all this, in my humble experience, the corporate world is not exactly powerless in getting what they want implemented.

Thanks,

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

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 10:16:47 -0700 (PDT)

I would wonder what the depth of the IPv6 implementation is.  And, what "sites" were talked to.

I, myself, have been worked in the corporate world for over 30 years and talk to multiple Fortune 1,000 companies daily.  I can tell you that a number are looking at their web sites & external access (but NOT their internal network).   A few are looking at internal implementation, and quite a few are saying "We have no plans to look at this".  

This whole discussion points out the reasons that corporations need to be involved in IETF - it will be good for both parties.  We are working on this!
 
Thanks,

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

Sent: Tuesday, March 19, 2013 9:53 AM

Joe

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 Mar 2013 18:19:01 +0100

Hi,

> I would wonder what the depth of the IPv6 implementation is.  And, what "sites" were talked to.

"Google and Facebook".

Anything else of relevance?

Gert Doering
        -- NetMaster

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 10:23:36 -0700

> I would wonder what the depth of the IPv6 implementation is.  And, what

The website I gave should have info on the sites; the idea of the 
website was to check something a lot like "Fortune 500" companies, at 
least for the US ones.

> I, myself, have been worked in the corporate world for over 30 years and
> talk to multiple Fortune 1,000 companies daily.  I can tell you that a
> number are looking at their web sites & external access (but NOT their
> internal network).   A few are looking at internal implementation, and
> quite a few are saying "We have no plans to look at this".

Sure, but why bother making this available publicly if nobody uses it?

Also, internal IPv6 deployment is known to be very widescale - notably 
in cellphone networks.

Joe

>
> This whole discussion points out the reasons that corporations need to
> be involved in IETF - it will be good for both parties.  We are working
> on this!
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>
> *To:* "Ackermann, Michael" <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, March 19, 2013 9:53 AM
>  > mental divide I see (as a new comer to IETF),  is that most of the
> IETF populace has been running IPV6 for years.  Most of corporate
> America is just learning to spell it.  And most are very resistant of it
> today.
>  >
>  > I can only hope we can attempt to see each others perspectives and
> bridge many of this gaps to jointly create overall effective solutions.
>  >
>  > Perhaps I sound

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Mar 2013 17:26:51 +0000

Here's another thought - just to have it out on the table. Both
SCTP and DCCP have sequence numbers, so that is something that
might be worth considering. But, the network is still very much
entrenched in TCP and UDP as the only "legitimate" protocols so I
think it would take a monumental push to get them promoted to be
on equal footing with TCP and UDP. Just the same, you might want
to see if there is a community of interest behind SCTP/DCCP and
join forces with them.

Thanks - Fred

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 17:31:36 +0000

Interesting.  

Something I can use to try promote IPV6.    The 9% looks impressive.   Even though the DNS stats published will reflect probably 0% of what we access, no one will realize that.  

Thanks!   

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, March 19, 2013 12:53 PM
To: Ackermann, Michael
Cc: Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 10:35:50 -0700 (PDT)

In my opinion, Google and Facebook do not exactly represent corporate America.  Corporate America does really boring things like making sure your mortgage gets paid and that you have health insurance.  It doesn't matter if your Google search has to be entered twice.  At least to me, it matters if my mortgage payment is taken out twice.

Having said that, in quite a few ways, Google and Facebook have been smarter than us in recognizing where the party has been going on.   

Believe me, we are working on getting more of us informed and to the party.   Whatever happens, I want to make sure that starting now, we know what is going on and that we have a voice.
 
Thanks,

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

________________________________
 From: Gert Doering <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Joe Touch <[email-masked]>; "Ackermann, Michael" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, March 19, 2013 10:19 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 
Hi,

"Google and Facebook".

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 Mar 2013 17:41:44 +0000

On 19/03/2013 16:41, Ackermann, Michael wrote:
> The HUGE fundamental divide I see (as a new comer to IETF),  is that
> most of the IETF populace has been running IPV6 for years.

If only they did, we wouldn't have half the amount of b/s we have with ipv6
today (e.g. the grand dhcpv6 vs SLAAC debacle, sigh) :-(

> Most of
> corporate America is just learning to spell it.   And most are very
> resistant of it today.

yep.

> bridge many of this gaps to jointly create overall effective solutions.

The issue is very simple: you're proposing something which will sit near
the bottom of the ipv6 protocol stack.  We can only move forward with a
proposal change if it's backwards compatible and it doesn't break stuff.

If you propose a shim, that will probably break backwards compatibility
with existing ipv6 installations.

Extension headers are incompatible with shifting packets at the speeds we
need to shift them at - i.e. they break ipv6 from a practical point of
view.  So any proposal you make which involves creating new extension
headers will also be shot down.

Unfortunately, this leaves your proposal as unworkable in its current
incarnation.  If you can find a way of getting a shim layer to work, then
go for it, but I suspect this is also a dead end.

The encapsulation suggestion may actually work - many problems can be
solved by adding another layer of indirection.

Would also suggest you check out rfc1925, particularly section 2.1 and
2.6a.  Wise words there.

Nick

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 17:46:23 +0000

Most enterprises block facebook.

From: Nalini Elkins [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 1:36 PM
To: Gert Doering
Cc: Joe Touch; Ackermann, Michael; [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com<http://www.insidethestack.com>
________________________________
From: Gert Doering <[email-masked]<mailto:[email-masked]>>
To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>
Cc: Joe Touch <[email-masked]<mailto:[email-masked]>>; "Ackermann, Michael" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 19, 2013 10:19 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Hi,

"Google and Facebook".

Gert Doering
        -- NetMaster

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Mar 2013 10:54:35 -0700

I don't think this is a productive or useful direction for this 
discussion to go.

I would appreciate it if the participants would adhere to the problem 
domain, rather than perhaps engendering a descent into list anarchy.

Thanks
your AD
Joel

On 3/19/13 10:46 AM, Ackermann, Michael wrote:
> *Sent:* Tuesday, March 19, 2013 1:36 PM
> *To:* Gert Doering
> *Cc:* Joe Touch; Ackermann, Michael; [email-masked]
> In my opinion, Google and Facebook do not exactly represent corporate 
> America.  Corporate America does really boring things like making sure 
> your mortgage gets paid and that you have health insurance.  It 
> doesn't matter if your Google search has to be entered twice.  At 
> least to me, it matters if my mortgage payment is taken out twice.
>
> Having said that, in quite a few ways, Google and Facebook have been 
> smarter than us in recognizing where the party has been going on.
>
> Believe me, we are working on getting more of us informed and to the 
> party.   Whatever happens, I want to make sure that starting now, we 
> know what is going on and that we have a voice.
>
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com <http://www.insidethestack.com>
>
> *From:*Gert Doering <[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]>>
> *Cc:* Joe Touch <[email-masked] <mailto:[email-masked]>>; "Ackermann, 
> Michael" <[email-masked] <mailto:[email-masked]>>; 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Tuesday, March 19, 2013 10:19 AM
> 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: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 11:37:42 -0700 (PDT)

Thanks, Fred.  Good thought.

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

Sent: Tuesday, March 19, 2013 10:26 AM

Thanks - Fred

---

From: Doug Barton <[email-masked]>
Date: Tue, 19 Mar 2013 13:35:21 -0700

One of the chief complaints from people who have considered implementing 
IPv6, but have not done so yet, is that the IETF keeps tinkering with 
the protocol. Others much more knowledgeable than I have already pointed 
out the technical reasons why it would not be possible to implement the 
IPID field in the manner you describe in a way that is backwards 
compatible with existing installations, and not doing it in a backwards 
compatible way is a non-starter.

I have no small amount of sympathy for your concern, but it seems that 
we're in the "that ship has already sailed" territory unless you can 
provide a robust solution that won't require changes to the installed base.

Doug

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 13:46:27 -0700

Besides "that ship has sailed", I think it's useful to consider *why* it 
sailed in the direction it has, in terms of both cost and complexity.

JOe

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 19 Mar 2013 14:12:01 -0700 (PDT)

Thanks Doug.  Appreciate the comments.

Let's see what we can do to as you say, "provide a robust solution that won't require changes to the installed base."
 
Thanks,

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

________________________________
 From: Doug Barton <[email-masked]>
To: [email-masked] 
Sent: Tuesday, March 19, 2013 1:35 PM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Doug

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 19 Mar 2013 23:14:55 +0000

In sticking with the maritime  metaphors, are you concerned at all that your ship may have a lighter load (e.g. less bits), but may be lacking the tools or supplies (e.g. IPID) to repair itself QUICKLY in the event of a disaster?      It's a decision of where the real cost and complexity and risk exist in the implied scenario.  

I get that the perspective of my organization and those like us is very different than many at IETF, but our ships do not usually leave port until it is completely ready, safe and as prepared as possible for the unknown.   

That is my concern for IPV6 in corporate America.  That it may leave port before it is ready and .......................

Do I wish we made our case years ago?   Heck yes.   And I again apologize for being late.    Is it better late than never????????  

I am going to go eat some spinach now!  :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Tuesday, March 19, 2013 4:46 PM
To: Doug Barton
Cc: [email-masked]
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

Besides "that ship has sailed", I think it's useful to consider *why* it sailed in the direction it has, in terms of both cost and complexity.

JOe

On 3/19/2013 1:35 PM, Doug Barton wrote:
> One of the chief complaints from people who have considered 
> implementing IPv6, but have not done so yet, is that the IETF keeps 
> tinkering with the protocol. Others much more knowledgeable than I 
> have already pointed out the technical reasons why it would not be 
> possible to implement the IPID field in the manner you describe in a 
> way that is backwards compatible with existing installations, and not 
> doing it in a backwards compatible way is a non-starter.
>
>> I, myself, have been worked in the corporate world for over 30 years 
>> and talk to multiple Fortune 1,000 companies daily.  I can tell you 
>> that a number are looking at their web sites & external access (but NOT their
>> This whole discussion points out the reasons that corporations need 
>> to be involved in IETF - it will be good for both parties.  We are 
>> working on this!
>> Thanks,
>>
>> Nalini Elkins
>> Inside Products, Inc.
>> (831) 659-8360
>> www.insidethestack.com
>>
>> ---