Subject: IPv6 Destination Option Requested for IPv6GEO

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Sep 2014 17:01:52 +0000

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

---

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,

Comments?

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 15 Sep 2014 14:24:22 -0700 (PDT)

Greetings,

There are two small issues I'd like to raise:

1.) Although it is not hard to infer, it would be good to state 
explicitly in Section 5.2 that the units of latitude and longitude 
are degrees.

2.) It would be good to see this proposal coordinated with
draft-gont-6man-ipv6-opt-transmit.

Thanks

Mike Heard

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 15 Sep 2014 22:03:37 +0000

Fred,

Why does this information belong in the IP layer, as opposed to the transport or application layers?

                                Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Monday, September 15, 2014 1:02 PM
> To: [email-masked]
> 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:
> 
> 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?
>

---

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]

---

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

> From: C. M. Heard [mailto:[email-masked]]
> Sent: Monday, September 15, 2014 2:24 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: IPv6 Destination Option Requested for IPv6GEO
>
> 
> Greetings,
> 

Yes, we can certainly address that. Thanks.
 
> draft-gont-6man-ipv6-opt-transmit.

Thanks for the pointer; we will contact the authors.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Mon, 15 Sep 2014 15:39:58 -0700

That is my question as well.

Bob

---

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

Hi Ron,

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Monday, September 15, 2014 3:04 PM
> To: Templin, Fred L; [email-masked]
> Subject: RE: IPv6 Destination Option Requested for IPv6GEO
> 
> Fred,
> 

We may only get a single IPv6 packet/fragment, and a minimal IPv6
packet may include only headers and nothing more. In many use cases,
we will still want to know where the packet/fragment came from.

Thanks - Fred

---

From: Ca By <[email-masked]>
Date: Mon, 15 Sep 2014 18:09:53 -0700

> [email-masked]

Why would you only get a fragment or header?

Bits are bits, why can this not be in the leading part of the application
data at approximately the same bit-stream position as header would be?

> > > We would like to request the assignment of an IPv6 Destination Option
for
> > > Our reason is this. In our industry, there are many examples of nodes
that

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 16 Sep 2014 02:29:19 +0000

Fred,

I am afraid that I don't understand your answer at all. To whom does "we" refer? Can you say a little more about the use-case?

                                                       Ron

> 
> We may only get a single IPv6 packet/fragment, and a minimal IPv6 packet
> may include only headers and nothing more. In many use cases, we will still
> want to know where the packet/fragment came from.
>

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 16 Sep 2014 13:00:19 +0200

Hi,

> Why does this information belong in the IP layer, as opposed to the transport or application layers?

This was also my question when I read this. Currently, I don't see any
reason that this information is actually useful at the IP / routing layer.

>> authority will want to know where it came from.

Without having read the draft I don't understand why an application
layer protocol couldn't provide this in the very first bits if this GEO
information is so important for you. Fragmentation by the IP layer
should be avoided anyway and better be done at the application layer
(following the ALF principle, or maybe at the transport layer).
Moreover, I think that the GEO location information - even if
transported via an IP extension header - will _not_ be evaluated within
the IP layer, but maybe at the application layer.
So IMHO it is not good to couple such things that belong to normally
totally disjunct functions (at different layers), and which
are separated for a good reason.

Regards,
 Roland

---

From: Brian Haberman <[email-masked]>
Date: Tue, 16 Sep 2014 09:27:06 -0400

All,
     I am making these statements with my AD hat off...

We have been here before.  Several times.  I am quite sure that the
issues raised during the previous discussions have not (and cannot) be
addressed.  The history of trying to add geographic information to the
network layer includes:

