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

[Shane Amante <[e-mail]>]

Nalini, All,

On Aug 15, 2011, at 7:13 AM, [e-mail] wrote:
> Well, that is a really good idea that we had explored also.  Now, we ourselves make an intelligent packet analyzer and work with the WireShark folks.  If I look at this selfishly for having an extra selling point for my products, then I can say, 'Yes, we allow you to do this!  Buy my product!'  But, I was trying to be a good citizen and allow all to do this without our products.  Now, if our proposal is not adopted, then we will do the checksum or hash on the packets in our products as I think it is needed for diagnostics. 
> 
> This idea also helps technicians who have taken a trace at one point using multiple facilities - that is, WireShark and IBM mainframe CTrace.  Then, it is useful to have the IPID shown in sequence.
> 
> But, the idea of the hash or checksum leaves aside the case where you have only one trace at one point along the path.  Being able to view the sequence of packet transmission is useful even then.  
> 
> Also, I really feel that down the road here, the 32-bit IPID is going to run into scalability issues.  We are proposing a 64-bit IPID.   The IPID is also not standardized.  Some implementations use the same IPID for all connections, others use a different IPID for each connection. Some increment by 1, some by two.
> 
> Our other future thoughts, and agenda, if you will, is that as networks and traffic grow, more and more diagnostics and troubleshooting will have do be done by computer systems rather than humans.  So, we are looking at what metrics need to be saved for that.  I feel that the IPID is one such.  There are others such as TCP Window Scaling - but that belongs on another email list, so I did not want to bring that up.

Have you taken a look at flow-spec for IPv4:
http://tools.ietf.org/html/rfc5575
... and, flow-spec for IPv6:
http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00
(Both the RFC and I-D are within the IDR WG).

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

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

-shane