One document matched: draft-hain-ipv6-pi-addr-10.txt
Differences from draft-hain-ipv6-pi-addr-09.txt
Internet Draft T. Hain
Document: draft-hain-ipv6-pi-addr-10.txt Cisco
Expires: February 2007 August 2006
An IPv6 Provider-Independent
Global Unicast Address Format
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 30, 2007.
Abstract
This document defines an IPv6 Provider-Independent 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 February 2007 1
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
Status of this Memo...................................................1
Abstract..............................................................1
Conventions used in this document.....................................1
Introduction..........................................................2
Overview of the IPv6 Address..........................................4
IPv6 Provider-Independent Global Unicast Address Format...............4
Examples..............................................................6
Extended resolution.................................................7
Interleave process detail:..........................................8
Interleave examples:................................................8
Airport location examples:..........................................9
U.S. postal examples:...............................................9
Locations within a 600km square - New York area (~Zone)::/12.......9
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:........10
A Provider Independent Multicast address format:.....................10
Subnet Identifier....................................................11
Technical Motivation.................................................11
General Considerations...............................................11
IANA Considerations..................................................12
RFC Editor Considerations............................................12
Security Considerations..............................................12
Appendix A:..........................................................12
References...........................................................16
Acknowledgments......................................................17
Author's Addresses...................................................17
Introduction
This document defines a Provider-Independent global unicast address
format for IPv6 address allocation. The companion document APPL [4]
discusses the appropriate use of this address format. 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.
The Provider-Independent format 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 known consumption of address space assigned to
Hain Expires February 2007 2
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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.
This format is expected to work well for organizations with multiple
sites distributed geographically when used concurrently with address
selection rules [5]. As each end system will select from its
available source set the address that has the longest match with any
particular destination, response packets from Provider-Independent
destination sites will naturally find the source network demarcation
point with the public Internet that is closest to the destination
site. While this does not assure symmetry, it does help localize any
differences.
The basic mechanism is an Earth surface location defined by WGS-84
[6] 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
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.
Addresses defined with the Provider-Independent 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 set of the
available prefixes (see companion document [4] for usage
discussions), allowing movement of any specific facility without
impacting all communications.
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. The only time a renumbering
event may be required is when the demarcation point to the public
Internet changes. 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.
Hain Expires February 2007 3
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
The number of subnets supported by this address format should be
sufficient for a variety of uses.
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 [7], 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"
(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 Provider-Independent 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 7). Only the xxxx
Format Prefix is defined here.
IPv6 Provider-Independent Global Unicast Address Format
Provider-Independent 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
Hain Expires February 2007 4
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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 Provider-Independent 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
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
Hain Expires February 2007 5
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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,
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.
Hain Expires February 2007 6
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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.
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
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.
Hain Expires February 2007 7
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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.
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
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
---------------------------------------------------------
Hain Expires February 2007 8
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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::
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::
Hain Expires February 2007 9
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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::
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 Provider Independent 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, the PI prefix provides a
means to identify the region for the target multicast.
Hain Expires February 2007 10
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
| 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). Nodes participating
in such a service would be listening to the all-nodes group
hierarchy for the geographic range they are interested in.
Subnet Identifier
(see RFC Editor considerations)
With a 0001 FP, this document modifies both RFC 3513 & 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.
The Subnet ID field is used by an individual organization to create
its own local addressing hierarchy and to identify subnets. This is
analogous to subnets in IPv4 except that most organizations have a
much greater number of subnets. The 16-bit Subnet ID field supports
65,535 individual subnets.
| 16 | 64 bits |
+------------+-------------------------------------+
| Subnet | Interface ID |
+------------+-------------------------------------+
Technical Motivation
The design choice for the size of the fields in the Provider-
Independent 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 defined in [8], and the resolution of readily
available handheld GPS receivers.
General Considerations
The policy considerations : about when it is appropriate to use
this address format are discussed in the companion document [4].
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.
Hain Expires February 2007 11
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
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 [8] 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 000/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
wise to avoid this mechanism in favor of location independent
mechanisms such as Provider-Aggregatable [8] allocations.
Appendix A:
#!/usr/bin/perl
#
# This is a derivative of a script by mcr@sandelman.ca.
Hain Expires February 2007 12
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
# 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=<STDIN>);
print "Use minus (-) for south or west values. \n";
print "Please enter your lattitude: ";
chop($lat=<STDIN>);
print "Please enter your longitude: ";
chop($long=<STDIN>);
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;
}
}
$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) {
Hain Expires February 2007 13
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
$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);
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);
Hain Expires February 2007 14
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
}
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";
exit;
sub convert_to_binary {
local($num)=@_;
local($i, @digits);
@digits=();
foreach $i (1..32) {
Hain Expires February 2007 15
An IPv6 Provider-Independent Global August 2006
Unicast Address Format
if($num & 1) {
unshift(@digits, 1);
} else {
unshift(@digits, 0);
}
$num = $num >> 1;
}
return @digits;
}
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-3513 Hinden, B., Deering, S. "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
3 RFC-2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
4 APPL, draft-hain-ipv6-PI-addr-use-10.txt, Hain, T., " Application
and Use of the IPv6 Provider-Independent (Geographic Reference)
Global Unicast Address Format", August 2006.
5 RFC-3484, Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
6 http://www.wgs84.com/files/wgsman24.pdf
7 RFC-3306, B. Haberman, D. Thaler., "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002
8 RFC-3587, Hinden, B., Nordmark, E., Deering, S., IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
Hain Expires February 2007 16
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.
Author's Addresses
Tony Hain
Cisco Systems
500 108th Ave. N.E. Suite 400
Bellevue, Wa. 98004
Email: alh-ietf@tndh.net
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hain Expires February 2007 17
| PAFTECH AB 2003-2026 | 2026-04-22 23:26:34 |