idnits 2.17.1 draft-hain-ipv6-geo-addr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 190 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 357 has weird spacing: '... bits deg...' == Line 413 has weird spacing: '...on long bit ...' == Line 613 has weird spacing: '...d.mm.ss or 2...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2010) is 5031 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 747 looks like a reference -- Missing reference section? '2' on line 747 looks like a reference -- Missing reference section? '3' on line 747 looks like a reference -- Missing reference section? '4' on line 177 looks like a reference -- Missing reference section? '5' on line 229 looks like a reference -- Missing reference section? '6' on line 566 looks like a reference -- Missing reference section? '0' on line 747 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet-Draft T. Hain 4 Intended status: Standards Track Cisco 5 Expires: January 2011 July 2010 7 An IPv6 Geographic 8 Global Unicast Address Format 10 draft-hain-ipv6-geo-addr-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. This document may contain 16 material from IETF Documents or IETF Contributions published or made 17 publicly available before November 10, 2008. The person(s) 18 controlling the copyright in some of this material may not have 19 granted the IETF Trust the right to allow modifications of such 20 material outside the IETF Standards Process. Without obtaining an 21 adequate license from the person(s) controlling the copyright in 22 such materials, this document may not be modified outside the IETF 23 Standards Process, and derivative works of it may not be created 24 outside the IETF Standards Process, except to format it for 25 publication as an RFC or to translate it into languages other than 26 English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 10, 2010. 46 Unicast Address Format 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the BSD License. 62 Abstract 64 This document defines an IPv6 Geographic global unicast address 65 format for use in the Internet. The address format defined in this 66 document is consistent with the IPv6 Protocol [1] and the "IPv6 67 Addressing Architecture" [2]. It is designed to facilitate scalable 68 Internet routing when sites attach to multiple service providers, by 69 using a prefix based on a geographic reference to the site. A 70 natural byproduct of this address allocation mechanism is that all 71 addresses are fixed allowing sites to change providers at will 72 without requiring their network to renumber. 74 Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 78 this document are to be interpreted as described in RFC-2119 [3]. 80 Unicast Address Format 82 Status of this Memo................................................... 1 83 Abstract.............................................................. 2 84 Conventions used in this document..................................... 2 85 Introduction.......................................................... 3 86 Overview of the IPv6 Address.......................................... 5 87 IPv6 Geographic Global Unicast Address Format......................... 6 88 Examples.............................................................. 7 89 Interleave process detail: .......................................... 8 90 Interleave examples: ................................................ 9 91 Airport location examples: .......................................... 9 92 U.S. postal examples: .............................................. 10 93 Locations within a 600km square - New York area (~Zone)::/12 94 ...... 10 95 Locations within a 150km square - Miami area (~Region)::/16 96 ....... 10 97 Locations within a 40km square - Chicago area (~Metro)::/20 98 ....... 10 99 Examples of existing exchange points & potential prefixes: 100 ........ 11 101 A Geographic Multicast address format:............................... 11 102 Subnet Identifier.................................................... 11 103 Technical Motivation................................................. 11 104 General Considerations............................................... 12 105 IANA Considerations.................................................. 12 106 RFC Editor Considerations............................................ 12 107 Security Considerations.............................................. 12 108 Appendix A:.......................................................... 13 109 Appendix B:.......................................................... 16 110 Extended resolution ................................................ 16 111 References........................................................... 17 112 Acknowledgments...................................................... 19 113 Author's Addresses................................................... 19 115 Introduction 117 This document defines a Geographic global unicast address format for 118 IPv6 address allocation. The mechanism defined here breaks down the 119 geographic location of the site into prefix lengths that map well 120 into existing routing protocols. It is not proposing that routers 121 know about geography, but that a prefix that routers know how to 122 deal with be constructed out of something readily available which 123 uniquely identifies a site such as the physical-media (layer-1) 124 demarcation point between the public Internet and the site. 126 There have been numerous diatribes about how addressing has to map 127 to topology, often noting that existing topology does not map 128 cleanly to geographic structure. The fundamental point being 129 overlooked in these cases is that the existing topology was deployed 130 to minimize the local costs at the time, yet those cost factors are 131 not static so topology evolves over time. In particular, the costs 132 Unicast Address Format 134 associated with a bloated routing system are not factored into the 135 historical topology. 136 Another assumption that is widespread is that there has to be a 137 single global 'default-free-zone' (DFZ). Measured differences in BGP 138 updates show this to be a fallacy, even when it is the assumed 139 operating mode for the global transit providers. Independent of the 140 differing views of the DFZ there are also VPN overlays in many BGP 141 environments, which have explicitly different aggregate sets. In any 142 case, while a provider aggregate (PA) addressing architecture should 143 result in a single global DFZ, other aggregate sets already co-exist 144 so adding one more will not directly impact the existing ones. As 145 such the format described here is not about replacing the PA 146 architecture, rather it is an additional tool to deal with 147 situations that would bloat PA beyond utility. The expectation is 148 that 2 smaller tables would both use fewer resources as well as be a 149 closer match to the desired routing policy. 151 Specifically, this format is targeted at situations where smaller 152 organizations are looking for regional multi-homing, or other 153 reasons for a provider independent address block. It is assumed that 154 due to their commercial value service providers will not try to 155 discourage large organizations from continuing to use the same 156 approaches they have to establish explicit entries in the PA DFZ. 157 While these historical approaches are manageable for a relatively 158 small number of large organizations, the ongoing concern is that 159 applying them to a large number of small organizations will 160 effectively disable the global transit routing system. 162 The Geographic format described here explicitly isolates a multi- 163 homed site's address prefix from the set of providers it is 164 connected to. As a concession to operational simplicity, the format 165 optimizes the operational issue of identifying the demarcation point 166 as a direct trade-off against the consumption of address space 167 assigned to uninhabited regions of the planet. The overall goal is 168 to allow efficient routing aggregation for single sites that connect 169 directly to multiple providers or to metropolitan scale exchanges. 170 Sites will have the choice to connect to either or both types of 171 service. The details about specific site topology will be limited to 172 the service providers that are making the direct connections, and 173 traffic will follow the shortest path from the perspective of the 174 current source. 176 The basic mechanism is an Earth surface location defined by WGS-84 177 [4] latitude and longitude which represents the lower left corner of 178 a nominal square ~6.4m on a side (equatorial). WGS-84 was selected 179 because low-cost hand-held devices with the necessary level of 180 accuracy on a global scale are readily available. For the purposes 181 of this document, the term square and size of the area covered are 182 used as an approximation to describe the concept. Therefore the 183 difference in longitude vs. latitude circumference (flattening) 184 resulting in a difference of the latitudinal sides will be ignored 185 in the description, but accounted for in the measurement and 186 Unicast Address Format 188 allocation process. Interleaving is used to create a 44-bit 189 reference value from a 2-bit section id plus the 21-bit values 190 corresponding to each side of the grid. The number of subnets 191 supported by this address format should be sufficient for a variety 192 of uses. 194 Addresses defined with the Geographic format prefix xxxx (see IANA 195 considerations) are portable between providers. At the same time 196 since they are defined by a fixed geographic location, by definition 197 these prefixes are NOT-PORTABLE when a network attachment point 198 changes geographic locations. Entities that expect reference values 199 to be portable across physical location moves MUST use alternatives 200 such as Provider-Aggregatable addresses or DNS names. Multi-site 201 organizations SHOULD be using an appropriate subset of the available 202 prefixes, aligning desired external traffic patterns with internal 203 prefix distribution. 205 While this format is based on geographic location, it does not 206 necessarily require renumbering devices as they move around within 207 the boundaries of a specific network. This is a local decision based 208 on the desired external traffic patterns. The only time a 209 renumbering event may be required is when the demarcation point to 210 the public Internet is being physically moved. Even then, if the 211 local jurisdiction remains the same (ie: the demarcation point is 212 simply moving between buildings occupied by the same company) the 213 prefix is may be left unchanged. 215 One proposed use of this format is for use by mobile routers that do 216 happen to be aware of their geographic position. Using this format 217 allows these routers to construct an ad-hoc network where the 218 prefixes naturally aggregate for prefixes far away. At the same time 219 it is clear to all nodes within the geographic region what their 220 prefix should be, which can further be leveraged to reduce the 221 number of unsolicited RA messages that would unnecessarily consume 222 battery power. 224 Overview of the IPv6 Address 226 IPv6 addresses are 128-bit identifiers for interfaces and sets of 227 interfaces. There are three types of addresses: Unicast, Anycast, 228 and Multicast. This document defines a specific type of Unicast 229 address prefix. In conjunction with RFC 3306 [5], these Unicast 230 prefixes define a specific capability for Multicast groups to target 231 group members in a geographic region. 233 In this document, fields in addresses are given specific names, for 234 example "subnet". When this name is used with the term "ID" (for 235 "identifier") after the name (e.g., "subnet ID"), it refers to the 236 contents of the named field. When it is used with the term "prefix" 237 Unicast Address Format 239 (e.g. "subnet prefix") it refers to all of the addressing bits to 240 the left of and including this field. 242 IPv6 unicast addresses are designed assuming that the Internet 243 routing system makes forwarding decisions based on a "longest prefix 244 match" algorithm on arbitrary bit boundaries and does not have any 245 knowledge of the internal structure of IPv6 addresses. The structure 246 in IPv6 addresses is for assignment and allocation. Due to the 247 relationship between physical location of routers, geography, and 248 human readability there may be a tendency to manage the routers so 249 that they make forwarding decisions on nibble boundaries, but there 250 is nothing in the format requiring that. Each router will need to be 251 configured to forward based on a prefix length appropriate for the 252 context of the specific local topology. 254 The specific type of an IPv6 address is indicated by the leading 255 bits in the address. The variable-length field comprising these 256 leading bits is called the Format Prefix (FP). This document defines 257 an address format for the xxxx (binary) (see IANA considerations) 258 Format Prefix for Geographic reference global unicast addresses. The 259 same address format could be used with other Format Prefixes, as 260 long as these Format Prefixes also identify IPv6 unicast addresses. 261 For example, different FPs could be used to distinguish between 262 resolution boundaries for three dimensional applications (see 263 Extended Resolution on page 16). Only the xxxx Format Prefix is 264 defined here. 266 IPv6 Geographic Global Unicast Address Format 268 Geographic address prefixes use a geographic reference derived from 269 a bit interleave of the WGS-84 based latitude and longitude of the 270 demarcation point of a site. The resulting 44-bit field provides a 271 resolution grid of approximately 6.4 meters (equatorial) on a side. 272 While the prefix MAY be defined and routed on any bit boundary 273 length, the requirement for all service providers announcing a 274 specific prefix to be capable of delivering traffic to all others, 275 will have a tendency to naturally limit the operational choices. 277 | 3 | 45 bits | 16 bits | 64 bits | 278 +---+---------------------+-----------+----------------------------+ 279 |001|global routing prefix| subnet ID | interface ID | 280 +---+---------------------+-----------+----------------------------+ 282 Creating the Geographic address prefix is accomplished by 283 establishing 4 major geographic sections. Three sections are in the 284 band between +/- 60 degrees latitude, with the fourth split between 285 the poles. Using section 00 as an example, the origin is established 286 at WGS-84 latitude and longitude 90e 60s. Locations covering 120 287 degrees east and north (measured to 5 places right of the decimal 288 ie: deg.xxxxx) are normalized to this origin, then those values are 289 divided by the incremental angle. For latitudes between +/- 60 290 Unicast Address Format 292 degrees the incremental angle is 0.00005722045898437500 293 (120/(2^21)). 295 The specific sequence for address formation is: 297 1. demarcation WGS-84 value in degrees rounded to 5 decimal places 298 follow steps for appropriate section 299 00 - 90e 60s to 209.99999e 59.99999n 300 01 - 210e 60s to 329.99999e 59.99999n 301 10 - 330e 60s to 89.99999e 59.99999n 302 110 - 90e 90s to 89.99999e 59.99999s 303 111 - 90e 60n to 89.99999e 90n 305 --- equatorial band 306 2. normalize for origin of the section 307 sec 0 308 a) for east subtract 90 from the value 309 b) for west subtract the value from 270 310 c) for north add 60 to the value 311 d) for south subtract the value from 60 312 3. divide resulting values by 0.00005722045898437500 (120/2^21) 313 4. convert each of the integers to 21-digit binary 314 5. bit interleave latitude, longitude into 42-bit result 315 6. prepend the 2-bit section number 316 7. prepend the 4-bit FP xxxx to form 48-bit prefix 318 --- polar sections 319 2. normalize for origin of the section 320 sec 3 - > 60 n/s 321 a) for east subtract 90 322 .1) if less than 0, add 360 323 b) for west subtract from 270 324 .1) if less than 0, add 360 325 c) for north subtract 60 326 d) for south subtract from 90 327 3. divide resulting values by 0.00017166137695312500 (360/2^21) 328 4. convert each of the integers to 21-digit binary 329 5. adjust latitude value for north / south section 330 a) for north set bit A(21) 331 b) for south clear bit A(21) 332 6. bit interleave latitude, longitude into 42-bit result 333 7. prepend the 2-bit section number 334 8. prepend the 4-bit FP xxxx to form 48-bit prefix 336 Examples 338 The examples in the tables below highlight the difficulty of 339 aligning technical details of bit patterns with human meaningful 340 text strings. One of the explicit goals of the first table is to 341 identify the very large scopes devoid of geo-political context, 342 Unicast Address Format 344 while recognizing the need to provide something that an operator can 345 relate to as the resolution becomes finer grained. In any case these 346 are only descriptive examples, and actual implementations would be 347 based on engineering requirements. 349 The Reference field in the prefix MUST be calculated for a site at 350 44-bits, but MAY be used in routing calculations on any bit boundary 351 appropriate for the topology. For human reference the approximate 352 surface area covered by each value of the grid is provided in the 353 table below. The size in meters is based on rounded values for the 354 equatorial circumference and should only be used as a conceptual 355 guideline. 357 bits degrees equatorial sq scope sites 358 -------------------------------------------------------------------- 359 2 -> 120.00000 13358 km section 360 4 -> 60.00000 6679 km expanse 361 8 -> 15.00000 1669 km frame 362 12 -> 3.75 417 km zone 363 16 -> 0.9375 104 km region 364 20 -> 0.234375 26 km metro 16777216 365 24 -> 0.05859375 6.5 km city 1048576 366 28 -> 0.0146484375 1.6 km locality 65536 367 32 -> 0.003662109375 407 m neighborhood 4096 368 36 -> 0.00091552734375 102 m block 256 369 40 -> 0.0002288818359375 25 m lot 16 370 44 -> 0.000057220458984375 6.4 m site 1 372 The location addressed as x000:0000:0000::/48 covers an area in the 373 Indian Ocean ~ 6.4 m on a side, north and east of the point 60 374 degrees south - 90 degrees east. Specifically the WGS84 values 375 between, 60s to 59.99994s and 90e to 90.00005e. 377 Interleave process detail: 378 A bit interleave is used to allow aggregation on arbitrary 379 granularities. From the left after the 4-bit format prefix, bits 123 380 & 122 will identify the section using the table: 381 00 - 90e 60s through 209.99999e 59.99999n 382 01 - 210e 60s through 329.99999e 59.99999n 383 10 - 330e 60s through 89.99999e 59.99999n 384 110 - 90e 90s through 89.99999e 59.99999s 385 111 - 90e 60n through 89.99999e 90n 387 Example: 388 Mont Orohena, Tahiti 17.62000 s 149.48000 w 390 This location is in section 01, where the coordinates normalize to: 391 A - 42.38 ; O - 0.52 392 Unicast Address Format 394 dividing those values by 120/2^21 returns: 395 A - 740644 ; O - 9087 397 converting those to hex results in: 398 A - B4D24 ; O - 237F 400 with binary equivalent from which the bits are interleaved: 402 A - 0 1011 0100 1101 0010 0100 ; O - 0 0000 0010 0011 0111 1111 403 A(21)---------------------(0); O(21)---------------------(0) 405 A(21)O(21) A(20)O(20)A(19)O(19) A(18)O(18)... A(1)O(1)A(0)O(0) 407 00 1000 1010 0010 0100 1010 0111 0001 1101 0111 0101 409 The 6 bits of FP and section ID are prepended with the final result: 410 x48A:24A7:1D75::/48 412 Interleave examples: 413 Region section lat section long bit interleave 414 --------------------------------------------------------- 415 W. Europe (west) 1C0000 : 000000 -> xAA0:0000:0000:: 416 W. Europe (east) 1C0000 : 080000 -> xAE0:0000:0000:: 417 S. Africa 070000 : 080000 -> x86A:0000:0000:: 418 NE Africa 148000 : 0C8000 -> xA70:0000:0000:: 419 E. Europe 1C0000 : 110000 -> xBA1:0000:0000:: 420 C. Asia 148000 : 000000 -> x220:8000:0000:: 421 E. Asia 190000 : 0C0000 -> x2D2:0000:0000:: 422 Australia 070000 : 0C0000 -> x07A:0000:0000:: 423 Alaska 020000 : 0A0000 -> xE4C:0000:0000:: 424 NW US 1C0000 : 088000 -> x6E0:4000:0000:: 425 Central America 148000 : 0D0000 -> x671:8000:0000:: 426 SE US 190000 : 100000 -> x782:0000:0000:: 427 South America 070000 : 100000 -> x52A:0000:0000:: 428 NW Africa 100000 : 038000 -> xA05:4000:0000:: 430 S Pole - 90.00000 s 90.00000 e xC00:0000:0000:: 431 N Pole - 90.00000 n 90.00000 e xF5D:DDDD:DDDD:: 433 Airport location examples: 435 MIA - 25.78000 n 80.28000 w x72C:E3BF:E8D9:: 436 ATL - 33.63000 n 84.42000 w x781:BF7A:F4F9:: 437 IAD - 38.93000 n 77.45000 w x78D:3942:C7FF:: 438 JFK - 40.63000 n 73.77000 w x798:B327:DDB5:: 439 ORD - 41.97000 n 87.90000 w x78A:4A57:1978:: 440 DEN - 39.85000 n 104.70000 w x6D8:8910:3DE6:: 441 SFO - 37.62000 n 122.37000 w x69D:11D4:0F13:: 442 LAX - 33.93000 n 118.40000 w x6C2:14F1:25C6:: 443 SAN - 32.73000 n 117.18000 w x6C0:DA88:62AD:: 445 Unicast Address Format 447 ANC - 61.16000 n 150.00000 w xE44:46CC:6C66:: 448 SYD - 33.97000 s 151.17000 e x128:BA55:FBDF:: 449 NRT - 35.75000 n 140.37000 e x2D3:94D4:C195:: 450 DEL - 28.55000 n 77.01000 e xB7A:C2E3:051F:: 451 CAI - 30.10000 n 31.40000 e xB80:117D:E30E:: 452 CPT - 33.95000 s 18.60000 e x878:FF19:7284:: 453 CDG - 49.00000 n 2.53000 e xAE2:4652:4716:: 454 LHR - 51.47000 n 0.350000 w xAB7:DEC2:89EF:: 455 GIG - 22.80000 s 42.23000 w x5D2:EDDB:8163:: 456 SCL - 33.38000 s 70.78000 w x53B:0682:2119:: 457 MEX - 19.43000 n 99.07000 w x673:49B8:798E:: 459 U.S. postal examples: 461 Locations within a 600km square - New York area (~Zone)::/12 462 Danvers, MA - 42.56940 n 70.94246 w x79B:2398:575C:: 463 Cambridge, MA - 42.37704 n 71.12561 w x79B:20E0:BF51:: 464 Boston, MA - 42.21300 n 71.03300 w x79B:2056:DBA2:: 465 Providence, RI - 41.49260 n 71.24400 w x79B:0200:94EA:: 466 Bridgeport, CT - 41.10010 n 73.12100 w x798:EA22:B031:: 467 Upton, NY - 40.52100 n 72.53100 w x798:E4E8:4ADA:: 468 New York, NY - 40.42510 n 74.00200 w x798:B03A:8CAB:: 469 Newark, NJ - 40.44080 n 74.10200 w x798:A5D1:B059:: 470 Cherry Hill, NJ - 39.93080 n 75.01754 w x78D:DD76:FA53:: 471 Baltimore, MD - 39.17250 n 76.36400 w x78D:6E0C:5CA6:: 472 TysonsCorner, VA - 38.55070 n 77.13500 w x78D:347E:9A88:: 473 Reston, VA - 38.93501 n 77.35144 w x78D:3957:BF69:: 474 Chantilly, VA - 38.88413 n 77.43544 w x78D:33E9:6FF3:: 476 Locations within a 150km square - Miami area (~Region)::/16 477 Boca Raton, FL - 26.34460 n 80.21094 w x72E:4178:3A32:: 478 DeerfiledBeachFl - 26.30956 n 80.09917 w x72E:4425:5611:: 479 CoralSprings, FL - 26.27140 n 80.25558 w x72E:4143:2F68:: 480 PompanoBeach, FL - 26.23153 n 80.12346 w x72C:EEAC:8FF3:: 481 FtLauderdale, FL - 26.12156 n 80.12878 w x72C:EE2B:5E8A:: 482 PembrokePines,FL - 26.02427 n 80.24018 w x72C:EB44:923B:: 483 South Miami, FL - 25.70025 n 80.30141 w x72C:E39C:2B95:: 484 Key Biscayne, FL - 25.69210 n 80.16248 w x72C:E3D7:E98D:: 485 Homestead, FL - 25.47664 n 80.48385 w x72C:E0CB:4E24:: 487 Locations within a 40km square - Chicago area (~Metro)::/20 488 Skokie, IL - 42.03617 n 87.73283 w x78A:4B66:D89B:: 489 Schaumburg, IL - 42.05807 n 88.04819 w x78A:4A3B:0DDC:: 490 Chicago, IL - 41.88585 n 87.61812 w x78A:4C8E:69C4:: 491 Oak Brook, IL - 41.78910 n 87.94009 w x78A:4870:E1F7:: 492 DownersGrove, IL - 41.80343 n 88.01375 w x78A:4837:E16A:: 493 Orland Park, IL - 41.61938 n 87.84225 w x78A:4387:1A7B:: 495 Unicast Address Format 497 Examples of existing exchange points & potential prefixes: 498 LINX, London - 51.50717 n 0.00117 w xAB7::/12 499 AMS-IX, Amsterdam - 52.3025 n 4.93533 e xAE3::/12 500 NYIIX, NY - 40.70350 n 74.00783 w x798::/16 501 STARTAP, Chicago - 41.87650 n 87.63467 w x78A::/16 502 LAIIX, LA - 34.04233 n 118.24383 w x6C2:171F::/20 503 PAIX, Palo Alto - 37.44083 n 122.15683 w x697:BEDA::/20 504 SIX, Seattle - 47.61321 n 122.33799 w x6B5:9E08::/20 505 NSPIXP6, Tokyo - 35.62500 n 139.90750 e x2D3::/16 506 SII, Shanghai - 31.30200 n 121.49167 e x2C0::/16 508 A Geographic Multicast address format: 510 A public service or network administrator may wish to notify all 511 nodes within a given geographic area without requiring those clients 512 to figure out all the appropriate groups to join. Using the all- 513 nodes group ID 0000:0001, with RFC 3306 [5}, the PI prefix provides 514 a means to identify the region for the target multicast. 516 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 517 +--------+----+----+--------+--------+----------------+----------+ 518 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 519 +--------+----+----+--------+--------+----------------+----------+ 521 Using this mechanism a weather warning or other public alert could 522 be sent to participants in an area without the alerting service 523 needing to individually contact the subscribers PA addresses, or the 524 subscribers needing to know which specific groups to join (ie: 525 connect me to all alerts within a 100km radius). Alternatively, 526 specific groups could be defined for each public alert type, and the 527 alert radius defined here would still apply. 529 Subnet Identifier 530 (see RFC Editor considerations) 532 If 0001 were selected for the FP, this document would modify both 533 RFC 4291 & 3587 to extend the 64 bit Interface ID field size, and 16 534 bit Subnet ID field into the upper half of the Format Prefix 000 535 space. 537 Technical Motivation 539 The design choice for the size of the fields in the Geographic 540 address format was based on the need to separate the address 541 allocation from the service provider (specifically to address the 542 scaling problems that mechanism creates when sites connect to 543 multiple providers), the need to preserve the subnet structure 544 Unicast Address Format 546 defined in [6], and the resolution of readily available handheld GPS 547 receivers. 549 General Considerations 551 The operational considerations : of human readability in the routing 552 prefix lengths versus the topology realities used by the routing 553 system are network dependent and outside the scope of this document. 555 The technical considerations : the accuracy of the WGS-84 location 556 reading versus the margin of error for a 21-bit resolution. When 557 available, 5 places of significance right of decimal in lat/long 558 readings results in 1 meter increment, or well within rounding error 559 of 21 bit resolution : while between +/- 15 degrees latitude, using 560 only 4 places of significance results in 11.1 meter increments which 561 is considerably longer than the side ~ 6.4 m of the area being 562 identified. (At this time, readily available consumer-grade GPS 563 receivers are generally accurate to 3 meters, while commercial grade 564 receivers have augmentation for sub-1 meter accuracy.) 566 Alignment of the site boundary supporting SLA with the [6] format 567 allows sites to use a consistent subnet structure. 569 IANA Considerations 571 A 4-bit format prefix for PI address use needs to be assigned. The 572 format prefix 0001 is recommended to avoid breaking up any of the 573 unassigned 3-bit spaces. 575 RFC Editor Considerations 577 The format prefix binary value in the xxxx examples needs to be 578 replaced by the value assigned by IANA. 580 The format prefix hex value in the xhhh: examples needs to be 581 replaced by the value assigned by IANA. 583 The Subnet Identifier section, and the matching comment in the 584 references section should be removed if the IANA assigned prefix is 585 not in 0000::/3. It should be replaced with a pointer to (ARCH) for 586 global scope allocations. 588 Security Considerations 590 While there may be concerns about location privacy raised by this 591 scheme, there is nothing inherent in this address format that would 592 raise any more security considerations than any other global 593 addressing format. If location privacy were an issue it would be 594 Unicast Address Format 596 wise to avoid this mechanism in favor of location independent 597 mechanisms such as Provider-Aggregatable allocations. 599 Appendix A: 601 #!/usr/bin/perl 602 # 603 # This is a derivative of a script by mcr@sandelman.ca. 604 # http://www.sandelman.ottawa.on.ca/SSW/ietf/geo-pi/ 605 # 606 # The primary modification was to adjust for the change 607 # to sections and origin. This version also adds an 608 # option for decimal degree input format. 609 # 610 # alh-ietf@tndh.net 2002/12/31 611 # 613 print "Please select format 1) dd.mm.ss or 2) dd.ddddd: "; 614 chop($fmt=); 616 print "Use minus (-) for south or west values. \n"; 617 print "Please enter your lattitude: "; 618 chop($lat=); 620 print "Please enter your longitude: "; 621 chop($long=); 623 if($fmt == 1) { 624 ($longdeg, $longmin, $longsec) = split(/ /, $long); 625 ($latdeg, $latmin, $latsec) = split(/ /, $lat); 627 if($longdeg < 0) { 628 $longdeg = 360 + $longdeg; 629 } 630 if($latdeg < 0) { 631 $latdeg = -$latdeg; 632 $south = 1; 633 } 634 $wgs84long = $longdeg + ($longmin / 60) + ($longsec / 360); 635 $wgs84lat = $latdeg + ($latmin / 60) + ($latsec / 360); 637 if($south == 1) { 638 $wgs84lat = -$wgs84lat; 639 } 640 } else { 641 if ($long < 0) { 642 $wgs84long = 360 + $long; 643 } else { 644 $wgs84long = $long; 645 } 646 } 647 Unicast Address Format 649 $wgs84lat = 90 + $lat; 651 # Origin is now south pole @ 0 degrees 653 if ($wgs84lat >= 30) { 654 if ($wgs84lat < 150) { 655 $seclat = $wgs84lat - 30; 656 if ($wgs84long >= 90) { 657 if ($wgs84long < 210) { 658 $section = 0; 659 $seclong = $wgs84long - 90; 660 } elsif ($wgs84long < 330) { 661 $section = 1; 662 $seclong = $wgs84long - 210; 663 } else { 664 $section = 2; 665 $seclong = $wgs84long - 330; 666 } 667 } else { 668 $section = 2; 669 $seclong = $wgs84long + 30; 670 } 671 } else { 672 $section = 7; 673 $seclat = $wgs84lat - 150; 674 $seclong = $wgs84long - 90; 675 } 676 } else { 677 $section = 6; 678 $seclat = $wgs84lat; 679 $seclong = $wgs84long - 90; 680 } 681 if ($seclong < 0) { 682 $seclong = 360 + $seclong; 683 } 685 # Origin is now normalized to section 686 print ("Sec Lat: $seclat \n"); 687 print ("Sec Long: $seclong \n"); 689 if($section < 3) { 690 $seclong = int($seclong / 0.000057220458984375); 691 $seclat = int($seclat / 0.000057220458984375); 692 } else { 693 $seclong = int($seclong / 0.00017166137695312500); 694 $seclat = int($seclat / 0.00017166137695312500); 695 } 697 # convert to binary 698 @lat = &convert_to_binary($seclat); 699 @long = &convert_to_binary($seclong); 700 @secbin = &convert_to_binary($section); 701 Unicast Address Format 703 print "Raw sec:",join('', @secbin),"\n"; 704 print "Raw lat: ",join('', @lat),"\n"; 705 print "Raw long:",join('', @long),"\n"; 707 # clean off excess leading 0's 708 foreach $i (1..11) { 709 shift(@lat); 710 shift(@long); 711 } 712 foreach $i (1..29) { 713 shift(@secbin); 714 } 716 # interleave bits 717 @geopi=(); 718 if ($section > 3) { 719 foreach $i (1..3) { 720 $secid = shift(@secbin); 721 push(@geopi, $secid); 722 } 723 } else { 724 shift(@secbin); 725 foreach $i (1..2) { 726 $secid = shift(@secbin); 727 push(@geopi, $secid); 728 } 729 } 730 my($o,$a); 731 foreach $i (1..21) { 732 $o = shift(@long); 733 $a = shift(@lat); 734 if ($section > 3 && $i == 1) { 735 # skip this bit in polar sections 736 } else { 737 push(@geopi, $a); 738 } 739 push(@geopi, $o); 740 } 742 print "Digits ",join('', @geopi),"\n"; 743 print "Lat: $lat Long: $long -> x"; 745 foreach $i (0..10) { 746 @nibble = @geopi[($i*4)..($i*4+3)]; 747 $nibble = $nibble[0]*8 + $nibble[1]*4 + $nibble[2]*2 + $nibble[3]; 748 print sprintf("%x", $nibble); 749 if($i==2 || $i==6) { 750 print ":"; 751 } 752 } 753 print "\n"; 754 Unicast Address Format 756 exit; 758 sub convert_to_binary { 759 local($num)=@_; 760 local($i, @digits); 762 @digits=(); 763 foreach $i (1..32) { 764 if($num & 1) { 765 unshift(@digits, 1); 766 } else { 767 unshift(@digits, 0); 768 } 769 $num = $num >> 1; 770 } 771 return @digits; 772 } 774 Appendix B: 776 Extended resolution 778 The basic mechanism provides allocation of /48's in a two 779 dimensional grid. At the same time there has been interest in finer 780 grained resolution, as well as the ability to express altitude. The 781 optional extended resolution provides three dimensional cube 782 resolution allocations. It is expected that allocations using this 783 extension will continue to be aggregated such that the prefix 784 announcement into the public routing table is no longer than a /48. 785 If that expectation will not be met, the extension will require a 786 different format prefix. 788 Options for encoding the bits beyond the lat-long grid as altitude 789 result in various depths when the goal is a cube. 791 44 bit lat-long grid + 16 bit altitude 792 44 -> 0.000057220458984375 6.4 m site 793 ~6.4 m cube to 419 km (260 mi) depth 795 46 bit lat-long grid + 14 bit altitude 796 46 -> 0.0000286102294921875 3.2 m room 797 ~3.2 m cube to 52 km (172,000 ft) depth 799 48 bit lat-long grid + 12 bit altitude 800 48 -> 0.0000143051147460937 1.6 m desk 801 ~1.6 m cube to 6.5 km (21,000 ft) depth