Internet DRAFT - draft-gundavelli-6man-nd-location
draft-gundavelli-6man-nd-location
6MAN WG S. Gundavelli
Internet-Draft Cisco
Intended status: Standards Track 12 July 2023
Expires: 13 January 2024
Civic Location and Geospatial Coordinate Support in IPv6 ND
draft-gundavelli-6man-nd-location-00
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.
Gundavelli Expires 13 January 2024 [Page 1]
Internet-Draft Civic and Geolocation Support July 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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
Gundavelli Expires 13 January 2024 [Page 2]
Internet-Draft Civic and Geolocation Support July 2023
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
TBD
Gundavelli Expires 13 January 2024 [Page 3]
Internet-Draft Civic and Geolocation Support July 2023
5. Security Considerations
TBD
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, March 1997,
<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, September 2007,
<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, 22 October 2021,
<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, October 2006,
<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, July 2011,
<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, July 2020,
<https://www.rfc-editor.org/info/rfc8801>.
Gundavelli Expires 13 January 2024 [Page 4]
Internet-Draft Civic and Geolocation Support July 2023
Author's Address
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sgundave@cisco.com
Gundavelli Expires 13 January 2024 [Page 5]
