idnits 2.17.1 draft-mangione-ipv6-gps-alt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 252 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John Mangione 2 Competitive Computing 3 Title: GPS^IP 4 Expiration Date: 12-31-96 5 filename: draft-mangione-ipv6-gps-alt-00.txt 7 Status of This Memo: 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute working 12 documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 `1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 ABSTRACT 27 GPS^IP is a suggested adjunct or alternate addressing scheme to IP, 28 version 6. All of the remaining suggested, proposed, and ratified 29 standards would remain as they are. As its name implies, GPS^IP would 30 use Global Positioning System (GPS) information, perhaps in one of the 31 currently unassigned regions of the IPv6 address space. This global 32 position information would be placed somewhere in the 128 bit IP 33 address, to provide a reasonable level of uniqueness. The remainder of 34 the IP address could remain as currently described, both in IPv4 and 35 IPv6, as described in other documents. Alternatively, a portion of the 36 low order end of the IP address field could be populated with the MAC 37 address as supplied by the interface. 39 PERCEIVED BENEFITS 41 The benefits of using geographical position information in the IP 42 address are as follows: 44 Address Uniqueness. With the accuracy of GPS locating equipment 45 constantly improving, and the inclusion of altitude information in the 46 address, each node that occupies a unique physical space will, by 47 definition, have a unique "address". Although geographical 48 latitude/longitude position alone would suffice to provide relative 49 device uniqueness and routing knowledge, it is important to include 50 altitude information in the case of multifloored buildings, or racks of 51 equipment with unique identities. To guarantee node address uniqueness, 52 MAC address information could be inserted into the IP address, in the 53 same way low order portions of IPX addresses are generated. 55 Mobility. A node's address would change as it moved, constantly 56 providing a more accurate routable address, since the most local "GP 57 server" would also provide the most appropriate "default gateway" 58 address for traffic to and from the mobile node. 60 Transparency. Addresses would not have to be established for individual 61 nodes, since they would gather their addresses from equipment either in 62 the node itself, or from nearby GP servers. Furthermore, if a portion 63 of the low order end of the IP address field were to be populated with 64 the MAC address as supplied by the machine's interface circuitry, this 65 would guarantee uniqueness, even for machines that were right next to 66 each other. 68 Universality. This scheme could be used to provide meaningful 69 information, by way of an IP address, for all types of equipment, 70 including computer equipment, mobile/cellular phones, pagers, 71 satellites, vending machines, etc. 73 Backward Compatibility in routing methods. Current routing methodologies 74 (i.e., lookup tables, more authoritative default gateways) could still 75 be used. 77 The Potential For Greater Routing Efficiency. Currently, there is no 78 obvious method to correlate geographical position with a best route 79 metric, without artificially devising methods that would create such a 80 correlation (such as, "All nodes should be connected to their nearest 81 geographical router", or "All nodes that do connect to their nearest 82 geographical router can use the geography metric for routing". As the 83 idea ruminates in the minds of the brilliant masses on the Net, there 84 may come a time where routers may use lat-long-alt information to move 85 datagrams toward a destination by algorithmic methods, rather than 86 current lookup methods, for determining best route. Currently, however, 87 this is NOT being stated as a perceived benefit of use geographical 88 information in IP addressing. 90 Device Location Awareness. Perhaps the greatest benefit would be that 91 administrators and users of networks alike would be able to know where 92 devices were on their networks. . 94 DISCUSSION 96 GPS^IP is a suggested adjunct or alternate addressing scheme to IP, 97 version 6, referred to in RFC-1884. As its name implies, GPS^IP would 98 use Global Positioning System (GPS) information. The GPS is a system of 99 several space-based satellites that provide constantly transmitted 100 location information to Earth. GPS receivers on the Earth (or 101 elsewhere), with this transmitted information, and through the use of 102 triangulation, can determine their own location, as latitude, longitude 103 and altitude. This information, to a greater or lesser degree, provides 104 accurate location information with sub-meter accuracy. Since other 105 documents describe how this is achieved and how the degrees of accuracy 106 are managed, this document will merely assume that this information can 107 be made available to a node through some relatively inexpensive 108 circuitry which would include RF receiver capabilities. The circuitry 109 would be able to electronically produce its own location coordinates. 110 This information will be referred to (in this document) as a node's 111 global position (GP). 113 This global position information would be placed in some currently 114 unassigned portion of the 128 bit IP address, to provide a reasonable 115 level of uniqueness, which is a basic requirement of any transport 116 addressing scheme. The remainder of the IP address could remain as 117 currently described, both in IPv4 and IPv6, as the four octet system. 118 This would be done to provide administratively managed uniqueness, and, 119 to a lesser degree, routing information to the IP address. 120 Alternatively, a portion of the low order end of the IP address field 121 could be populated with the MAC address as supplied by the interface for 122 the guarantee of uniqueness. 124 Within the network, certain nodes, such as routers, would have an 125 awareness of their geographic location. This would be achieved by 126 equipping these nodes with inexpensive GPS devices that would 127 auto-locate. Also, certain of these nodes would provide such location 128 information to other nodes that request it. In effect, these nodes 129 would behave as Global Position Servers, "GP servers", or "GP daemons". 130 All "GP clients" would request and gather this information from GP 131 servers in their electronic horizon, or subnet, and use an algorithm, 132 such as quickest response time, to select the optimal default GP server. 133 The server that is chosen may or may not become the primary router, or 134 default gateway, for that client station. The router that would act as 135 the default gateway would become the destination router for all incoming 136 information to any nodes that are "registered with" that router. 138 Initially, only GP servers and routers would need to be configured, 139 either statically or dynamically, with accurate GP information. This 140 would be achieved statically, by using some hand-held lat-long-alt 141 device at the machine and manually entering it into the GP server, or 142 dynamically, by using a GPS location acquiring circuitry that would be 143 installed directly into the GP server, and would feed this information 144 directly and electronically to the system, perhaps through the BIOS, 145 like on-board clocks. 147 As time goes on, more client workstations would be outfitted with 148 position gathering circuitry, so that these nodes could also serve as 149 more local GP servers, and/or provide the actual lat-long-alt 150 information directly, for the internal use of the system to create its 151 own full IP address. 153 Not all routers would have to be GP aware at first. The core, or heart 154 of the network would be the devices that would have this information at 155 the outset. Routers that were further away from the "backbone" would 156 not necessarily have Global positioning awareness. Those that weren't 157 would pad that portion of the address with zeros. When the datagram 158 arrived at a GP aware router through standard routing methodologies, it 159 would be that router's responsibility to replace the appropriate zeros 160 with its own GP location coordinates. In this way, the GP portion of the 161 return address of the datagram would first become the nearest GP router 162 to the message originator. Thus, the "heart" of the routing system 163 would be GP aware at first, with the more peripheral portions of the 164 Internet becoming aware through the attrition of older devices in favor 165 of GP aware newer technologies. 167 CURRENT ARGUMENTS AGAINST THIS IDEA: 169 "Geographical information cannot be used for routing purposes, since 170 wires and geography are two different mathematical systems." 172 Response: Currently, there is no identifiable method of mapping 173 geographical information into an improved routing scheme than is 174 currently employed, but current routing schemes can still be used as 175 before, without alteration, so we are no worse off for having the 176 information there. And, with geographical information is in the 177 address, at least the potential for the evolution of improved routing 178 algorithms based on geography is there. 180 "What about privacy? I don't necessarily want anyone to know where I am 181 when I send a message." 183 Response: A "defeat location information" can be included as a 184 configuration check box that users can manipulate for those holding this 185 concern. Also, just as remailers are used, there would be similar ways 186 to ensure "locale privacy". 188 "There would be the cost overhead to include this equipment in 189 machines." 191 Response: It would not have to go into all machines as it would be a 192 discretionary portion of the address. Over time, the machines that were 193 most in need of locating quickly would be the ones that would get the 194 additional hardware. Furthermore, with Global Position Servers able to 195 provide proximity information to other "clients", devices would be able 196 to provide general location information without adding equipment on a 197 device-by-device basis. 199 "There would be the addressing overhead to include global position 200 information in the actual addresses." 202 Response: This overhead already exists, since the current proposal on 203 the table already accommodates 128 bits. There is no less overhead 204 transmitting all zeros than in transmitting global positioning 205 information instead. 207 Why go through all the effort? 209 Currently, with the proliferation of devices on the Internet, as well as 210 the intranets, and with the addition of new types of devices, such as 211 vending machines and video cameras, as is currently being experimented 212 with on the Internet, keeping track of where these machines are will 213 become increasingly more challenging. With the addition of software that 214 would graphically display portions of the network in relation to a room, 215 a floor, a building, or a continent, administrators could find the 216 beaconing node, or the network enabled printer that is out of paper. 217 This could all be done by looking at a map on a computer monitor and 218 seeing the various devices in relation to the space that it occupies. 219 In a small network that is not reconfigured frequently, this information 220 may be trivial. However, in networks of more than 100 nodes, a single 221 administrator or user would be hard-pressed to track all changes made to 222 the network, especially if that administrator or user were relatively 223 new to the network. To know where the vending machine got moved to on 224 campus while someone was on vacation would be a very useful piece of 225 information, especially if that device were sending distress pages that 226 it needed servicing. 228 What do you think? 230 Author/Contact Information: 232 John Mangione 233 Competitive Computing 234 2000 Mountain View Drive 235 Suite 106 236 Colchester, Vermont 05446 237 voice: (802) 655-0757 238 fax: (802) 655-6681 239 johnm@competitive.com