Re: Adding GPS location to IPv6 header

[Jimmy Hess <mysidia () gmail com>]

On 11/25/12, William Herrin <bill () herrin us> wrote:
> On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih <ammar.salih () auis edu iq>
> wrote:
> Geographic-based layer 3 routing has been thoroughly discussed on the
> IRTF RRG and just as thoroughly rejected. It's wholly inadequate as an
> approximation for topographic locality within the network graph.

Nevertheless, there are some applications in which it might have some merit.
If  there is even one such application, then it is sensible to have the required
bits set aside, so there can be an extension in the limited cases
where it is required.

> On Sun, Nov 25, 2012 at 1:28 AM, Jimmy Hess <mysidia () gmail com> wrote:
> > On 11/24/12, John Adams <jna () retina net> wrote:
> > > Don't conflate layer 5-7 needs with basic communication requirements. IP
> > IP is the logical place for this kind of header,  as this information
> > is node dependent, not application dependent.
>
> As is the user's legal name and social security number. If it isn't
> processed by the layer 3 protocols, if they don't use it for next hop
> selection, then it doesn't belong at layer 3.

An extension header at Layer 3 containing this information should be just fine.
Or rather,  an extension, allowing a reference to a lookup service for
that information
to be placed in IP headers,  for network management should be just fine.

The actual underlying plaintext PII best be protected with IPsec and
additional measures, but that is the network implementor's
responsibility.     Not all Layer 3 headers have to influence path
selection.

There _ARE_  headers for strictly network management purposes.

Examples would include the  IP TOS header;   Route record  extensions;
Hop limit;   Timestamp.

The IP TOS header identifies a value, which can be used to prioritize
some packets;
similarly,  a network operator might have a need to  prioritize
packets with a certain
geographical origin at L3,  or   grant    certain  throughput and
performance characteristics
based on source region,   to ensure a degree of fairness with their application.


> > For example, in the case of an  anycasted service,   the  source IP
> > address does not uniquely identify where the source came from.

> Given appropriate construction of the layer 4 protocol, nothing stops
> an anycasted service from responding with a unicast IP address and

They generally will not.  The mechanism of operation of an anycasted
service is there are a small number of unicast addresses, with routes
announced from various different points.

If each region had its own unicast IP, it would just be a normal
DNS-balanced service.

Therefore, the same unicast IP address may be used from multiple regions,
for example,   the DNS servers  in different regions may have identical
IP addresses.

For network management purposes, on the End user side, it would be useful
in some cases, for  the  IP header  of  DNS and HTTP response packets,
to identify which "node"  or site is responding;
even if this cannot be indicated in the IP address fields.

It may help identify, if an issue accessing an any casted service is related to
instability of   which  route is preferred  (E.g.  thrashing of the
end user's site selection);
if there is an extension option available for  Recording or Tagging
packets with a source ID,

a situation, in which the  Record Route  IP  extension is not a viable option.


> Bill Herrin
--
-JH