Internet-Draft Civic and Geolocation Support July 2023
Gundavelli Expires 13 January 2024 [Page]
Intended Status:
Standards Track
S. Gundavelli

Civic Location and Geospatial Coordinate Support in IPv6 ND


The physical location of a network device plays a crucial role in various applications, particularly in emergency calling, where precise caller location information is essential for prompt and effective emergency response.

RFC 4676 has standardized DHCP options for delivering the Civic Location of the client, while RFC 6225 has defined DHCP options for delivering the Geospatial coordinates of the client. However, these corresponding options are missing in IPv6 Neighbor Discovery protocols.

This proposal aims to address this gap by introducing the necessary options for IPv6 Neighbor Discovery to provide accurate location information.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 13 January 2024.

Table of Contents

1. Introduction

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.

[RFC4676] has standardized DHCP options for delivering the Civic Location of the client, while [RFC6225] 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.

2. Conventions and Terminology

2.1. Conventions

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 [RFC2119].

2.2. Terminology

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

3. Overview

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 [RFC4676] and Geospatial coordinate options [RFC6225] from DHCP as IPv6 Router Advertisement options [RFC4861]. Standardize new options.

Approach-2: There was a proposal on defining a new Router Advertisement IPv6 ND messag [I-D.troan-6man-universal-ra-option]. 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 [RFC8801], 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?

4. IANA Considerations


5. Security Considerations


6. Acknowledgements


7. References

7.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <>.

7.2. Informative References

Winters, T. and O. Trøan, "The Universal IPv6 Configuration Option", Work in Progress, Internet-Draft, draft-troan-6man-universal-ra-option-06, , <>.
Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4676, DOI 10.17487/RFC4676, , <>.
Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed., "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, DOI 10.17487/RFC6225, , <>.
Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", RFC 8801, DOI 10.17487/RFC8801, , <>.

Author's Address

Sri Gundavelli
170 West Tasman Drive
San Jose, CA 95134
United States of America