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