Network Working Group Internet-Draft T. Hain Intended status: Standards Track Cisco Expires: April 2010 October 2009 An IPv6 Geographic Global Unicast Address Format draft-hain-ipv6-geo-addr-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2010. Hain Expires April 2010 1 An IPv6 Provider-Independent Global October 2009 Unicast Address Format Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 BSD License. Abstract This document defines an IPv6 Geographic global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [1] and the "IPv6 Addressing Architecture" [2]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. Hain Expires April 2010 2 An IPv6 Provider-Independent Global October 2009 Unicast Address Format Status of this Memo................................................... 1 Abstract.............................................................. 2 Conventions used in this document..................................... 2 Introduction.......................................................... 3 Overview of the IPv6 Address.......................................... 5 IPv6 Geographic Global Unicast Address Format......................... 6 Examples.............................................................. 7 Interleave process detail: .......................................... 8 Interleave examples: ................................................ 9 Airport location examples: .......................................... 9 U.S. postal examples: .............................................. 10 Locations within a 600km square - New York area (~Zone)::/12 ...... 10 Locations within a 150km square - Miami area (~Region)::/16 ....... 10 Locations within a 40km square - Chicago area (~Metro)::/20 ....... 10 Examples of existing exchange points & potential prefixes: ........ 11 A Geographic Multicast address format:............................... 11 Subnet Identifier.................................................... 11 Technical Motivation................................................. 11 General Considerations............................................... 12 IANA Considerations.................................................. 12 RFC Editor Considerations............................................ 12 Security Considerations.............................................. 12 Appendix A:.......................................................... 13 Appendix B:.......................................................... 16 Extended resolution ................................................ 16 References........................................................... 17 Acknowledgments...................................................... 19 Author's Addresses................................................... 19 Introduction This document defines a Geographic global unicast address format for IPv6 address allocation. The mechanism defined here breaks down the geographic location of the site into prefix lengths that map well into existing routing protocols. It is not proposing that routers know about geography, but that a prefix that routers know how to deal with be constructed out of something readily available which uniquely identifies a site such as the physical-media (layer-1) demarcation point between the public Internet and the site. There have been numerous diatribes about how addressing has to map to topology, often noting that existing topology does not map cleanly to geographic structure. The fundamental point being overlooked in these cases is that the existing topology was deployed to minimize the local costs at the time, yet those cost factors are not static so topology evolves over time. In particular, the costs Hain Expires April 2010 3 An IPv6 Provider-Independent Global October 2009 Unicast Address Format associated with a bloated routing system are not factored into the historical topology. Another assumption that is widespread is that there has to be a single global 'default-free-zone' (DFZ). Measured differences in BGP updates show this to be a fallacy, even when it is the assumed operating mode for the global transit providers. Independent of the differing views of the DFZ there are also VPN overlays in many BGP environments, which have explicitly different aggregate sets. In any case, while a provider aggregate (PA) addressing architecture should result in a single global DFZ, other aggregate sets already co-exist so adding one more will not directly impact the existing ones. As such the format described here is not about replacing the PA architecture, rather it is an additional tool to deal with situations that would bloat PA beyond utility. The expectation is that 2 smaller tables would both use fewer resources as well as be a closer match to the desired routing policy. Specifically, this format is targeted at situations where smaller organizations are looking for regional multi-homing, or other reasons for a provider independent address block. It is assumed that due to their commercial value service providers will not try to discourage large organizations from continuing to use the same approaches they have to establish explicit entries in the PA DFZ. While these historical approaches are manageable for a relatively small number of large organizations, the ongoing concern is that applying them to a large number of small organizations will effectively disable the global transit routing system. The Geographic format described here explicitly isolates a multi- homed site's address prefix from the set of providers it is connected to. As a concession to operational simplicity, the format optimizes the operational issue of identifying the demarcation point as a direct trade-off against the consumption of address space assigned to uninhabited regions of the planet. The overall goal is to allow efficient routing aggregation for single sites that connect directly to multiple providers or to metropolitan scale exchanges. Sites will have the choice to connect to either or both types of service. The details about specific site topology will be limited to the service providers that are making the direct connections, and traffic will follow the shortest path from the perspective of the current source. The basic mechanism is an Earth surface location defined by WGS-84 [4] latitude and longitude which represents the lower left corner of a nominal square ~6.4m on a side (equatorial). WGS-84 was selected because low-cost hand-held devices with the necessary level of accuracy on a global scale are readily available. For the purposes of this document, the term square and size of the area covered are used as an approximation to describe the concept. Therefore the difference in longitude vs. latitude circumference (flattening) resulting in a difference of the latitudinal sides will be ignored in the description, but accounted for in the measurement and Hain Expires April 2010 4 An IPv6 Provider-Independent Global October 2009 Unicast Address Format allocation process. Interleaving is used to create a 44-bit reference value from a 2-bit section id plus the 21-bit values corresponding to each side of the grid. The number of subnets supported by this address format should be sufficient for a variety of uses. Addresses defined with the Geographic format prefix xxxx (see IANA considerations) are portable between providers. At the same time since they are defined by a fixed geographic location, by definition these prefixes are NOT-PORTABLE when a network attachment point changes geographic locations. Entities that expect reference values to be portable across physical location moves MUST use alternatives such as Provider-Aggregatable addresses or DNS names. Multi-site organizations SHOULD be using an appropriate subset of the available prefixes, aligning desired external traffic patterns with internal prefix distribution. While this format is based on geographic location, it does not necessarily require renumbering devices as they move around within the boundaries of a specific network. This is a local decision based on the desired external traffic patterns. The only time a renumbering event may be required is when the demarcation point to the public Internet is being physically moved. Even then, if the local jurisdiction remains the same (ie: the demarcation point is simply moving between buildings occupied by the same company) the prefix is may be left unchanged. One proposed use of this format is for use by mobile routers that do happen to be aware of their geographic position. Using this format allows these routers to construct an ad-hoc network where the prefixes naturally aggregate for prefixes far away. At the same time it is clear to all nodes within the geographic region what their prefix should be, which can further be leveraged to reduce the number of unsolicited RA messages that would unnecessarily consume battery power. Overview of the IPv6 Address IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast, Anycast, and Multicast. This document defines a specific type of Unicast address prefix. In conjunction with RFC 3306 [5], these Unicast prefixes define a specific capability for Multicast groups to target group members in a geographic region. In this document, fields in addresses are given specific names, for example "subnet". When this name is used with the term "ID" (for "identifier") after the name (e.g., "subnet ID"), it refers to the contents of the named field. When it is used with the term "prefix" Hain Expires April 2010 5 An IPv6 Provider-Independent Global October 2009 Unicast Address Format (e.g. "subnet prefix") it refers to all of the addressing bits to the left of and including this field. IPv6 unicast addresses are designed assuming that the Internet routing system makes forwarding decisions based on a "longest prefix match" algorithm on arbitrary bit boundaries and does not have any knowledge of the internal structure of IPv6 addresses. The structure in IPv6 addresses is for assignment and allocation. Due to the relationship between physical location of routers, geography, and human readability there may be a tendency to manage the routers so that they make forwarding decisions on nibble boundaries, but there is nothing in the format requiring that. Each router will need to be configured to forward based on a prefix length appropriate for the context of the specific local topology. The specific type of an IPv6 address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP). This document defines an address format for the xxxx (binary) (see IANA considerations) Format Prefix for Geographic reference global unicast addresses. The same address format could be used with other Format Prefixes, as long as these Format Prefixes also identify IPv6 unicast addresses. For example, different FPs could be used to distinguish between resolution boundaries for three dimensional applications (see Extended Resolution on page 16). Only the xxxx Format Prefix is defined here. IPv6 Geographic Global Unicast Address Format Geographic address prefixes use a geographic reference derived from a bit interleave of the WGS-84 based latitude and longitude of the demarcation point of a site. The resulting 44-bit field provides a resolution grid of approximately 6.4 meters (equatorial) on a side. While the prefix MAY be defined and routed on any bit boundary length, the requirement for all service providers announcing a specific prefix to be capable of delivering traffic to all others, will have a tendency to naturally limit the operational choices. | 3 | 45 bits | 16 bits | 64 bits | +---+---------------------+-----------+----------------------------+ |001|global routing prefix| subnet ID | interface ID | +---+---------------------+-----------+----------------------------+ Creating the Geographic address prefix is accomplished by establishing 4 major geographic sections. Three sections are in the band between +/- 60 degrees latitude, with the fourth split between the poles. Using section 00 as an example, the origin is established at WGS-84 latitude and longitude 90e 60s. Locations covering 120 degrees east and north (measured to 5 places right of the decimal ie: deg.xxxxx) are normalized to this origin, then those values are divided by the incremental angle. For latitudes between +/- 60 Hain Expires April 2010 6 An IPv6 Provider-Independent Global October 2009 Unicast Address Format degrees the incremental angle is 0.00005722045898437500 (120/(2^21)). The specific sequence for address formation is: 1. demarcation WGS-84 value in degrees rounded to 5 decimal places follow steps for appropriate section 00 - 90e 60s to 209.99999e 59.99999n 01 - 210e 60s to 329.99999e 59.99999n 10 - 330e 60s to 89.99999e 59.99999n 110 - 90e 90s to 89.99999e 59.99999s 111 - 90e 60n to 89.99999e 90n --- equatorial band 2. normalize for origin of the section sec 0 a) for east subtract 90 from the value b) for west subtract the value from 270 c) for north add 60 to the value d) for south subtract the value from 60 3. divide resulting values by 0.00005722045898437500 (120/2^21) 4. convert each of the integers to 21-digit binary 5. bit interleave latitude, longitude into 42-bit result 6. prepend the 2-bit section number 7. prepend the 4-bit FP xxxx to form 48-bit prefix --- polar sections 2. normalize for origin of the section sec 3 - > 60 n/s a) for east subtract 90 .1) if less than 0, add 360 b) for west subtract from 270 .1) if less than 0, add 360 c) for north subtract 60 d) for south subtract from 90 3. divide resulting values by 0.00017166137695312500 (360/2^21) 4. convert each of the integers to 21-digit binary 5. adjust latitude value for north / south section a) for north set bit A(21) b) for south clear bit A(21) 6. bit interleave latitude, longitude into 42-bit result 7. prepend the 2-bit section number 8. prepend the 4-bit FP xxxx to form 48-bit prefix Examples The examples in the tables below highlight the difficulty of aligning technical details of bit patterns with human meaningful text strings. One of the explicit goals of the first table is to identify the very large scopes devoid of geo-political context, Hain Expires April 2010 7 An IPv6 Provider-Independent Global October 2009 Unicast Address Format while recognizing the need to provide something that an operator can relate to as the resolution becomes finer grained. In any case these are only descriptive examples, and actual implementations would be based on engineering requirements. The Reference field in the prefix MUST be calculated for a site at 44-bits, but MAY be used in routing calculations on any bit boundary appropriate for the topology. For human reference the approximate surface area covered by each value of the grid is provided in the table below. The size in meters is based on rounded values for the equatorial circumference and should only be used as a conceptual guideline. bits degrees equatorial sq scope sites -------------------------------------------------------------------- 2 -> 120.00000 13358 km section 4 -> 60.00000 6679 km expanse 8 -> 15.00000 1669 km frame 12 -> 3.75 417 km zone 16 -> 0.9375 104 km region 20 -> 0.234375 26 km metro 16777216 24 -> 0.05859375 6.5 km city 1048576 28 -> 0.0146484375 1.6 km locality 65536 32 -> 0.003662109375 407 m neighborhood 4096 36 -> 0.00091552734375 102 m block 256 40 -> 0.0002288818359375 25 m lot 16 44 -> 0.000057220458984375 6.4 m site 1 The location addressed as x000:0000:0000::/48 covers an area in the Indian Ocean ~ 6.4 m on a side, north and east of the point 60 degrees south - 90 degrees east. Specifically the WGS84 values between, 60s to 59.99994s and 90e to 90.00005e. Interleave process detail: A bit interleave is used to allow aggregation on arbitrary granularities. From the left after the 4-bit format prefix, bits 123 & 122 will identify the section using the table: 00 - 90e 60s through 209.99999e 59.99999n 01 - 210e 60s through 329.99999e 59.99999n 10 - 330e 60s through 89.99999e 59.99999n 110 - 90e 90s through 89.99999e 59.99999s 111 - 90e 60n through 89.99999e 90n Example: Mont Orohena, Tahiti 17.62000 s 149.48000 w This location is in section 01, where the coordinates normalize to: A - 42.38 ; O - 0.52 Hain Expires April 2010 8 An IPv6 Provider-Independent Global October 2009 Unicast Address Format dividing those values by 120/2^21 returns: A - 740644 ; O - 9087 converting those to hex results in: A - B4D24 ; O - 237F with binary equivalent from which the bits are interleaved: A - 0 1011 0100 1101 0010 0100 ; O - 0 0000 0010 0011 0111 1111 A(21)---------------------(0); O(21)---------------------(0) A(21)O(21) A(20)O(20)A(19)O(19) A(18)O(18)... A(1)O(1)A(0)O(0) 00 1000 1010 0010 0100 1010 0111 0001 1101 0111 0101 The 6 bits of FP and section ID are prepended with the final result: x48A:24A7:1D75::/48 Interleave examples: Region section lat section long bit interleave --------------------------------------------------------- W. Europe (west) 1C0000 : 000000 -> xAA0:0000:0000:: W. Europe (east) 1C0000 : 080000 -> xAE0:0000:0000:: S. Africa 070000 : 080000 -> x86A:0000:0000:: NE Africa 148000 : 0C8000 -> xA70:0000:0000:: E. Europe 1C0000 : 110000 -> xBA1:0000:0000:: C. Asia 148000 : 000000 -> x220:8000:0000:: E. Asia 190000 : 0C0000 -> x2D2:0000:0000:: Australia 070000 : 0C0000 -> x07A:0000:0000:: Alaska 020000 : 0A0000 -> xE4C:0000:0000:: NW US 1C0000 : 088000 -> x6E0:4000:0000:: Central America 148000 : 0D0000 -> x671:8000:0000:: SE US 190000 : 100000 -> x782:0000:0000:: South America 070000 : 100000 -> x52A:0000:0000:: NW Africa 100000 : 038000 -> xA05:4000:0000:: S Pole - 90.00000 s 90.00000 e xC00:0000:0000:: N Pole - 90.00000 n 90.00000 e xF5D:DDDD:DDDD:: Airport location examples: MIA - 25.78000 n 80.28000 w x72C:E3BF:E8D9:: ATL - 33.63000 n 84.42000 w x781:BF7A:F4F9:: IAD - 38.93000 n 77.45000 w x78D:3942:C7FF:: JFK - 40.63000 n 73.77000 w x798:B327:DDB5:: ORD - 41.97000 n 87.90000 w x78A:4A57:1978:: DEN - 39.85000 n 104.70000 w x6D8:8910:3DE6:: SFO - 37.62000 n 122.37000 w x69D:11D4:0F13:: LAX - 33.93000 n 118.40000 w x6C2:14F1:25C6:: SAN - 32.73000 n 117.18000 w x6C0:DA88:62AD:: Hain Expires April 2010 9 An IPv6 Provider-Independent Global October 2009 Unicast Address Format ANC - 61.16000 n 150.00000 w xE44:46CC:6C66:: SYD - 33.97000 s 151.17000 e x128:BA55:FBDF:: NRT - 35.75000 n 140.37000 e x2D3:94D4:C195:: DEL - 28.55000 n 77.01000 e xB7A:C2E3:051F:: CAI - 30.10000 n 31.40000 e xB80:117D:E30E:: CPT - 33.95000 s 18.60000 e x878:FF19:7284:: CDG - 49.00000 n 2.53000 e xAE2:4652:4716:: LHR - 51.47000 n 0.350000 w xAB7:DEC2:89EF:: GIG - 22.80000 s 42.23000 w x5D2:EDDB:8163:: SCL - 33.38000 s 70.78000 w x53B:0682:2119:: MEX - 19.43000 n 99.07000 w x673:49B8:798E:: U.S. postal examples: Locations within a 600km square - New York area (~Zone)::/12 Danvers, MA - 42.56940 n 70.94246 w x79B:2398:575C:: Cambridge, MA - 42.37704 n 71.12561 w x79B:20E0:BF51:: Boston, MA - 42.21300 n 71.03300 w x79B:2056:DBA2:: Providence, RI - 41.49260 n 71.24400 w x79B:0200:94EA:: Bridgeport, CT - 41.10010 n 73.12100 w x798:EA22:B031:: Upton, NY - 40.52100 n 72.53100 w x798:E4E8:4ADA:: New York, NY - 40.42510 n 74.00200 w x798:B03A:8CAB:: Newark, NJ - 40.44080 n 74.10200 w x798:A5D1:B059:: Cherry Hill, NJ - 39.93080 n 75.01754 w x78D:DD76:FA53:: Baltimore, MD - 39.17250 n 76.36400 w x78D:6E0C:5CA6:: TysonsCorner, VA - 38.55070 n 77.13500 w x78D:347E:9A88:: Reston, VA - 38.93501 n 77.35144 w x78D:3957:BF69:: Chantilly, VA - 38.88413 n 77.43544 w x78D:33E9:6FF3:: Locations within a 150km square - Miami area (~Region)::/16 Boca Raton, FL - 26.34460 n 80.21094 w x72E:4178:3A32:: DeerfiledBeachFl - 26.30956 n 80.09917 w x72E:4425:5611:: CoralSprings, FL - 26.27140 n 80.25558 w x72E:4143:2F68:: PompanoBeach, FL - 26.23153 n 80.12346 w x72C:EEAC:8FF3:: FtLauderdale, FL - 26.12156 n 80.12878 w x72C:EE2B:5E8A:: PembrokePines,FL - 26.02427 n 80.24018 w x72C:EB44:923B:: South Miami, FL - 25.70025 n 80.30141 w x72C:E39C:2B95:: Key Biscayne, FL - 25.69210 n 80.16248 w x72C:E3D7:E98D:: Homestead, FL - 25.47664 n 80.48385 w x72C:E0CB:4E24:: Locations within a 40km square - Chicago area (~Metro)::/20 Skokie, IL - 42.03617 n 87.73283 w x78A:4B66:D89B:: Schaumburg, IL - 42.05807 n 88.04819 w x78A:4A3B:0DDC:: Chicago, IL - 41.88585 n 87.61812 w x78A:4C8E:69C4:: Oak Brook, IL - 41.78910 n 87.94009 w x78A:4870:E1F7:: DownersGrove, IL - 41.80343 n 88.01375 w x78A:4837:E16A:: Orland Park, IL - 41.61938 n 87.84225 w x78A:4387:1A7B:: Hain Expires April 2010 10 An IPv6 Provider-Independent Global October 2009 Unicast Address Format Examples of existing exchange points & potential prefixes: LINX, London - 51.50717 n 0.00117 w xAB7::/12 AMS-IX, Amsterdam - 52.3025 n 4.93533 e xAE3::/12 NYIIX, NY - 40.70350 n 74.00783 w x798::/16 STARTAP, Chicago - 41.87650 n 87.63467 w x78A::/16 LAIIX, LA - 34.04233 n 118.24383 w x6C2:171F::/20 PAIX, Palo Alto - 37.44083 n 122.15683 w x697:BEDA::/20 SIX, Seattle - 47.61321 n 122.33799 w x6B5:9E08::/20 NSPIXP6, Tokyo - 35.62500 n 139.90750 e x2D3::/16 SII, Shanghai - 31.30200 n 121.49167 e x2C0::/16 A Geographic Multicast address format: A public service or network administrator may wish to notify all nodes within a given geographic area without requiring those clients to figure out all the appropriate groups to join. Using the all- nodes group ID 0000:0001, with RFC 3306 [5}, the PI prefix provides a means to identify the region for the target multicast. | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+--------+----------------+----------+ |11111111|flgs|scop|reserved| plen | network prefix | group ID | +--------+----+----+--------+--------+----------------+----------+ Using this mechanism a weather warning or other public alert could be sent to participants in an area without the alerting service needing to individually contact the subscribers PA addresses, or the subscribers needing to know which specific groups to join (ie: connect me to all alerts within a 100km radius). Alternatively, specific groups could be defined for each public alert type, and the alert radius defined here would still apply. Subnet Identifier (see RFC Editor considerations) If 0001 were selected for the FP, this document would modify both RFC 4291 & 3587 to extend the 64 bit Interface ID field size, and 16 bit Subnet ID field into the upper half of the Format Prefix 000 space. Technical Motivation The design choice for the size of the fields in the Geographic address format was based on the need to separate the address allocation from the service provider (specifically to address the scaling problems that mechanism creates when sites connect to multiple providers), the need to preserve the subnet structure Hain Expires April 2010 11 An IPv6 Provider-Independent Global October 2009 Unicast Address Format defined in [6], and the resolution of readily available handheld GPS receivers. General Considerations The operational considerations : of human readability in the routing prefix lengths versus the topology realities used by the routing system are network dependent and outside the scope of this document. The technical considerations : the accuracy of the WGS-84 location reading versus the margin of error for a 21-bit resolution. When available, 5 places of significance right of decimal in lat/long readings results in 1 meter increment, or well within rounding error of 21 bit resolution : while between +/- 15 degrees latitude, using only 4 places of significance results in 11.1 meter increments which is considerably longer than the side ~ 6.4 m of the area being identified. (At this time, readily available consumer-grade GPS receivers are generally accurate to 3 meters, while commercial grade receivers have augmentation for sub-1 meter accuracy.) Alignment of the site boundary supporting SLA with the [6] format allows sites to use a consistent subnet structure. IANA Considerations A 4-bit format prefix for PI address use needs to be assigned. The format prefix 0001 is recommended to avoid breaking up any of the unassigned 3-bit spaces. RFC Editor Considerations The format prefix binary value in the xxxx examples needs to be replaced by the value assigned by IANA. The format prefix hex value in the xhhh: examples needs to be replaced by the value assigned by IANA. The Subnet Identifier section, and the matching comment in the references section should be removed if the IANA assigned prefix is not in 0000::/3. It should be replaced with a pointer to (ARCH) for global scope allocations. Security Considerations While there may be concerns about location privacy raised by this scheme, there is nothing inherent in this address format that would raise any more security considerations than any other global addressing format. If location privacy were an issue it would be Hain Expires April 2010 12 An IPv6 Provider-Independent Global October 2009 Unicast Address Format wise to avoid this mechanism in favor of location independent mechanisms such as Provider-Aggregatable allocations. Appendix A: #!/usr/bin/perl # # This is a derivative of a script by mcr@sandelman.ca. # http://www.sandelman.ottawa.on.ca/SSW/ietf/geo-pi/ # # The primary modification was to adjust for the change # to sections and origin. This version also adds an # option for decimal degree input format. # # alh-ietf@tndh.net 2002/12/31 # print "Please select format 1) dd.mm.ss or 2) dd.ddddd: "; chop($fmt=); print "Use minus (-) for south or west values. \n"; print "Please enter your lattitude: "; chop($lat=); print "Please enter your longitude: "; chop($long=); if($fmt == 1) { ($longdeg, $longmin, $longsec) = split(/ /, $long); ($latdeg, $latmin, $latsec) = split(/ /, $lat); if($longdeg < 0) { $longdeg = 360 + $longdeg; } if($latdeg < 0) { $latdeg = -$latdeg; $south = 1; } $wgs84long = $longdeg + ($longmin / 60) + ($longsec / 360); $wgs84lat = $latdeg + ($latmin / 60) + ($latsec / 360); if($south == 1) { $wgs84lat = -$wgs84lat; } } else { if ($long < 0) { $wgs84long = 360 + $long; } else { $wgs84long = $long; } } Hain Expires April 2010 13 An IPv6 Provider-Independent Global October 2009 Unicast Address Format $wgs84lat = 90 + $lat; # Origin is now south pole @ 0 degrees if ($wgs84lat >= 30) { if ($wgs84lat < 150) { $seclat = $wgs84lat - 30; if ($wgs84long >= 90) { if ($wgs84long < 210) { $section = 0; $seclong = $wgs84long - 90; } elsif ($wgs84long < 330) { $section = 1; $seclong = $wgs84long - 210; } else { $section = 2; $seclong = $wgs84long - 330; } } else { $section = 2; $seclong = $wgs84long + 30; } } else { $section = 7; $seclat = $wgs84lat - 150; $seclong = $wgs84long - 90; } } else { $section = 6; $seclat = $wgs84lat; $seclong = $wgs84long - 90; } if ($seclong < 0) { $seclong = 360 + $seclong; } # Origin is now normalized to section print ("Sec Lat: $seclat \n"); print ("Sec Long: $seclong \n"); if($section < 3) { $seclong = int($seclong / 0.000057220458984375); $seclat = int($seclat / 0.000057220458984375); } else { $seclong = int($seclong / 0.00017166137695312500); $seclat = int($seclat / 0.00017166137695312500); } # convert to binary @lat = &convert_to_binary($seclat); @long = &convert_to_binary($seclong); @secbin = &convert_to_binary($section); Hain Expires April 2010 14 An IPv6 Provider-Independent Global October 2009 Unicast Address Format print "Raw sec:",join('', @secbin),"\n"; print "Raw lat: ",join('', @lat),"\n"; print "Raw long:",join('', @long),"\n"; # clean off excess leading 0's foreach $i (1..11) { shift(@lat); shift(@long); } foreach $i (1..29) { shift(@secbin); } # interleave bits @geopi=(); if ($section > 3) { foreach $i (1..3) { $secid = shift(@secbin); push(@geopi, $secid); } } else { shift(@secbin); foreach $i (1..2) { $secid = shift(@secbin); push(@geopi, $secid); } } my($o,$a); foreach $i (1..21) { $o = shift(@long); $a = shift(@lat); if ($section > 3 && $i == 1) { # skip this bit in polar sections } else { push(@geopi, $a); } push(@geopi, $o); } print "Digits ",join('', @geopi),"\n"; print "Lat: $lat Long: $long -> x"; foreach $i (0..10) { @nibble = @geopi[($i*4)..($i*4+3)]; $nibble = $nibble[0]*8 + $nibble[1]*4 + $nibble[2]*2 + $nibble[3]; print sprintf("%x", $nibble); if($i==2 || $i==6) { print ":"; } } print "\n"; Hain Expires April 2010 15 An IPv6 Provider-Independent Global October 2009 Unicast Address Format exit; sub convert_to_binary { local($num)=@_; local($i, @digits); @digits=(); foreach $i (1..32) { if($num & 1) { unshift(@digits, 1); } else { unshift(@digits, 0); } $num = $num >> 1; } return @digits; } Appendix B: Extended resolution The basic mechanism provides allocation of /48's in a two dimensional grid. At the same time there has been interest in finer grained resolution, as well as the ability to express altitude. The optional extended resolution provides three dimensional cube resolution allocations. It is expected that allocations using this extension will continue to be aggregated such that the prefix announcement into the public routing table is no longer than a /48. If that expectation will not be met, the extension will require a different format prefix. Options for encoding the bits beyond the lat-long grid as altitude result in various depths when the goal is a cube. 44 bit lat-long grid + 16 bit altitude 44 -> 0.000057220458984375 6.4 m site ~6.4 m cube to 419 km (260 mi) depth 46 bit lat-long grid + 14 bit altitude 46 -> 0.0000286102294921875 3.2 m room ~3.2 m cube to 52 km (172,000 ft) depth 48 bit lat-long grid + 12 bit altitude 48 -> 0.0000143051147460937 1.6 m desk ~1.6 m cube to 6.5 km (21,000 ft) depth Hain Expires April 2010 16 An IPv6 Provider-Independent Global October 2009 Unicast Address Format 50 bit lat-long grid + 10 bit altitude 50 -> 0.0000071525573730468 0.8 m chair ~.8 m cube to 815 m (2,600 ft) depth *** the following text about 3 dimensional support is broken and needs to be reworked. It inadvertently assumes the terrain map is always the surface of the WGS 84 ellipsoid. It may be appropriate to consider the altitude axis on a logarithmic scale, though that would cause resolution differences between identical buildings where one is at sea level while the other sits on a mountain top. *** At this time, the tallest buildings are about 500m, so 50 bit lat/long + 10 bit altitude would appear to provide the best fit for a 3D use. This requires a WGS84 measurement resolution of 7 decimal places (beyond the capabilities of current consumer devices). If there is a strong interest in addressing mobile objects at higher altitudes, the grid would need to remain somewhat coarse to allow for the desired height. Also, until more accurate measurement equipment is readily available in handheld form to be carried by every L1 installer, there will be little ability to take advantage of the finer grid. There has also been some interest expressed in negative altitude values. While the opportunity exists for networks to exist below the surface of the WGS-84 ellipsoid, the likelihood of wide-scale use is very small. Coupling that with the already insufficient number of bits to encode the potentially interesting positive values above the surface at high granularity; makes it very unlikely that there will be broad community support for below the surface allocations. If on the other hand there were substantial interest in below the surface use, and equipment accuracy remains just 5 decimal places, it would make sense to use the 44 bit lat/long and 16 bit altitude approach. In this case, the most significant bit of 0 would designate above the surface, while 1 designates below. This would result in one subnet per ~6.4 m cube, to an approximate depth of + or - 210 km. References The Overview of the IPv6 Address, Site Level Aggregator, and Interface ID portions of this text are directly copied from RFC 3587 for consistency. 1 RFC-2460 Deering, S., Hinden, B. "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 2 RFC-4291 Hinden, B., Deering, S. "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 4291, February 2006. Hain Expires April 2010 17 An IPv6 Provider-Independent Global October 2009 Unicast Address Format 3 RFC-2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 http://en.wikipedia.org/wiki/WGS84 5 RFC-3306, B. Haberman, D. Thaler., "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002 6 RFC-3587, Hinden, B., Nordmark, E., Deering, S., IPv6 Global Unicast Address Format", RFC 3587, August 2003. Hain Expires April 2010 18 Acknowledgments Early feedback was provided by Iljitsch van Beijnum, Brian Carpenter, Sean Doran, Geoff Huston, Andrew Main, Brian Haberman, Michael H. Lambert and Michel Py. Thanks to Michael Richardson for providing the initial Perl script. Calvin Newport's research efforts at MIT provided the innovative use case in MANET networks. Author's Addresses Tony Hain Cisco Systems 500 108th Ave. N.E. Suite 500 Bellevue, Wa. 98004 Email: alh-ietf@tndh.net Hain Expires April 2010 19