1. VANET-related research
(http://www.researchgate.net/publication/224108335_Geographical_information_extension_for_IPv6_Application_to_VANET)

2. Tony Hain's geo-based IPv6 addressing scheme
(http://tools.ietf.org/html/draft-hain-ipv6-geo-addr-02)

3. A different proposal to add geographic information to the IPv6 header
(http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/)

4. A patent on carrying geographic information in an IPv6 extension
header (https://www.google.com/patents/US7330726).

I am sure I have forgotten other instances, but that is beside the
point.  In this day and age, there needs to be strong justification to
add this type of information to the network layer, especially in light
of RFC 7258.

Regards,
Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 16 Sep 2014 15:45:56 +0000

> add this type of information to the network layer, especially in light

In this I scratch my head. If this were a required information element, I would very much agree - I should not be forced to disclose my location without my consent. But it’s not; it is within the context of a business, and the given business has the requirement. There are a number of use cases in section 4 of draft-skeen-6man-ipv6geo-01.txt; you’re welcome to your opinion on each of them, but the point stands that they exist.

I divide between “has the capability” and “is required to on the open backbone”. From a technology perspective, I don’t see providing a way to encode information implies a requirement to use it in any given case.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 16 Sep 2014 12:00:46 -0400

Hi Fred,

On 9/16/14 11:45 AM, Fred Baker (fred) wrote:
>> point.  In this day and age, there needs to be strong justification
>> to add this type of information to the network layer, especially in
>> light of RFC 7258.
> 
> In this I scratch my head. If this were a required information
> element, I would very much agree - I should not be forced to disclose
> my location without my consent. But it’s not; it is within the
> context of a business, and the given business has the requirement.
> There are a number of use cases in section 4 of
> draft-skeen-6man-ipv6geo-01.txt; you’re welcome to your opinion on
> each of them, but the point stands that they exist.

I agree they do exist.  But the question, to me, is why at the network
layer?  None of the described scenarios described in section 4 explain
why this info needs to be in the network layer.  In fact, several of the
scenarios sound like existing applications that I have seen in the wild.

This is a pertinent question given the amount of data that has been
presented on the inclusion of IPv6 extension headers leading to packet
drops.

> 
> I divide between “has the capability” and “is required to on the open
> backbone”. From a technology perspective, I don’t see providing a way
> to encode information implies a requirement to use it in any given
> case.
> 

I agree with the above.  I was trying to point out that this approach
has been presented before and I currently do not see any new
justification that would change the state of consensus from the last
time we discussed this.

It was also pointed out to me in private that the authors may want to
look at what the geopriv and netext WGs are doing (or have done) in
sending geo information.

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2014 17:33:42 +0000

Hi Brian,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Tuesday, September 16, 2014 9:01 AM
> To: [email-masked]
> > my location without my consent. But it's not; it is within the
> > draft-skeen-6man-ipv6geo-01.txt; you're welcome to your opinion on

We have seen some of the past activities in this space, but we
believe we are bringing some new perspectives. In particular,
we care about use cases in which the source of geolocation
data actually wants to be geolocated (e.g., planes in the sky,
ships at sea, search and rescue units in the field, etc.).

In many cases, communications messaging is very expensive and
data links are already over-subscribed. And, periodic beaconing
might alert nearby adversaries to a node's location. So, a node
should be able to piggyback geolocation data onto existing
messages without having to modify applications.
 
> > I divide between "has the capability" and "is required to on the open
> > backbone". From a technology perspective, I don't see providing a way

Again, we care about use cases in which the geo information is
included at the discretion of the source for the benefit of the
destination(s) - such as when the source really wants its
friends to be able to find it. Nodes that do not want to be
found simply omit the option.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Sep 2014 22:26:52 +0200

Hello,

Please allow me a comment here.

This question is immediately clear, especially when several IP 
applications are known to use lat/long/alt coordinates payloads of IP 
packets, most often in HTTP messages.

One should consider too another perspective looking at the numerous 
application domains - most often in mobility environments, mobile 
persons carrying devices, or mobile vehicles connecting to other mobile 
or fixed entities, where the position information is of paramount 
importance.  Some of these application domains are listed in the draft.

The positioning information is so important that these application 
domains rarely use IP protocols at all - you get application data 
directly over some particular communication link, to just transmit the 
coordinates.  It is the case for example in ETSI ITS (Intelligent 
Transportation Systems).

This is not a desirable situation either - there is positioning 
information communicated but not over heterogeneous links.

Other simpler applications where sysadmins feel needs of simple 
positioning information is to locate WiFi Access Points - where is that 
Router Advertisement coming from?  (so I can reconfigure it).

Also, there is this Routing Header which specifies 'where' the packet 
should go first.  Sometimes applications need to specify this 'where' in 
terms of real geography terms (not 'where' in IP terms), for reasons 
related to non-Internet governance - eg I dont want my traffic to cross 
this country because its legislation forbids that particular application.

This is to say that whereas it looks natural for net-layer people to 
consider everything else to be an application, there are also 
non-net-layer people who find the net layer to be an overhead.

Alex

>>
>> Ron
>>
>>> -----Original Message----- From: ipv6
>>> [mailto:[email-masked]] On Behalf Of Templin, Fred L Sent:
>>> Monday, September 15, 2014 1:02 PM To: [email-masked] 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:
>>>
>>> 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
>>>
>>> [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Sep 2014 22:33:38 +0200

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

Hello Fred,

Thank you for this draft that I read with interest.

It has a section mentioning other works at IETF in this space, like the 
geopriv WG.

I think that section could add to its advantage the drafts mentioned by 
Brian H. later in this thread.

Also, I would like to advertise the GEONET BoF of Vancouver, and the 
email list ietf.org/mailman/listinfo/its - we try to see what could be 
done in this space.

People interested in this discussion may join that mailing list and join 
expertise related to geography, IPv6, mamming DNS/LISP and applications.

Alex

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 16 Sep 2014 14:33:10 -0700

>non-net-layer people who find the net layer to be an overhead.

I am wondering if there is a different question here.   Geo coordinates may fall into the category of information needed for overall packet management.   There are other metrics which also fall into this category.  

Since there is no layer which precedes IP that one might put such information into nor is there an out-of-band layer for such variables AND there is a need for such functions and metrics, then DO is being chosen as being such a vehicle.

Nalini

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Sep 2014 10:48:54 +0200

> scenarios sound like existing applications that I have seen in the wild.

I agree.  Many existing applications that one can easily see in the wild 
run indeed at the app layer.  For example WAZE (a recent app from Google 
which tells car traffic situation).

A user may easily be satisfied with this app - it is really sufficient.

But, for the same need - express car traffic information - there are 
also other applications used by professionals which may be more 
accurate.  These applications rarely use IP, they run straight over some 
radio link - only that link.  They use dedicated sensors to capture 
data, dedicated communication channels, dedicated people taking care of it.

> presented on the inclusion of IPv6 extension headers leading to packet

I agree.

> look at what the geopriv and netext WGs are doing (or have done) in

I am not an author but here are my thoughts.

Yes, the flagship product from geopriv WG is the PIDF-LO format which is 
an xml kind to be transported presumably over HTTP, way above IP, to 
encode location information.

The netext WG has draft-ietf-netext-ani-location-03.txt
"Extensions to the PMIPv6 Access Network Identifier Option"

Also DHC WG led to RFC 3825 "Dynamic Host Configuration Protocol Option 
for Coordinate-based Location Configuration Information"

In my understanding these latter two document how the network tells the 
node where it is.  This is different than the node knowing where it is 
by other means[*] and telling it to the network.  This may be more 
appropriate for an end node that believes to know better.

Alex
[*] almost all if not all chipsets recently on the market for IoT and 
M2M that feature cellular communication capabilities also feature GNSS 
capability like GPS and Glonass.  This is important - it is not simply 
that large smartphone platforms featuring a plethora of wireless links, 
NFC and sensors; it is the GNSS built-in everything that is cellular link.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Sep 2014 20:44:04 +0000

Hi Alex,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Wednesday, September 17, 2014 1:49 AM
> To: [email-masked]

We would like to be able to geolocate isolated IPv6 packets whose
application content does not include location information, such as
when a pilot's voice messaging to air traffic control falls silent.

> data, dedicated communication channels, dedicated people taking care of it.

Non-IP links certainly exist in our domains of interest, yes.
But, data link availability and reliability are areas for concern.

> > presented on the inclusion of IPv6 extension headers leading to packet

In controlled networks, packet drops due to extension headers
may not be so much of an issue.

> appropriate for an end node that believes to know better.

Again, our use cases would be satisfied by the ability to determine
the location of origin of an isolated IPv6 packet whose application
content does not include location information.

Thanks - Fred

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Sep 2014 15:13:21 -0700

Fred it seems there's a bit of effort here that I don't really understand.

IPv6geo lists a number of possible use cases for the field as well as
describing the field itself, it does not really tease out the problem
statement.

In some respects the use cases appear to have some commonality with
host-id work in the IETF.

The problem statement might be (and I'm speculating here)  " a need
exists for reliable low bandwidth delay tolerant telemetry at a
relatively high frequency carried over ip."  from that vantage point
(and with an eye towards the stated consideration of ads-b I would
imagine one encoding ground speed vertical rate and heading as well.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Sep 2014 22:28:57 +0000

Hi Joel,

> From: joel jaeggli [mailto:[email-masked]]
> Sent: Thursday, September 18, 2014 3:13 PM
> To: Templin, Fred L; Alexandru Petrescu; [email-masked]

Maybe we could address this in a new paragraph under "Motivation"?

> relatively high frequency carried over ip."

Yes, that would fit one aspect of the motivation. I think we could
also touch on other aspects, such as the ability to geolocate an
isolated IPv6 packet that shows up in a packet trace, log, etc.

> from that vantage point

Yes, that is right. We purposefully specified a "minimal" position-only
encoding in the draft with the expectation that other information such
as you mentioned would be included in a new "GEO Type" to be defined
later.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Sep 2014 10:31:21 +1200

Fred,

On 19/09/2014 08:44, Templin, Fred L wrote:
...
> when a pilot's voice messaging to air traffic control falls silent.

Living only a few thousand km from where MH370 may or may not lie
under the ocean, and from the area where the yacht carrying our lost
colleague Evi Nemeth went missing, it's easy to understand the motivation.
But for such purposes, shouldn't this be handled at layer 2 so that
all forms of communication are covered?

   Brian

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 18 Sep 2014 22:39:10 +0000

>From my experience it's better to drive changes up the stack, not down - lossy high latency L2s would be loath to add anything like this...besides what else is there but IP ;) Remembering the t-shirt. I used to see at plenary meetings ( IP - necessary and sufficient ;)

-------- Original message --------
From: Brian E Carpenter <[email-masked]>
Date:09/18/2014 5:31 PM (GMT-06:00)
To: "Templin, Fred L" <[email-masked]>
Cc: Alexandru Petrescu <[email-masked]>, [email-masked]
Subject: Re: IPv6 Destination Option Requested for IPv6GEO

Fred,

   Brian

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Sep 2014 23:01:07 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, September 18, 2014 3:31 PM
> To: Templin, Fred L
> Cc: Alexandru Petrescu; [email-masked]

Indeed.

> all forms of communication are covered?

Aircraft as just one example typically have many data links of widely
varying properties, and may not be available during all phases of flight.
Reliability and availability are therefore a matter of concern. There is
also typically a mix of IP-based and non-IP links - again, with a very
heterogeneous mix of characteristics.

So, if we can get IP links that do not have a layer 2 geo capability to
squawk IPv6GEO we perhaps (just perhaps) stand a chance of learning
something that we otherwise wouldn't. That's all I'm saying...

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Mon, 22 Sep 2014 13:08:02 -0700

Fred,

> something that we otherwise wouldn't. That's all I'm saying…
> 

I am still not convinced this should be at the IP layer.  I have some personal experience with communication over low bandwidth links where position is sent at an application layer (encoded in email), and via dedicated satellite transponders that periodically send position reports.  These work well.  

I am not sure that just a position is that useful, course and speed are also useful when the transmission are intermittent.  Adding that data to the extension header would make it longer and increase the overhead if sent in every datagram.

I also wonder if needs to be included in every datagram in a transport session.  Unless one is going very fast or want a great deal of positional accuracy, the position won't be changing very much in a series of datagrams.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Sep 2014 17:08:31 +0000

Hi Bob,

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Monday, September 22, 2014 1:08 PM
> To: Templin, Fred L
> Cc: Bob Hinden; Brian E Carpenter; Alexandru Petrescu; [email-masked]
> I am still not convinced this should be at the IP layer.

It should be possible to encode geo information at any layer, in case
it is not encoded at other layers. For example, if there are multiple
data links with diverse characteristics, and with diverse application
overlays, the IP layer may be the only point of commonality.

> I have some personal experience with
> communication over low bandwidth links where position is sent at an application layer (encoded in
> email), and via dedicated satellite transponders that periodically send position reports.  These work
> well.

Your experience is truly well noted, and we are pleased that your
needs were satisfied.

> I am not sure that just a position is that useful, course and speed are also useful when the
> transmission are intermittent.

This was pointed out also by Joel. It could be addressed by adding a
second IPv6GEO encoding type that includes course and speed if the
wg would like for us to add that.

> Adding that data to the extension header would make it longer and
> increase the overhead if sent in every datagram.

That may depend on how frequently datagrams are sent. If sending at
100pkts/sec, then including in every datagram might be inefficient.
But, if sending at 1pkt/min or so including in every datagram might
not be so bad.

> I also wonder if needs to be included in every datagram in a transport session.  Unless one is going
> very fast or want a great deal of positional accuracy, the position won't be changing very much in a
> series of datagrams.

Right, as above.

Thanks - Fred