[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Adding GPS location to IPv6 header
On 11/25/12, William Herrin <bill at herrin.us> wrote:
> On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih <ammar.salih at auis.edu.iq>
> 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 at gmail.com> wrote:
>> On 11/24/12, John Adams <jna at 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
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
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
similarly, a network operator might have a need to prioritize
packets with a certain
geographical origin at L3, or grant certain throughput and
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
Therefore, the same unicast IP address may be used from multiple regions,
for example, the DNS servers in different regions may have identical
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