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.
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.
