Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO)
draft-skeen-6man-ipv6geo-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Brian Skeen , Fred Templin | ||
| Last updated | 2014-07-02 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-skeen-6man-ipv6geo-00
Network Working Group B. Skeen
Internet-Draft Boeing Phantom Works
Intended status: Standards Track F. Templin, Ed.
Expires: January 3, 2015 Boeing Research & Technology
July 2, 2014
Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO)
draft-skeen-6man-ipv6geo-00.txt
Abstract
This document provides a specification for including geolocation
information in the headers of IPv6 packets (IPv6 GEO). The
information is intended to be included in packets for which the
location of the source node is to be conveyed to the destination node
or nodes.
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 http://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 January 3, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://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 Simplified BSD License text as described in Section 4.e of
Skeen & Templin Expires January 3, 2015 [Page 1]
Internet-Draft IPv6 GEO July 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Motivation and Applicability . . . . . . . . . . . . . . . . 4
5. IPv6 GEO Specification . . . . . . . . . . . . . . . . . . . 6
5.1. IPv6 GEO Destination Option Format . . . . . . . . . . . 6
5.2. IPv6 GEO Option Encoding Algorithm . . . . . . . . . . . 8
5.3. IPv6 Node Requirements . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Related Work in the IETF . . . . . . . . . . . . . . . . . . 9
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
10. Contributers . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Internet Protocol, version 4 (IPv4) [RFC0791] provides limited
capabilities for including additional information in the headers of
packets. The maximum IPv4 header length is 60 bytes including any IP
options, and options are not widely used due to incompatibilities
with network middleboxes. On the other hand, Internet Protocol,
version 6 (IPv6) [RFC2460] includes an extensible header format
whereby additional information can be inserted between the IPv6
header and the transport layer header. These extensions can be
included on a per-packet basis, and not necessarily for all packets
of the same flow. This document specifies a format for including
geolocation information within the headers of individual IPv6 packets
(IPv6 GEO).
IPv6 GEO information is included at the discretion of source nodes
for the benefit of destination nodes and/or network elements that may
need to examine the headers of packets in flight. Legacy destination
nodes that do not recognize the IPv6 GEO information must ignore it
and process the rest of the packet as if it were not present. The
IPv6 specification defines several extension header types, including
the Destination Options header. Section 4.6 of [RFC2460] describes
conditions under which new information should be encoded as either a
new extension header or as a new destination option:
Skeen & Templin Expires January 3, 2015 [Page 2]
Internet-Draft IPv6 GEO July 2014
"Note that there are two possible ways to encode optional
destination information in an IPv6 packet: either as an option in
the Destination Options header, or as a separate extension header.
The Fragment header and the Authentication header are examples of
the latter approach. Which approach can be used depends on what
action is desired of a destination node that does not understand
the optional information:"
Section 3 of [RFC6564] further states that:
"The base IPv6 standard [RFC2460] allows the use of both extension
headers and destination options in order to encode optional
destination information in an IPv6 packet. The use of destination
options to encode this information provides more flexible handling
characteristics and better backward compatibility than using
extension headers. Because of this, implementations SHOULD use
destination options as the preferred mechanism for encoding
optional destination information, and use a new extension header
only if destination options do not satisfy their needs. The
request for creation of a new IPv6 extension header MUST be
accompanied by a specific explanation of why destination options
could not be used to convey this information."
Our first interpretation of this guidance and the supporting text
that follows suggests that, since IPv6 GEO information must be
ignored by legacy destination nodes, encoding as a Destination Option
is indicated. Further investigation and community input may indicate
that a new extension header type is instead warranted. In either
case, future versions of this document will adopt the encoding
approach indicated by community consensus.
2. Terminology
The following terms are defined within the scope of this document:
IPv6 Geolocation (IPv6 GEO)
a means for identifying the location of the source of an IPv6
packet based on geographical coordinates, altitude, timestamp and/
or other information conveyed from the source to the
destination(s).
3. Requirements
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 [RFC2119]. When used
in lower case (e.g., must, must not, etc.), these words MUST NOT be
Skeen & Templin Expires January 3, 2015 [Page 3]
Internet-Draft IPv6 GEO July 2014
interpreted as described in [RFC2119], but are rather interpreted as
they would be in common English.
4. Motivation and Applicability
Traditionally, a given source node will include a set of identifying
criteria that can be used to help determine the relative location of
that node on the network. Such criteria include, but are not limited
to, IP address, Ethernet, 802.11 or Bluetooth MAC addresses, Wifi and
RFID tags, or other user-defined variables that may be specific to a
given implementation. However, these variables are often unreliable
in determining the physical location of a source node as modern
networks are typically implemented with a logical "layer 2" structure
without emphasis on the node's physical location. Furthermore,
variables such as IP address and Wifi RFID tags are commonly defined
by a network administrator and are subject to the implementation
criteria of a given network, and therefore are susceptible to error
in identifying the location of a given node since there is no common
mechanism for linking these criteria to a given physical location.
In addition, the proliferation of portable and handheld mobile
devices makes it increasingly likely that nodes will at some point
change the point of attachment to a given network and will need to be
identified and likely authenticated against a set of reliable
location-based criteria.
In the absence of location-based authentication criteria, a host will
typically be configured to require either local parameters, i.e.,
username and password, or a strong "two-factor" authentication
mechanism, or both. Whereas the merit and applicability of these
methods is outside the scope of this document, some implementations
require an additional layer of authentication control based on the
physical location of a given source node. As a result, a means for
identifying the location of the source node based on the geographical
coordinates, altitude, timestamp and/or other information is needed.
Numerous use cases can be identified for location-based
authentication control that would require the source node to provide
its current location to one or more destination node(s). The source
node to be geolocated can be defined as any IPv6 GEO node capable of
encoding the geolocation data within the IPv6 Destination Options
header; for example, a remote corporate user, a ground soldier, or an
unmanned aerial vehicle, to name a few. The destination node can be
any IPv6 node that can interpret the IPv6 GEO encoded data contained
in the Destination Options header; for example, an authentication
server responsible for deriving the geolocation criteria received
from the source node and authenticating it against a location-based
access policy.
Skeen & Templin Expires January 3, 2015 [Page 4]
Internet-Draft IPv6 GEO July 2014
Potential use cases for IPv6 GEO include:
o A remote corporate user that requires an encrypted tunnel
connection to a corporate VPN server. In addition to a two-factor
authentication request, an IPv6 source node using IPv6 GEO would
also encode its geolocation data into the authentication request
to be sent to the corporate VPN server. The corporate VPN server
would authenticate the specified location of the source node to
the corporate policy that includes the list of approved locations
for the source node on the corporate authentication server in
order to accept the connection request.
o An expeditionary team may want to relay geolocation data to a
mission control center in order to provide emergency response
coordinates, humanitarian support vectors, new terrain
characteristics, or as a means to coordinate the search of a large
geographic region. Further, a method to authenticate the control
messages sent from the expedition team leader to the control
center may require that the geolocation authenticity of the
messages be verified
o A first responder may require a rapidly deployable means of
providing geolocation data to emergency teams engaged in rescuing
lost or injured personnel or in coordinating the location of
support personnel conducting a search over wide geographic areas.
The ability to provide location awareness could provides the
critical communication needed to reduce the time to contact in
life-threatening emergency situations.
o Civil aviation Air Traffic Management (ATM) systems require a
means for tracking the location of aircraft in their various
phases of flight (both on the ground and in the sky). As ATM
becomes increasingly dependent on data communications, the ability
to associate an aircraft's location with its communications
messaging can augment and in some instances replace legacy
mechanisms.
o Unmanned Air Systems (UAS) are envisioned in a wide variety of use
cases. IPv6 GEO information sharing for both ground control and
UAS-to-UAS communications will naturally result in more effective
fleet coordination and tracking.
o Space exploration vehicles must be tracked by control stations and
other vehicles throughout all mission phases. Especially for deep
space applications, an extraterrestrial location coordinate system
may be needed.
Skeen & Templin Expires January 3, 2015 [Page 5]
Internet-Draft IPv6 GEO July 2014
o Convergence of dynamic routing protocols in a wide variety of
mobile networks can benefit greatly from knowledge of the
geographical locations of prospective neighbors. This information
is best conveyed in the headers of IPv6 packets used for routing
protocol control message exchanges
In these cases, the actual implementation of a geolocation
authentication mechanism is considered outside the scope of this
document. This document seeks to specify a method for including the
geolocation data in the IPv6 Destination Options header in order for
it to be utilized in the manner specified by a set of given
implementation criteria.
5. IPv6 GEO Specification
5.1. IPv6 GEO Destination Option Format
The IPv6 GEO "Type 0" Destination Option is formatted as shown in
Figure 1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GEO Type | Reserved|T|A|L| LAT/LON Integer Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAT Fraction Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LON Fraction Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (bits 0-31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (bits 32-63) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp (sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp (usec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 GEO Type 0 Destination Option Format
The fields of the option are defined as follows:
Option Type (8)
the IPv6 Option Type code for IPv6 GEO; to be assigned by IANA.
The high order three bits of the Option Type encode the value
'000' to indicate that the option is to be skipped over if not
Skeen & Templin Expires January 3, 2015 [Page 6]
Internet-Draft IPv6 GEO July 2014
recognized, and that the data must not change en route (see:
Section 4.2 of [RFC2460]).
Opt Data Len (8)
the length of the data portion of the IPv6 GEO Option.
GEO Type (8)
the IPv6 GEO encoding type; set to 0 for the encapsulation format
specified in this section.
Flags (8)
an 8-bit flags field. Contains a 5-bit Reserved field that is set
to 0 on transmission and ignored on reception. The following
three bits (T, A, L) are set to 1 if the corresponding GEO
information fields are included and set to 0 otherwise.
LAT/LON Integer Part (16)
a 16 bit field that encodes the integer part of the Latitude and
Longitude coordinates (see below). Included when 'L' is 1 and
omitted when 'L' is 0.
LAT Fraction Part (32)
a 32 bit field that encodes the fractional part of the Latitude
coordinate (see below). Included when 'L' is 1 and omitted when
'L' is 0.
LON Fractional Part (32)
a 32 bit field that encodes the fractional part of the Longitude
coordinate (see below). Included when 'L' is 1 and omitted when
'L' is 0.
Altitude (64)
two 32-bit fields that together encode the altitude (in
centimeters). Included when 'A' is 1 and omitted when 'A' is 0.
Time Stamp (sec) (32)
a 32 bit field that encodes the time that the IPv6 GEO data was
generated in seconds since the epoch (00:00:00 UTC on 1 January
1970). Included when 'T' is 1 and omitted when 'T' is 0.
Time Stamp (usec) (32)
a 32 bit field that encodes the microseconds at the time that the
IPv6 GEO data was generated. Included when 'T' is 1 and omitted
when 'T' is 0.
In the language of Section 4.2 of [RFC2460], the option has alignment
requirement '4n+2' when the 'L' flag is set and '4n' when the 'L'
Skeen & Templin Expires January 3, 2015 [Page 7]
Internet-Draft IPv6 GEO July 2014
flag is clear. Future specifications may include new IPv6 GEO types
to encode alternate formats.
5.2. IPv6 GEO Option Encoding Algorithm
The Latitude (LAT) and Longitude (LON) coordinate values are treated
as floating point numbers with 10^-10 precision. LAT values range
from 0 at the equator to +90 northward and -90 southward. LON values
range from 0 at the IERS Reference Meridian [WGS-84] to +180 eastward
and -180 westward. The LAT/LON coordinates are then encoded as
follows:
LAT/LON Integer Part = int(LAT+90)*360 + int(LON+180)
LAT Fraction Part = fra(LAT)*1,000,000,000
LON Fraction Part = fra(LON)*1,000,000,000
where "int()" returns the integer part of the floating point number
and "fra()" returns the fractional part of the floating point number.
This encoding scheme is similar to one proposed in "Efficient WGS84
(aka GPS) coordinates compression" [WGS-ENCODE].
5.3. IPv6 Node Requirements
IPv6 source hosts MAY insert the IPv6 GEO destination option in any
IPv6 packets they send to IPv6 destinations (unicast, multicast or
anycast). If the host inserts the IPv6 GEO destination option, it
MUST construct the option using the format specified in Section 5.1
and using the encoding algorithm specified in Section 5.2. The host
MUST further ensure that the geolocation information encoded in the
option is current and accurate.
IPv6 destinations that do not recognize the IPv6 GEO destination
option MUST ignore it and continue to process the IPv6 destination
options extension header as though the IPv6 GEO option were not
present.
6. IANA Considerations
IANA is requested to allocate an IPv6 Option number for the IPv6 GEO
Option in the "Destination Options and Hop-by-Hop Options" registry.
7. Security Considerations
Packets with IPv6 GEO options that are sent in the clear without
encryption risk exposure of sensitive information to unauthorized
Skeen & Templin Expires January 3, 2015 [Page 8]
Internet-Draft IPv6 GEO July 2014
eavesdroppers. When location privacy is desired, Internet security
protocols and/or link layer security SHOULD be used.
A spoofing attack is exposed when a source includes forged IPv6 GEO
information that is incorrect for its current location and/or time.
Destinations SHOULD therefore authenticate the source of IPv6 packets
before accepting any IPv6 GEO information they may include.
User agents MUST NOT send geolocation information to unauthorized
correspondents (e.g., Web sites, etc.) without the express permission
of the user.
8. Related Work in the IETF
The IETF GEOPRIV working group is chartered to "continue to develop
and refine representations of location in Internet protocols, and to
analyze the authorization, integrity, and privacy requirements that
must be met when these representations of location are created,
stored, and used". However, the group is located within the Real-
time Applications and Infrastructure area, and as such it is not
clear whether the Internet layer approach proposed in this document
would fit within the area focus. The GEOPRIV working group has
published a BCP on "An Architecture for Location and Location Privacy
in Internet Applications" [RFC6280].
A BoF on "Internet-wide Geo-Networking (geonet)" was held at IETF88
in November 2013. A Problem Statement related to the BoF states
that: "Internet-based applications use IP addresses to address a node
that can be a host, a server or a router. Scenarios and use cases
exist where nodes are being addressed using their geographical
location instead of their IP address"
[I-D.karagiannis-problem-statement-geonetworking]. This BoF was held
within the Internet area and concerns geolocation at the Internet
layer.
9. Implementation Status
A prototype implementation has been developed and tested, but not yet
available for public release. The prototype implementation uses the
Option Type value reserved for experimentation [RFC3692].
10. Contributers
The authors greatly appreciate the efforts of Jin Fang, who jointly
developed the IPv6 GEO message format and was the primary author of
the prototype implementation. We wish Jin the best of success in his
future endeavors.
Skeen & Templin Expires January 3, 2015 [Page 9]
Internet-Draft IPv6 GEO July 2014
11. Acknowledgments
The following individuals are acknowledged for helpful comments and
suggestions: Jeff Ahrenholz, Kerry Hu.
12. References
12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012.
12.2. Informative References
[I-D.karagiannis-problem-statement-geonetworking]
Karagiannis, G., Heijenk, G., Festag, A., Petrescu, A.,
and A. Chaiken, "Internet-wide Geo-networking Problem
Statement", draft-karagiannis-problem-statement-
geonetworking-01 (work in progress), November 2013.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011.
[WGS-84] Wikipedia, W., "World Geodetic System
(http://en.wikipedia.org/wiki/World_Geodetic_System)",
November 2013.
[WGS-ENCODE]
Dupuis, L., "Efficient WGS84 (aka GPS) Coordinates
Compression (http://www.dupuis.me/node/35)", August 2013.
Skeen & Templin Expires January 3, 2015 [Page 10]
Internet-Draft IPv6 GEO July 2014
Authors' Addresses
Brian Skeen
Boeing Phantom Works
P.O. Box 3707
Seattle, WA 98124
USA
Email: brian.l.skeen@boeing.com
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Skeen & Templin Expires January 3, 2015 [Page 11]