Location

(First-person) I get my own location from a server. This makes address
spoofing more difficult, with return routability. Drawback: If I'm
behind a NAT, and the location server isn't, this works only if the IP
address in the IP packet is used, not something in the query. VPNs
should not be a big deal here.

(Third-person) I ask for an address for an IP address. Address spoofing
and VPN issues matter, possibly NAT issues (since the IP address I get
may be a NAT address, given the typical circles of NAT hell in various
networks.) 


"Get the physically closest box to tell me"
  DHCP


DSL management

http://www.dslforum.org/aboutdsl/Technical_Reports/TR-069.pdf


(Direct) The wire tells the attached device where it is -> LLDP-MED,
802.11 beacons, BlueTooth beacons, etc. Little room for confusion. No
need for addresses of any sort.

(L2-interface/circuit) Server maps some circuit identifier to a
location, based on a mapping (RAIO). No MAC address needed, but probably
mainly applicable to broadband home networks rather than typical
corporate networks.

(L2-MAC) The server obtains a MAC address from the client, and then
uses various bridge-MIB tracing techniques to find out which port the
client is connected to, by checking where the MAC address has been seen.
This is subject to some failure scenarios and the problem I mentioned
obliquely earlier.

(L3) The server gets an IP address and somehow finds the location.

Note that I said "server" above - this could be a DHCP server, but
doesn't have to be. Obviously, a DHCP server has the advantage that the
client knows how to find it.

----

1) use of DHCP relay options for location determination (IETF RFC 3825 and
http://www1.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-05.txt)

2) use of LLDP-MED on enterprise Ethernet LANs (PN-3-0185,LLDP Media Endpoint
Discovery Project, letter-ballot(to be published as ANSI/TIA-1057))
3) use of various layer 2/3 information exchanges involving the Auto-Configuration
Server protocol defined by the DSL forum (refer to DSL Forum TR-069)

There are also related proposals for making location information available
for emergency calling.  One class of methods involves downloading/delivering
location information to an IP endpoint; a second class of methods involves
having another entity, e.g., a call server or a VoIP Position Server query
a Location Information Server on behalf of the IP endpoint.

In the first category, the proposed methods include:
1) automatic download to the endpoint device using the DHCP protocol (triggered
automatically during the configuration of the endpoint)
2) automatic download to the endpoint device using the LLDP-MED protocol
(defined by IEEE and TR41.4 for enterprise LANs)
3) use of ACS protocol to download location information to the CPE  
4) a variation of (3) that would allow for DHCP to be used for the last leg
of the download to the device
5) application layer protocol query from the IP endpoint  directly to the
Location Information Server to obtain location information (in some variation
of an application layer protocol such as the one described in draft-winterbottom-http-location-delivery-00.txt,
HTTP Enabled Location Delivery, submitted to IETF Geopriv WG). 

In the second category, the proposed methods include:
1) The optional VPC query of a LIS described as the V3 interface in the i2
Solution document.
2) "Option 1" in a BellSouth/Bell Canada proposal that allows a Call Server
to query the LIS directly for location information, on behalf of a caller.