Subject: Re: [ippm] IPv6 Destination Option Requested for IPv6GEO

From: Nalini Elkins <[email-masked]>
Date: Mon, 15 Sep 2014 14:11:39 -0700

Fred,

I think this is very interesting and could be quite useful for the work we are doing in diagnostics and measurement as well as for the usage cases you have cited.

We also have proposed an IPv6 Destination Option which will contain performance and diagnostic information.   Please see:

https://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option/

and

https://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-option/

I think that if a packet were to have both Destination Options, it would be very useful indeed.

I have some comments about the layout of your destination option.   First, we have put in quite a bit of effort to compress our delta time into a time value which if used in conjunction with the scale, can convey times from picoseconds up to years (potentially needed for DTN).  Our value is 16 bits + an 8 bit scale value.  There is some loss of precision, but it is relatively negligible.   I understand yours is a timestamp and not a delta value with a granularity at the microsecond level.   One can deduce timezone from the latitude and longitude.

Secondly, I wonder if you might be willing to add a couple of packet sequence numbers to your destination option - I am thinking of "this packet number" and "packet number last received"?   Those are of great help in troubleshooting and diagnostics.

I am copying the IPPM group on this, as I believe this may also be of interest to them.   I had meant to talk to you earlier about if the DTN group might also be interested!

Thanks,

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

________________________________
From: "Templin, Fred L" <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Monday, September 15, 2014 10:01 AM
Subject: IPv6 Destination Option Requested for IPv6GEO

Hello,

We would like to request the assignment of an IPv6 Destination Option
for including geolocation information in the headers of IPv6 packets
(IPv6GEO). Accordingly, we would like to request publication of our
document as a Proposed Standard:

  https://datatracker.ietf.org/doc/draft-skeen-6man-ipv6geo/

Our reason is this. In our industry, there are many examples of nodes 
that willingly submit themselves for active surveillance. If the last
thing ever heard from such a node is a single isolated IPv6 packet
or fragment, the surveillance authority will want to know where it
came from.

Comments?

Brian Skeen, Ed King, Fred Templin
The Boeing Company

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Sep 2014 22:27:51 +0000

Hi Nalini,

> Fred,
> 
> I think this is very interesting and could be quite useful for the work we are doing in diagnostics
> and measurement as well as for the usage cases you have cited.

OK, thanks.

> https://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-option/

Thanks for the pointers.

> I think that if a packet were to have both Destination Options, it would be very useful indeed.

That would certainly be permissible by the standards, yes.
 
> I have some comments about the layout of your destination option.   First, we have put in quite a bit
> of effort to compress our delta time into a time value which if used in conjunction with the scale,
> can convey times from picoseconds up to years (potentially needed for DTN).  Our value is 16 bits + an
> 8 bit scale value.  There is some loss of precision, but it is relatively negligible.   I understand
> yours is a timestamp and not a delta value with a granularity at the microsecond level.   One can
> deduce timezone from the latitude and longitude.

The reason we preferred the timestamp instead of some delta since
the previous packet is because we will want each packet to stand
on its own since we may only ever get one of them.

> Secondly, I wonder if you might be willing to add a couple of packet sequence numbers to your
> destination option - I am thinking of "this packet number" and "packet number last received"?   Those
> are of great help in troubleshooting and diagnostics.

Again, our idea was to approach this from an isolated single packet
standpoint, so packet sequence numbers may not have much usefulness
in this context.

> I am copying the IPPM group on this, as I believe this may also be of interest to them.   I had meant
> to talk to you earlier about if the DTN group might also be interested!

I think the DTN group would view this as a hop-by-hop link-layer
consideration available over IPv6 convergence layers only, so it
might not be an end-to-end consideration there.

Thanks - Fred
[email-masked]