Civic Location and Geospatial Coordinate Support in IPv6 ND

Accurate knowledge of the physical location of a network device serves a wide range of applications. In the context of emergency telephony, precise caller location information is vital for correctly directing the emergency dispatch personnel to the correct location. An endpoint can obtain the location information from the network and can include it in the SIP (Session Initiation Protocol) signaling messages. has standardized DHCP options for delivering the Civic Location of the client, while has defined DHCP options for delivering the Geospatial coordinates of the client. However, these corresponding options are missing in IPv6 Neighbor Discovery protocols. In the case of an IPv6-only client utilizing SLAAC (Stateless Address Autoconfiguration) for auto-address configuration and obtaining configuration parameters through Neighbor Discovery (ND), it should have the capability to acquire the same information from the first-hop router over IPv6 Neighbor discovery messages.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

All the IPv6 terms used in this document are to be interpreted as defined in the IETF specifications.

Assuming there is agreement on supporting these options for IPv6 ND, we have few different paths to get there. Approach-1: Replicate the Civic Location and Geospatial coordinate options from DHCP as IPv6 Router Advertisement options . Standardize new options. Approach-2: There was a proposal on defining a new Router Advertisement IPv6 ND messag . Its purpose is to use the Router Advertisement messages as opaque carriers for configuration information between an agent on a router and a host. However, this proposal did not receive much love from the working group at that time. Is it time now to bring that document back and revisit the decision? Approach-3: With the realization of IPv6 coloring in the form of PVD , we now have the option to contain these options under a PVD scope. But the location is not a domain specific property and cannot see how it be localized under a given PVD scope. Keeping that discusison aside, should be location be retrieved as additional PvD information. If the "H" flag in the PVD option is set to a value of 1, and if PVD URI is provided, an endpoint can query the location information. For this, we need to define a JSON elements with string type, (e.g.) “Civic-Location-Country-Code”, “Civic-Location-Street” following some ISO address conventions. What is the best path for closing this gap? Is there another alternative?

TBD