idnits 2.17.1 draft-skeen-6man-ipv6geo-03.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 (October 31, 2016) is 2733 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) == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 E. King 5 Expires: May 4, 2017 Boeing EO&T IT 6 F. Templin, Ed. 7 Boeing Research & Technology 8 October 31, 2016 10 Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO) 11 draft-skeen-6man-ipv6geo-03.txt 13 Abstract 15 This document provides a specification for including geolocation 16 information in the headers of IPv6 packets (IPv6 GEO). The 17 information is intended to be included in packets for which the 18 location of the source node is to be conveyed via the network to the 19 destination node or nodes. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 4, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Motivation and Applicability . . . . . . . . . . . . . . . . 4 59 5. IPv6 GEO Specification . . . . . . . . . . . . . . . . . . . 7 60 5.1. IPv6 GEO Destination Option Format . . . . . . . . . . . 7 61 5.2. IPv6 GEO Option Encoding Algorithm . . . . . . . . . . . 9 62 5.3. IPv6 Node Requirements . . . . . . . . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. Related Work in the IETF . . . . . . . . . . . . . . . . . . 10 66 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 67 10. Contributers . . . . . . . . . . . . . . . . . . . . . . . . 11 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 12.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Internet Protocol, version 4 (IPv4) [RFC0791] provides limited 77 capabilities for including additional information in the headers of 78 packets. The maximum IPv4 header length is 60 bytes including any IP 79 options, and options are not widely used due to incompatibilities 80 with network middleboxes. On the other hand, Internet Protocol, 81 version 6 (IPv6) [RFC2460] includes an extensible header format 82 whereby additional information can be inserted between the IPv6 83 header and the transport layer header. These extensions can be 84 included on a per-packet basis, and not necessarily for all packets 85 of the same flow. This document specifies a format for including 86 geolocation information within the headers of individual IPv6 packets 87 (IPv6 GEO). 89 IPv6 GEO information is included at the discretion of source nodes 90 for the benefit of destination nodes and/or network elements that may 91 need to examine the headers of packets in transit. Legacy 92 destination nodes that do not recognize the IPv6 GEO information must 93 ignore it and process the rest of the packet as if it were not 94 present. The IPv6 specification defines several extension header 95 types, including the Destination Options header. Section 4.6 of 96 [RFC2460] describes conditions under which new information should be 97 encoded as either a new extension header or as a new destination 98 option: 100 "Note that there are two possible ways to encode optional 101 destination information in an IPv6 packet: either as an option in 102 the Destination Options header, or as a separate extension header. 103 The Fragment header and the Authentication header are examples of 104 the latter approach. Which approach can be used depends on what 105 action is desired of a destination node that does not understand 106 the optional information:" 108 Section 3 of [RFC6564] further states that: 110 "The base IPv6 standard [RFC2460] allows the use of both extension 111 headers and destination options in order to encode optional 112 destination information in an IPv6 packet. The use of destination 113 options to encode this information provides more flexible handling 114 characteristics and better backward compatibility than using 115 extension headers. Because of this, implementations SHOULD use 116 destination options as the preferred mechanism for encoding 117 optional destination information, and use a new extension header 118 only if destination options do not satisfy their needs. The 119 request for creation of a new IPv6 extension header MUST be 120 accompanied by a specific explanation of why destination options 121 could not be used to convey this information." 123 Our first interpretation of this guidance and the supporting text 124 that follows suggests that, since IPv6 GEO information must be 125 ignored by legacy destination nodes, encoding as a Destination Option 126 is indicated. Further investigation and community input may indicate 127 that a new extension header type is instead warranted. In either 128 case, future versions of this document will adopt the encoding 129 approach indicated by community consensus. 131 2. Terminology 133 The following terms are defined within the scope of this document: 135 IPv6 Geolocation (IPv6 GEO) 136 a means for identifying the location of the source of an IPv6 137 packet based on geographical coordinates, altitude, timestamp and/ 138 or other information conveyed from the source to the 139 destination(s). 141 3. Requirements 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. When used 146 in lower case (e.g., must, must not, etc.), these words MUST NOT be 147 interpreted as described in [RFC2119], but are rather interpreted as 148 they would be in common English. 150 IPv6 forwarding nodes must not discard packets that include the 151 destination options specified herein unless by explicit 152 administrative policy. General forwarding considerations for packets 153 that contain IPv6 options are discussed in 154 [I-D.ietf-opsec-ipv6-eh-filtering]. 156 4. Motivation and Applicability 158 Traditionally, a given source node will include a set of identifying 159 criteria that can be used to help determine the relative location of 160 that node on the network. Such criteria include, but are not limited 161 to, IP address, Ethernet MAC addresses, 802.11 or Bluetooth MAC 162 addresses, Wifi and RFID tags, or other user-defined variables that 163 may be specific to a given implementation. However, these variables 164 are often unreliable in determining the physical location of a source 165 node as modern networks are typically implemented with a logical 166 "layer 2" structure without emphasis on the node's physical location. 167 Furthermore, variables such as IP address and Wifi RFID tags are 168 commonly defined by a network administrator and are subject to the 169 implementation criteria of a given network, and therefore are 170 susceptible to error in identifying the location of a given node 171 since there is no common mechanism for associating these criteria to 172 a given physical location. In addition, the proliferation of 173 portable and handheld mobile devices makes it increasingly likely 174 that nodes will at some point change the point of attachment to a 175 given network and will need to be identified and likely authenticated 176 against a set of reliable location-based criteria. 178 In the absence of location-based authentication criteria, a host will 179 typically be configured to require either local parameters, i.e., 180 username and password, or a strong "two-factor" authentication 181 mechanism, or both. Whereas the merit and applicability of these 182 methods is outside the scope of this document, some implementations 183 require an additional layer of authentication control based on the 184 physical location of a given source node. As a result, a means for 185 identifying the location of the source node based on the geographical 186 coordinates, altitude, timestamp and/or other information is needed. 188 Numerous use cases can be identified for location-based 189 authentication control that would require the source node to provide 190 its current location to one or more destination node(s). The source 191 node to be geolocated can be defined as any IPv6 GEO node capable of 192 encoding the geolocation data within the IPv6 Destination Options 193 header; for example, an airplane, an automobile, a remote corporate 194 user, a ground soldier, or an unmanned aerial vehicle, to name a few. 195 The destination node can be any IPv6 node that can interpret the IPv6 196 GEO encoded data contained in the Destination Options header; for 197 example, an authentication server responsible for deriving the 198 geolocation criteria received from the source node and authenticating 199 it against a location-based access policy. 201 Potential use cases for IPv6 GEO include: 203 o A remote corporate user that requires an encrypted tunnel 204 connection to a corporate VPN server must provide authentic 205 location information. In addition to a two-factor authentication 206 request, an IPv6 source node using IPv6 GEO would also encode its 207 geolocation data into the authentication request to be sent to the 208 corporate VPN server. The corporate VPN server would authenticate 209 the specified location of the source node to the corporate policy 210 that includes the list of approved locations for the source node 211 on the corporate authentication server in order to accept the 212 connection request. 214 o An expeditionary team may want to relay geolocation data to a 215 mission control center in order to provide emergency response 216 coordinates, humanitarian support vectors, new terrain 217 characteristics, or as a means to coordinate the search of a large 218 geographic region. Further, a method to authenticate the control 219 messages sent from the expedition team leader to the control 220 center may require that the geolocation authenticity of the 221 messages be verified 223 o A first responder may require a rapidly deployable means of 224 providing geolocation data to emergency teams engaged in rescuing 225 lost or injured personnel or in coordinating the location of 226 support personnel conducting a search over wide geographic areas. 227 The ability to provide location awareness could provide the 228 critical communication needed to reduce the time to contact in 229 life-threatening emergency situations. 231 o Civil aviation Air Traffic Management (ATM) systems require a 232 means for tracking the location of aircraft in their various 233 phases of flight (both on the ground and in the sky). As ATM 234 becomes increasingly dependent on data communications, the ability 235 to associate an aircraft's location with its communications 236 messaging can augment and in some instances replace mechanisms 237 such as Automatic Dependent Surveillance - Broadcast (ADS-B). 239 o Unmanned Air Systems (UAS) are envisioned in a wide variety of use 240 cases. IPv6 GEO information sharing for both ground control and 241 UAS-to-UAS communications will naturally result in more effective 242 fleet coordination and tracking. 244 o Automobiles and vehicles of all types are increasingly connected 245 to the Internet. Comfort-enhancing entertainment applications, 246 road safety applications using bidirectional data flows, and 247 connected automated driving are but a few new features expected in 248 automobiles to hit the roads from now to year 2020. Vehicle-to- 249 Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) use-cases where 250 IP is well-suited as a networking technology, supporting also 251 applications that involve exchanges of safety-related messages 252 between vehicles and infrastructure if necessary. 254 o Space exploration vehicles must be tracked by control stations and 255 other vehicles throughout all mission phases. Especially for deep 256 space applications, an extraterrestrial location coordinate system 257 may be needed. 259 o Convergence of dynamic routing protocols in a wide variety of 260 mobile networks can benefit greatly from knowledge of the 261 geographical locations of prospective neighbors. This information 262 is best conveyed in the headers of IPv6 packets used for routing 263 protocol control message exchanges. 265 o The networks that make up the greater "Internet," including all 266 various forms of Intranets (Enterprises, small businesses, Service 267 Providers, etc.) all need to manage those assets that constitute 268 their administrative domain. Sometimes these networks are 269 millions of dollars and all of the time are critical to business 270 value. Being able to locate and place where these devices are 271 located may mean actual dollar value to the businesses bottom line 272 because of various tax and depreciation details that are variable, 273 depending on which taxing authority these devices are located 274 (City, State (Province), Country or any other various taxing 275 authority in which the business provides value with those assets. 276 Having a clear location, at any time has distinct advantages to 277 the business as to where exactly those devices are, at any one 278 time. 280 In these cases, the actual implementation of a geolocation 281 authentication layer in a multi-layered security scheme is considered 282 outside the scope of this document. This document seeks to specify a 283 method for including the geolocation data in the IPv6 Destination 284 Options header in order for it to be utilized in the manner specified 285 by a set of given implementation criteria. 287 In the final analysis, if a subject node that willingly submits 288 itself for surveillance sends only a single IPv6 packet or fragment 289 before falling silent, then any tracking node(s) should be able to 290 determine where the packet came from. 292 5. IPv6 GEO Specification 294 5.1. IPv6 GEO Destination Option Format 296 The IPv6 GEO "Type 0" Destination Option is formatted as shown in 297 Figure 1: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Option Type | Opt Data Len | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | GEO Type | Reserved|T|A|L| LAT/LON Integer Part | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | LAT Fraction Part | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | LON Fraction Part | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Altitude (bits 0-31) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Altitude (bits 32-63) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Time Stamp (sec) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Time Stamp (usec) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 1: IPv6 GEO Type 0 Destination Option Format 321 The fields of the option are defined as follows: 323 Option Type (8) 324 the IPv6 Option Type code for IPv6 GEO; to be assigned by IANA. 325 The high order three bits of the Option Type encode the value 326 '000' to indicate that the option is to be skipped over if not 327 recognized, and that the data must not change en route (see: 328 Section 4.2 of [RFC2460]). 330 Opt Data Len (8) 331 the length of the data portion of the IPv6 GEO Option. 333 GEO Type (8) 334 the IPv6 GEO encoding type; set to 0 for the encapsulation format 335 specified in this section. 337 Flags (8) 338 an 8-bit flags field. Contains a 5-bit Reserved field that is set 339 to 0 on transmission and ignored on reception. The following 340 three bits (T, A, L) are set to 1 if the corresponding GEO 341 information fields are included and set to 0 otherwise. 343 LAT/LON Integer Part (16) 344 a 16 bit field that encodes the integer part of the Latitude and 345 Longitude coordinates (see below). Included when 'L' is 1 and 346 omitted when 'L' is 0. 348 LAT Fraction Part (32) 349 a 32 bit field that encodes the fractional part of the Latitude 350 coordinate (see below). Included when 'L' is 1 and omitted when 351 'L' is 0. 353 LON Fractional Part (32) 354 a 32 bit field that encodes the fractional part of the Longitude 355 coordinate (see below). Included when 'L' is 1 and omitted when 356 'L' is 0. 358 Altitude (64) 359 two 32-bit fields that together encode the altitude (in 360 centimeters). Included when 'A' is 1 and omitted when 'A' is 0. 362 Time Stamp (sec) (32) 363 a 32 bit field that encodes the time that the IPv6 GEO data was 364 generated in seconds since the epoch (00:00:00 UTC on 1 January 365 1970). Included when 'T' is 1 and omitted when 'T' is 0. 367 Time Stamp (usec) (32) 368 a 32 bit field that encodes the microseconds at the time that the 369 IPv6 GEO data was generated. Included when 'T' is 1 and omitted 370 when 'T' is 0. 372 In the language of Section 4.2 of [RFC2460], the option has alignment 373 requirement '4n+2' when the 'L' flag is set and '4n' when the 'L' 374 flag is clear. Future specifications may include new IPv6 GEO types 375 to encode alternate formats. 377 5.2. IPv6 GEO Option Encoding Algorithm 379 The Latitude (LAT) and Longitude (LON) coordinate values are treated 380 as floating point numbers with 10^-10 precision. LAT values range 381 from 0 degrees at the equator to +90 degress northward and -90 382 degrees southward. LON values range from 0 degrees at the IERS 383 Reference Meridian [WGS-84] to +180 degrees eastward and -180 degrees 384 westward. The LAT/LON coordinates are then encoded as follows: 386 LAT/LON Integer Part = int(LAT+90)*360 + int(LON+180) 388 LAT Fraction Part = fra(LAT)*1,000,000,000 390 LON Fraction Part = fra(LON)*1,000,000,000 392 where "int()" returns the integer part of the floating point number 393 and "fra()" returns the fractional part of the floating point number. 394 This encoding scheme is similar to one proposed in "Efficient WGS84 395 (aka GPS) coordinates compression" [WGS-ENCODE]. 397 5.3. IPv6 Node Requirements 399 IPv6 source hosts MAY insert the IPv6 GEO destination option in any 400 IPv6 packets they send to IPv6 destinations (unicast, multicast or 401 anycast). Any IPv6 packet is eligible, including a minimal packet 402 that includes only an (extended) IPv6 header with the value "No Next 403 Header" in the final "Next Header" field. 405 If the host inserts the IPv6 GEO destination option, it MUST 406 construct the option using the format specified in Section 5.1 and 407 using the encoding algorithm specified in Section 5.2. The host MUST 408 further ensure that the geolocation information encoded in the option 409 is current and accurate. 411 IPv6 destinations that do not recognize the IPv6 GEO destination 412 option MUST ignore it and continue to process the IPv6 destination 413 options extension header as though the IPv6 GEO option were not 414 present. 416 6. IANA Considerations 418 IANA is requested to allocate an IPv6 Option number for the IPv6 GEO 419 Option in the "Destination Options and Hop-by-Hop Options" registry. 421 7. Security Considerations 423 Packets with IPv6 GEO options that are sent in the clear without 424 encryption risk exposure of sensitive information to unauthorized 425 eavesdroppers. When location privacy is desired, Internet security 426 protocols (e.g., IPsec [RFC4301], etc.) and/or link layer security 427 SHOULD be used to ensure confidentiality. 429 A spoofing attack is exposed when a source includes forged IPv6 GEO 430 information that is incorrect for its current location and/or time. 431 Destinations SHOULD therefore authenticate the source of IPv6 packets 432 before accepting any IPv6 GEO information they may include. 434 User agents MUST NOT send geolocation information to unauthorized 435 correspondents (e.g., Web sites, etc.) without the express permission 436 of the user. 438 8. Related Work in the IETF 440 The IETF GEOPRIV working group is chartered to "continue to develop 441 and refine representations of location in Internet protocols, and to 442 analyze the authorization, integrity, and privacy requirements that 443 must be met when these representations of location are created, 444 stored, and used". However, the group is located within the Real- 445 time Applications and Infrastructure area, and as such it is not 446 clear whether the Internet layer approach proposed in this document 447 would fit within the area focus. The GEOPRIV working group has 448 published a BCP on "An Architecture for Location and Location Privacy 449 in Internet Applications" [RFC6280]. 451 A BoF on "Internet-wide Geo-Networking (geonet)" was held at IETF88 452 in November 2013. A Problem Statement related to the BoF states 453 that: "Internet-based applications use IP addresses to address a node 454 that can be a host, a server or a router. Scenarios and use cases 455 exist where nodes are being addressed using their geographical 456 location instead of their IP address" 457 [I-D.karagiannis-problem-statement-geonetworking]. This BoF was held 458 within the Internet area and concerns geolocation at the Internet 459 layer. 461 As a result of the geonet BoF, a new working group known as 462 'Intelligent Transportation Systems (its) is undergoing chartering 463 activities. It is expected that IPv6GEO will be closely related to 464 the its charter. 466 9. Implementation Status 468 A prototype implementation has been developed and tested, but not yet 469 available for public release. The prototype implementation uses the 470 Option Type value reserved for experimentation [RFC3692]. 472 10. Contributers 474 The authors greatly appreciate the efforts of Jin Fang, who jointly 475 developed the IPv6 GEO message format and was the primary author of 476 the prototype implementation. We wish Jin the best of success in his 477 future endeavors. 479 11. Acknowledgments 481 The following individuals are acknowledged for helpful comments and 482 suggestions: Jeff Ahrenholz, Kerry Hu. 484 12. References 486 12.1. Normative References 488 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 489 DOI 10.17487/RFC0791, September 1981, 490 . 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 498 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 499 December 1998, . 501 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 502 Considered Useful", BCP 82, RFC 3692, 503 DOI 10.17487/RFC3692, January 2004, 504 . 506 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 507 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 508 RFC 6564, DOI 10.17487/RFC6564, April 2012, 509 . 511 12.2. Informative References 513 [I-D.ietf-opsec-ipv6-eh-filtering] 514 Gont, F., LIU, S., and R. Bonica, "Recommendations on 515 Filtering of IPv6 Packets Containing IPv6 Extension 516 Headers", draft-ietf-opsec-ipv6-eh-filtering-01 (work in 517 progress), July 2016. 519 [I-D.karagiannis-problem-statement-geonetworking] 520 Karagiannis, G., Heijenk, G., Festag, A., Petrescu, A., 521 and A. Chaiken, "Internet-wide Geo-networking Problem 522 Statement", draft-karagiannis-problem-statement- 523 geonetworking-01 (work in progress), November 2013. 525 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 526 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 527 December 2005, . 529 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 530 Tschofenig, H., and H. Schulzrinne, "An Architecture for 531 Location and Location Privacy in Internet Applications", 532 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 533 . 535 [WGS-84] Wikipedia, W., "World Geodetic System 536 (http://en.wikipedia.org/wiki/World_Geodetic_System)", 537 November 2013. 539 [WGS-ENCODE] 540 Dupuis, L., "Efficient WGS84 (aka GPS) Coordinates 541 Compression (http://www.dupuis.me/node/35)", August 2013. 543 Authors' Addresses 545 Brian Skeen 546 Boeing Phantom Works 547 P.O. Box 3707 548 Seattle, WA 98124 549 USA 551 Email: brian.l.skeen@boeing.com 552 Edwin King 553 Boeing EO&T IT 554 P.O. Box 3707 555 Seattle, WA 98124 556 USA 558 Email: edwin.e.king@boeing.com 560 Fred L. Templin (editor) 561 Boeing Research & Technology 562 P.O. Box 3707 563 Seattle, WA 98124 564 USA 566 Email: fltemplin@acm.org