Network Working Group                                           B. Skeen
Internet-Draft                                      Boeing Phantom Works
Intended status: Standards Track                                 E. King
Expires: March 12, 2015                                   Boeing EO&T IT
                                                         F. Templin, Ed.
                                            Boeing Research & Technology
                                                      September 08, 2014

  Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO)


   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 via the network 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

   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 March 12, 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
   ( 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

Skeen, et al.            Expires March 12, 2015                 [Page 1]

Internet-Draft                  IPv6 GEO                  September 2014

   include Simplified BSD License text as described in Section 4.e of
   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  . . . . . . . . . . . . . . . . . . . . . . . .   4
   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  . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Related Work in the IETF  . . . . . . . . . . . . . . . . . .   9
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  10
   10. Contributers  . . . . . . . . . . . . . . . . . . . . . . . .  10
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     12.2.  Informative References . . . . . . . . . . . . . . . . .  11
   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 transit.  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

Skeen, et al.            Expires March 12, 2015                 [Page 2]

Internet-Draft                  IPv6 GEO                  September 2014

   encoded as either a new extension header or as a new destination

      "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

Skeen, et al.            Expires March 12, 2015                 [Page 3]

Internet-Draft                  IPv6 GEO                  September 2014

3.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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
   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 MAC addresses, 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 associating 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, an airplane, a remote corporate user, a ground
   soldier, or an unmanned aerial vehicle, to name a few.  The

Skeen, et al.            Expires March 12, 2015                 [Page 4]

Internet-Draft                  IPv6 GEO                  September 2014

   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.

   Potential use cases for IPv6 GEO include:

   o  A remote corporate user that requires an encrypted tunnel
      connection to a corporate VPN server must provide authentic
      location information.  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 provide 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 mechanisms
      such as Automatic Dependent Surveillance - Broadcast (ADS-B).

   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.

Skeen, et al.            Expires March 12, 2015                 [Page 5]

Internet-Draft                  IPv6 GEO                  September 2014

   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.

   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.

   o  The networks that make up the greater "Internet," including all
      various forms of Intranets (Enterprises, small businesses, Service
      Providers, etc...) all need to manage those assets that constitute
      their administrative domain.  Sometimes these networks are
      millions of dollars and all of the time are critical to business
      value.  Being able to locate and place where these devices are
      located mean actual dollar value to the businesses bottom line
      because of various tax and depreciation details that are variable,
      depending on which taxing authority these devious are located
      (City, State (Province), Country or any other various taxing
      authority in which the business provides value with those assets.
      Having a clear location, at any time has distinct advantages to
      the business as to where exactly those devices are, at any one

   In these cases, the actual implementation of a geolocation
   authentication layer in a multi-layered security scheme 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.

   In the final analysis, if a subject node that willingly submits
   itself for surveillance sends only a single IPv6 packet or fragment
   before falling silent, then any tracking node(s) should be able to
   determine where the packet came from.

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:

Skeen, et al.            Expires March 12, 2015                 [Page 6]

Internet-Draft                  IPv6 GEO                  September 2014

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

Skeen, et al.            Expires March 12, 2015                 [Page 7]

Internet-Draft                  IPv6 GEO                  September 2014

   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'
   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

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

Skeen, et al.            Expires March 12, 2015                 [Page 8]

Internet-Draft                  IPv6 GEO                  September 2014

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).  Any IPv6 packet is eligible, including a minimal packet
   that includes only an (extended) IPv6 header with the value "No Next
   Header" in the final "Next Header" field.

   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

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
   eavesdroppers.  When location privacy is desired, Internet security
   protocols (e.g., IPsec [RFC4301], etc.) and/or link layer security
   SHOULD be used to ensure confidentiality.

   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-

Skeen, et al.            Expires March 12, 2015                 [Page 9]

Internet-Draft                  IPv6 GEO                  September 2014

   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

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.

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

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

Skeen, et al.            Expires March 12, 2015                [Page 10]

Internet-Draft                  IPv6 GEO                  September 2014

   [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

              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.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [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
              November 2013.

              Dupuis, L., "Efficient WGS84 (aka GPS) Coordinates
              Compression (", August 2013.

Authors' Addresses

   Brian Skeen
   Boeing Phantom Works
   P.O. Box 3707
   Seattle, WA  98124


Skeen, et al.            Expires March 12, 2015                [Page 11]

Internet-Draft                  IPv6 GEO                  September 2014

   Edwin King
   Boeing EO&T IT
   P.O. Box 3707
   Seattle, WA  98124


   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124


Skeen, et al.            Expires March 12, 2015                [Page 12]