idnits 2.17.1 draft-skeen-6man-ipv6geo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Skeen 3 Internet-Draft Boeing Phantom Works 4 Intended status: Standards Track F. Templin, Ed. 5 Expires: January 3, 2015 Boeing Research & Technology 6 July 2, 2014 8 Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO) 9 draft-skeen-6man-ipv6geo-00.txt 11 Abstract 13 This document provides a specification for including geolocation 14 information in the headers of IPv6 packets (IPv6 GEO). The 15 information is intended to be included in packets for which the 16 location of the source node is to be conveyed to the destination node 17 or nodes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 3, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Motivation and Applicability . . . . . . . . . . . . . . . . 4 57 5. IPv6 GEO Specification . . . . . . . . . . . . . . . . . . . 6 58 5.1. IPv6 GEO Destination Option Format . . . . . . . . . . . 6 59 5.2. IPv6 GEO Option Encoding Algorithm . . . . . . . . . . . 8 60 5.3. IPv6 Node Requirements . . . . . . . . . . . . . . . . . 8 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8. Related Work in the IETF . . . . . . . . . . . . . . . . . . 9 64 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 65 10. Contributers . . . . . . . . . . . . . . . . . . . . . . . . 9 66 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 12.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 Internet Protocol, version 4 (IPv4) [RFC0791] provides limited 75 capabilities for including additional information in the headers of 76 packets. The maximum IPv4 header length is 60 bytes including any IP 77 options, and options are not widely used due to incompatibilities 78 with network middleboxes. On the other hand, Internet Protocol, 79 version 6 (IPv6) [RFC2460] includes an extensible header format 80 whereby additional information can be inserted between the IPv6 81 header and the transport layer header. These extensions can be 82 included on a per-packet basis, and not necessarily for all packets 83 of the same flow. This document specifies a format for including 84 geolocation information within the headers of individual IPv6 packets 85 (IPv6 GEO). 87 IPv6 GEO information is included at the discretion of source nodes 88 for the benefit of destination nodes and/or network elements that may 89 need to examine the headers of packets in flight. Legacy destination 90 nodes that do not recognize the IPv6 GEO information must ignore it 91 and process the rest of the packet as if it were not present. The 92 IPv6 specification defines several extension header types, including 93 the Destination Options header. Section 4.6 of [RFC2460] describes 94 conditions under which new information should be encoded as either a 95 new extension header or as a new destination option: 97 "Note that there are two possible ways to encode optional 98 destination information in an IPv6 packet: either as an option in 99 the Destination Options header, or as a separate extension header. 100 The Fragment header and the Authentication header are examples of 101 the latter approach. Which approach can be used depends on what 102 action is desired of a destination node that does not understand 103 the optional information:" 105 Section 3 of [RFC6564] further states that: 107 "The base IPv6 standard [RFC2460] allows the use of both extension 108 headers and destination options in order to encode optional 109 destination information in an IPv6 packet. The use of destination 110 options to encode this information provides more flexible handling 111 characteristics and better backward compatibility than using 112 extension headers. Because of this, implementations SHOULD use 113 destination options as the preferred mechanism for encoding 114 optional destination information, and use a new extension header 115 only if destination options do not satisfy their needs. The 116 request for creation of a new IPv6 extension header MUST be 117 accompanied by a specific explanation of why destination options 118 could not be used to convey this information." 120 Our first interpretation of this guidance and the supporting text 121 that follows suggests that, since IPv6 GEO information must be 122 ignored by legacy destination nodes, encoding as a Destination Option 123 is indicated. Further investigation and community input may indicate 124 that a new extension header type is instead warranted. In either 125 case, future versions of this document will adopt the encoding 126 approach indicated by community consensus. 128 2. Terminology 130 The following terms are defined within the scope of this document: 132 IPv6 Geolocation (IPv6 GEO) 133 a means for identifying the location of the source of an IPv6 134 packet based on geographical coordinates, altitude, timestamp and/ 135 or other information conveyed from the source to the 136 destination(s). 138 3. Requirements 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. When used 143 in lower case (e.g., must, must not, etc.), these words MUST NOT be 144 interpreted as described in [RFC2119], but are rather interpreted as 145 they would be in common English. 147 4. Motivation and Applicability 149 Traditionally, a given source node will include a set of identifying 150 criteria that can be used to help determine the relative location of 151 that node on the network. Such criteria include, but are not limited 152 to, IP address, Ethernet, 802.11 or Bluetooth MAC addresses, Wifi and 153 RFID tags, or other user-defined variables that may be specific to a 154 given implementation. However, these variables are often unreliable 155 in determining the physical location of a source node as modern 156 networks are typically implemented with a logical "layer 2" structure 157 without emphasis on the node's physical location. Furthermore, 158 variables such as IP address and Wifi RFID tags are commonly defined 159 by a network administrator and are subject to the implementation 160 criteria of a given network, and therefore are susceptible to error 161 in identifying the location of a given node since there is no common 162 mechanism for linking these criteria to a given physical location. 163 In addition, the proliferation of portable and handheld mobile 164 devices makes it increasingly likely that nodes will at some point 165 change the point of attachment to a given network and will need to be 166 identified and likely authenticated against a set of reliable 167 location-based criteria. 169 In the absence of location-based authentication criteria, a host will 170 typically be configured to require either local parameters, i.e., 171 username and password, or a strong "two-factor" authentication 172 mechanism, or both. Whereas the merit and applicability of these 173 methods is outside the scope of this document, some implementations 174 require an additional layer of authentication control based on the 175 physical location of a given source node. As a result, a means for 176 identifying the location of the source node based on the geographical 177 coordinates, altitude, timestamp and/or other information is needed. 179 Numerous use cases can be identified for location-based 180 authentication control that would require the source node to provide 181 its current location to one or more destination node(s). The source 182 node to be geolocated can be defined as any IPv6 GEO node capable of 183 encoding the geolocation data within the IPv6 Destination Options 184 header; for example, a remote corporate user, a ground soldier, or an 185 unmanned aerial vehicle, to name a few. The destination node can be 186 any IPv6 node that can interpret the IPv6 GEO encoded data contained 187 in the Destination Options header; for example, an authentication 188 server responsible for deriving the geolocation criteria received 189 from the source node and authenticating it against a location-based 190 access policy. 192 Potential use cases for IPv6 GEO include: 194 o A remote corporate user that requires an encrypted tunnel 195 connection to a corporate VPN server. In addition to a two-factor 196 authentication request, an IPv6 source node using IPv6 GEO would 197 also encode its geolocation data into the authentication request 198 to be sent to the corporate VPN server. The corporate VPN server 199 would authenticate the specified location of the source node to 200 the corporate policy that includes the list of approved locations 201 for the source node on the corporate authentication server in 202 order to accept the connection request. 204 o An expeditionary team may want to relay geolocation data to a 205 mission control center in order to provide emergency response 206 coordinates, humanitarian support vectors, new terrain 207 characteristics, or as a means to coordinate the search of a large 208 geographic region. Further, a method to authenticate the control 209 messages sent from the expedition team leader to the control 210 center may require that the geolocation authenticity of the 211 messages be verified 213 o A first responder may require a rapidly deployable means of 214 providing geolocation data to emergency teams engaged in rescuing 215 lost or injured personnel or in coordinating the location of 216 support personnel conducting a search over wide geographic areas. 217 The ability to provide location awareness could provides the 218 critical communication needed to reduce the time to contact in 219 life-threatening emergency situations. 221 o Civil aviation Air Traffic Management (ATM) systems require a 222 means for tracking the location of aircraft in their various 223 phases of flight (both on the ground and in the sky). As ATM 224 becomes increasingly dependent on data communications, the ability 225 to associate an aircraft's location with its communications 226 messaging can augment and in some instances replace legacy 227 mechanisms. 229 o Unmanned Air Systems (UAS) are envisioned in a wide variety of use 230 cases. IPv6 GEO information sharing for both ground control and 231 UAS-to-UAS communications will naturally result in more effective 232 fleet coordination and tracking. 234 o Space exploration vehicles must be tracked by control stations and 235 other vehicles throughout all mission phases. Especially for deep 236 space applications, an extraterrestrial location coordinate system 237 may be needed. 239 o Convergence of dynamic routing protocols in a wide variety of 240 mobile networks can benefit greatly from knowledge of the 241 geographical locations of prospective neighbors. This information 242 is best conveyed in the headers of IPv6 packets used for routing 243 protocol control message exchanges 245 In these cases, the actual implementation of a geolocation 246 authentication mechanism is considered outside the scope of this 247 document. This document seeks to specify a method for including the 248 geolocation data in the IPv6 Destination Options header in order for 249 it to be utilized in the manner specified by a set of given 250 implementation criteria. 252 5. IPv6 GEO Specification 254 5.1. IPv6 GEO Destination Option Format 256 The IPv6 GEO "Type 0" Destination Option is formatted as shown in 257 Figure 1: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Option Type | Opt Data Len | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | GEO Type | Reserved|T|A|L| LAT/LON Integer Part | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | LAT Fraction Part | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | LON Fraction Part | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Altitude (bits 0-31) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Altitude (bits 32-63) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Time Stamp (sec) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Time Stamp (usec) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 1: IPv6 GEO Type 0 Destination Option Format 281 The fields of the option are defined as follows: 283 Option Type (8) 284 the IPv6 Option Type code for IPv6 GEO; to be assigned by IANA. 285 The high order three bits of the Option Type encode the value 286 '000' to indicate that the option is to be skipped over if not 287 recognized, and that the data must not change en route (see: 288 Section 4.2 of [RFC2460]). 290 Opt Data Len (8) 291 the length of the data portion of the IPv6 GEO Option. 293 GEO Type (8) 294 the IPv6 GEO encoding type; set to 0 for the encapsulation format 295 specified in this section. 297 Flags (8) 298 an 8-bit flags field. Contains a 5-bit Reserved field that is set 299 to 0 on transmission and ignored on reception. The following 300 three bits (T, A, L) are set to 1 if the corresponding GEO 301 information fields are included and set to 0 otherwise. 303 LAT/LON Integer Part (16) 304 a 16 bit field that encodes the integer part of the Latitude and 305 Longitude coordinates (see below). Included when 'L' is 1 and 306 omitted when 'L' is 0. 308 LAT Fraction Part (32) 309 a 32 bit field that encodes the fractional part of the Latitude 310 coordinate (see below). Included when 'L' is 1 and omitted when 311 'L' is 0. 313 LON Fractional Part (32) 314 a 32 bit field that encodes the fractional part of the Longitude 315 coordinate (see below). Included when 'L' is 1 and omitted when 316 'L' is 0. 318 Altitude (64) 319 two 32-bit fields that together encode the altitude (in 320 centimeters). Included when 'A' is 1 and omitted when 'A' is 0. 322 Time Stamp (sec) (32) 323 a 32 bit field that encodes the time that the IPv6 GEO data was 324 generated in seconds since the epoch (00:00:00 UTC on 1 January 325 1970). Included when 'T' is 1 and omitted when 'T' is 0. 327 Time Stamp (usec) (32) 328 a 32 bit field that encodes the microseconds at the time that the 329 IPv6 GEO data was generated. Included when 'T' is 1 and omitted 330 when 'T' is 0. 332 In the language of Section 4.2 of [RFC2460], the option has alignment 333 requirement '4n+2' when the 'L' flag is set and '4n' when the 'L' 334 flag is clear. Future specifications may include new IPv6 GEO types 335 to encode alternate formats. 337 5.2. IPv6 GEO Option Encoding Algorithm 339 The Latitude (LAT) and Longitude (LON) coordinate values are treated 340 as floating point numbers with 10^-10 precision. LAT values range 341 from 0 at the equator to +90 northward and -90 southward. LON values 342 range from 0 at the IERS Reference Meridian [WGS-84] to +180 eastward 343 and -180 westward. The LAT/LON coordinates are then encoded as 344 follows: 346 LAT/LON Integer Part = int(LAT+90)*360 + int(LON+180) 348 LAT Fraction Part = fra(LAT)*1,000,000,000 350 LON Fraction Part = fra(LON)*1,000,000,000 352 where "int()" returns the integer part of the floating point number 353 and "fra()" returns the fractional part of the floating point number. 354 This encoding scheme is similar to one proposed in "Efficient WGS84 355 (aka GPS) coordinates compression" [WGS-ENCODE]. 357 5.3. IPv6 Node Requirements 359 IPv6 source hosts MAY insert the IPv6 GEO destination option in any 360 IPv6 packets they send to IPv6 destinations (unicast, multicast or 361 anycast). If the host inserts the IPv6 GEO destination option, it 362 MUST construct the option using the format specified in Section 5.1 363 and using the encoding algorithm specified in Section 5.2. The host 364 MUST further ensure that the geolocation information encoded in the 365 option is current and accurate. 367 IPv6 destinations that do not recognize the IPv6 GEO destination 368 option MUST ignore it and continue to process the IPv6 destination 369 options extension header as though the IPv6 GEO option were not 370 present. 372 6. IANA Considerations 374 IANA is requested to allocate an IPv6 Option number for the IPv6 GEO 375 Option in the "Destination Options and Hop-by-Hop Options" registry. 377 7. Security Considerations 379 Packets with IPv6 GEO options that are sent in the clear without 380 encryption risk exposure of sensitive information to unauthorized 381 eavesdroppers. When location privacy is desired, Internet security 382 protocols and/or link layer security SHOULD be used. 384 A spoofing attack is exposed when a source includes forged IPv6 GEO 385 information that is incorrect for its current location and/or time. 386 Destinations SHOULD therefore authenticate the source of IPv6 packets 387 before accepting any IPv6 GEO information they may include. 389 User agents MUST NOT send geolocation information to unauthorized 390 correspondents (e.g., Web sites, etc.) without the express permission 391 of the user. 393 8. Related Work in the IETF 395 The IETF GEOPRIV working group is chartered to "continue to develop 396 and refine representations of location in Internet protocols, and to 397 analyze the authorization, integrity, and privacy requirements that 398 must be met when these representations of location are created, 399 stored, and used". However, the group is located within the Real- 400 time Applications and Infrastructure area, and as such it is not 401 clear whether the Internet layer approach proposed in this document 402 would fit within the area focus. The GEOPRIV working group has 403 published a BCP on "An Architecture for Location and Location Privacy 404 in Internet Applications" [RFC6280]. 406 A BoF on "Internet-wide Geo-Networking (geonet)" was held at IETF88 407 in November 2013. A Problem Statement related to the BoF states 408 that: "Internet-based applications use IP addresses to address a node 409 that can be a host, a server or a router. Scenarios and use cases 410 exist where nodes are being addressed using their geographical 411 location instead of their IP address" 412 [I-D.karagiannis-problem-statement-geonetworking]. This BoF was held 413 within the Internet area and concerns geolocation at the Internet 414 layer. 416 9. Implementation Status 418 A prototype implementation has been developed and tested, but not yet 419 available for public release. The prototype implementation uses the 420 Option Type value reserved for experimentation [RFC3692]. 422 10. Contributers 424 The authors greatly appreciate the efforts of Jin Fang, who jointly 425 developed the IPv6 GEO message format and was the primary author of 426 the prototype implementation. We wish Jin the best of success in his 427 future endeavors. 429 11. Acknowledgments 431 The following individuals are acknowledged for helpful comments and 432 suggestions: Jeff Ahrenholz, Kerry Hu. 434 12. References 436 12.1. Normative References 438 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 439 1981. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 445 (IPv6) Specification", RFC 2460, December 1998. 447 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 448 Considered Useful", BCP 82, RFC 3692, January 2004. 450 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 451 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 452 RFC 6564, April 2012. 454 12.2. Informative References 456 [I-D.karagiannis-problem-statement-geonetworking] 457 Karagiannis, G., Heijenk, G., Festag, A., Petrescu, A., 458 and A. Chaiken, "Internet-wide Geo-networking Problem 459 Statement", draft-karagiannis-problem-statement- 460 geonetworking-01 (work in progress), November 2013. 462 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 463 Tschofenig, H., and H. Schulzrinne, "An Architecture for 464 Location and Location Privacy in Internet Applications", 465 BCP 160, RFC 6280, July 2011. 467 [WGS-84] Wikipedia, W., "World Geodetic System 468 (http://en.wikipedia.org/wiki/World_Geodetic_System)", 469 November 2013. 471 [WGS-ENCODE] 472 Dupuis, L., "Efficient WGS84 (aka GPS) Coordinates 473 Compression (http://www.dupuis.me/node/35)", August 2013. 475 Authors' Addresses 477 Brian Skeen 478 Boeing Phantom Works 479 P.O. Box 3707 480 Seattle, WA 98124 481 USA 483 Email: brian.l.skeen@boeing.com 485 Fred L. Templin (editor) 486 Boeing Research & Technology 487 P.O. Box 3707 488 Seattle, WA 98124 489 USA 491 Email: fltemplin@acm.org