Civic Location and Geospatial Coordinate Support in IPv6 ND

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 https://datatracker.ietf.org/drafts/current/.¶

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

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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

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

TBD¶

5. Security Considerations

TBD¶

6. Acknowledgements

TBD¶

Author's Address