Internet-Draft | Civic and Geolocation Support | July 2023 |
Gundavelli | Expires 13 January 2024 | [Page] |
- Workgroup:
- 6MAN WG
- Internet-Draft:
- draft-gundavelli-6man-nd-location-00
- Published:
- Intended Status:
- Standards Track
- Expires:
Civic Location and Geospatial Coordinate Support in IPv6 ND
Abstract
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 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.¶
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?¶
6. Acknowledgements
TBD¶
7. References
7.1. Normative References
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC4861]
- Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
7.2. Informative References
- [I-D.troan-6man-universal-ra-option]
- Winters, T. and O. Trøan, "The Universal IPv6 Configuration Option", Work in Progress, Internet-Draft, draft-troan-6man-universal-ra-option-06, , <https://datatracker.ietf.org/doc/html/draft-troan-6man-universal-ra-option-06>.
- [RFC4676]
- Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4676, DOI 10.17487/RFC4676, , <https://www.rfc-editor.org/info/rfc4676>.
- [RFC6225]
- 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, , <https://www.rfc-editor.org/info/rfc6225>.
- [RFC8801]
- Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", RFC 8801, DOI 10.17487/RFC8801, , <https://www.rfc-editor.org/info/rfc8801>.