One document matched: draft-hain-ipv6-pi-addr-03.txt
Differences from draft-hain-ipv6-pi-addr-02.txt
IPv6wg
Internet Draft T. Hain
Document: draft-hain-ipv6-pi-addr-03.txt Cisco
Expires: March 2003 September 2002
An IPv6 Provider-Independent
Global Unicast Address Format
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
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 [2] and the
"IPv6 Addressing Architecture" [3]. 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 [4].
Hain Expires March 2003 1
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
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..............................................................5
Core routing table examples:........................................6
Airport location examples:..........................................6
U.S. postal examples:...............................................7
Locations within a 600km square - New York area (~Zone)::/14.......7
Locations within a 150km square - Miami area (~Region)::/18........7
Locations within a 40km square - Chicago area (~Metro)::/22........7
Site-Level Aggregation Identifier.....................................8
Interface ID..........................................................8
Technical Motivation..................................................9
General Considerations................................................9
IANA Considerations..................................................10
RFC Editor Considerations............................................10
Security Considerations..............................................10
References...........................................................12
Acknowledgments......................................................13
Author's Addresses...................................................13
Introduction
This document defines a Provider-Independent global unicast address
format for IPv6 address assignments. The companion document APPL [5]
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
uninhabitable 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
Hain Expires March 2003 2
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
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 [6]. 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
[7] latitude and longitude which represents the center of a nominal
square ~10m on a side. (WGS-84 was selected because low-cost hand-
held devices with the necessary level of accuracy on a global scale
are readily available.) Interleaving is used to create a 44-bit
reference value from the 22-bit values corresponding to each side of
the grid. Dropping the low order nibbles increases flexibility of
assignments to sites and allows for local management by expanding
the grid scope.
Addresses defined with the Provider-Independent format prefix (IANA
assigned, recommendation to use 0001) are portable between
providers, but by definition are NOT-PORTABLE when a network
attachment point changes geographic locations. Entities that expect
identifiers 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 [5] for usage
discussions), allowing movement of any specific facility without
impacting all communications.
While this format is based on geographic location, it does not
require renumbering devices as they move around within a 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.
** Geography provides distinguished meaning to the term 'home
address'. One possibility would be for all nodes to use Mobile-IPv6
[8] with the PI as home and whatever current provider as care-of.
Hain Expires March 2003 3
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
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.
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. The only
exception to this is the distinction made between unicast and
multicast addresses. 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 a specific
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 (IANA assigned)
(binary) Format Prefix for Provider-Independent geographic reference
global unicast addresses. The same address format could be used for
other Format Prefixes, as long as these Format Prefixes also
identify IPv6 unicast addresses. Only the "xxxx (IANA assigned)"
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 10 meters on a
side. While the prefix MAY be defined and routed on any bit boundary
length, the requirement for all service providers serving any short
prefix boundary scope to be capable of delivering traffic to all
others, will have a tendency to naturally limit the operational
choices.
Hain Expires March 2003 4
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
This document specifies the format for format prefix (FP) (IANA
assigned, recommendation to use 0001) binary.
| 4 | 44 | 16 | 64 bits |
+---+-------------------------+--------+---------------------------+
|FP | Reference | SLA | Interface ID |
+---+-------------------------+--------+---------------------------+
Creating the Provider-Independent address prefix is accomplished by
establishing the origin at 0e 90s, dividing the WGS-84 latitude and
longitude readings in degrees (for latitudes between +/- 15 degrees
measured to 5 places right of the decimal ie: deg.xxxxx) by the
incremental angle. For 22-bit values the incremental angle is
0.0000858306884765625 degrees (360/(2^22)). This will result in
uniquely identifiable areas with 2096832 along the latitude axis and
4193664 along the longitude axis. The specific sequence for address
formation is:
1. find demarcation WGS-84 value in degrees to 5 decimal places
2. adjust for origin at 0e 90s
a) for east add 0 to the value
b) for west subtract the value from 360
c) for north add 90 to the value
d) for south subtract the value from 90
3. divide resulting degree values by 0.0000858306884765625
4. convert each of the integers to 22-digit binary
5. bit interleave latitude, longitude into 44-bit result
6. prepend FP xxxx (IANA assigned) 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. A specific instance is the fact is that there are at
least 2 prefix announcements (covering each side of the meridian)
for the text string matching the political entity known as 'West
Europe'. One of the explicit goals of the first table is to identify
the very large nibble-based 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 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 4-bit 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.
Hain Expires March 2003 5
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
bits degrees nominal square scope sites
--------------------------------------------------------------------
4 -> 90.00000 10000 km octant
8 -> 22.50000 2500 km expanse
12 -> 5.625000 600 km zone
16 -> 1.406250 150 km region
20 -> 0.3515625 40 km metro 16777216
24 -> 0.087890625 10 km city 1048576
28 -> 0.02197265625 2.5 km locality 65536
32 -> 0.0054931640625 600 m neighborhood 4096
36 -> 0.001373291015625 150 m block 256
40 -> 0.00034332275390625 40 m lot 16
44 -> 0.0000858306884765625 10 m site 1
The location addressed as X000:0000:0000::/48 covers an area ~ 10 m
on a side, centered at the South Pole with a defined East / West
origin at 0.
S Pole û 90.00000 s 0.00000 e X000:0000:0000::
N Pole û 90.00000 n 0.00000 e X800:0000:0000::
Core routing table examples:
Region lat long bit interleave
---------------------------------------------------------
W. Europe (west) 180000 : 3C0000 -> X7D0:0000:0000::
W. Europe (east) 180000 : 000000 -> X280:0000:0000::
S. Africa 0A0000 : 000000 -> X088:0000:0000::
NE Africa 130000 : 030000 -> X20F:0000:0000::
E. Europe 180000 : 060000 -> X294:0000:0000::
C. Asia 130000 : 0C0000 -> X25A:0000:0000::
E. Asia 160000 : 180000 -> X368:0000:0000::
Australia 0A0000 : 180000 -> X1C8:0000:0000::
Alaska 1C0000 : 240000 -> X6B0:0000:0000::
NW US 180000 : 2B0000 -> X6C5:0000:0000::
Central America 130000 : 2E0000 -> X65E:0000:0000::
SE US 160000 : 300000 -> X728:0000:0000::
South America 0A0000 : 300000 -> X588:0000:0000::
NW Africa 100000 : 3D0000 -> X751:0000:0000::
Airport location examples:
MIA û 25.78000 n 80.28000 w X721:C766:317C::
ATL û 33.63000 n 84.42000 w X722:FFD9:D587::
IAD û 38.93000 n 77.45000 w X72C:ADCF:8EEE::
JFK û 40.63000 n 73.77000 w X72E:5E86:46B3::
ORD û 41.97000 n 87.90000 w X72A:3B7D:4386::
DEN û 39.85000 n 104.70000 w X67B:1626:d7F8::
SFO û 37.62000 n 122.37000 w X66C:8F54:5854::
LAX û 33.93000 n 118.40000 w X66C:5585:1F52::
SAN û 32.73000 n 117.18000 w X667:A647:8224::
Hain Expires March 2003 6
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
ANC û 61.16000 n 150.00000 w X699:B3BB:3B33::
SYD û 33.97000 s 151.17000 e X16C:51DD:544E::
NRT û 35.75000 n 140.37000 e X368:779A:1433::
DEL û 28.55000 n 77.01000 e X273:470A:727F::
CAI û 30.10000 n 31.40000 e X233:3693:A5A8::
CPT û 33.95000 s 18.60000 e X087:BA7C:E823::
CDG û 49.00000 n 2.53000 e X280:9F2D:049A::
LHR û 51.47000 n 0.350000 w X7D7:5D28:2B24::
GIG û 22.80000 s 42.23000 w X5CA:BF5C:2380::
SCL û 33.38000 s 70.78000 w X58D:1644:E769::
MEX û 19.43000 n 99.07000 w X65E:3E25:253E::
U.S. postal examples:
** (U.S. selected only because the lat/long was easy to find)
Locations within a 600km square - New York area (~Zone)::/14
Danvers, MA û 42.56940 n 70.94246 w X72F:9607:3912::
Cambridge, MA û 42.37704 n 71.12561 w X72F:91C4:DD54::
Boston, MA û 42.21300 n 71.03300 w X72F:9157:0D93::
Providence, RI û 41.49260 n 71.24400 w X72F:3911:63EF::
Bridgeport, CT û 41.10010 n 73.12100 w X72F:20A8:845C::
Upton, NY û 40.52100 n 72.53100 w X72F:0B65:086A::
New York, NY û 40.42510 n 74.00200 w X72E:59EA:A19C::
Newark, NJ û 40.44080 n 74.10200 w X72E:5B05:C043::
Cherry Hill, NJ û 39.93080 n 75.01754 w X72E:46C3:71DE::
Baltimore, MD û 39.17250 n 76.36400 w X72C:BE78:E194::
TysonsCorner, VA û 38.55070 n 77.13500 w X72C:B2C9:6AA0::
Reston, VA û 38.93501 n 77.35144 w X72C:ADDF:EE96::
Chantilly, VA û 38.88413 n 77.43544 w X72C:ADC7:D985::
Locations within a 150km square - Miami area (~Region)::/18
Boca Raton, FL û 26.34460 n 80.21094 w X721:CDF9:EA84::
DeerfiledBeachFl û 26.30956 n 80.09917 w X721:D8A6:6941::
CoralSprings, FL û 26.27140 n 80.25558 w X721:CDCF:9D64::
PompanoBeach, FL û 26.23153 n 80.12346 w X721:D883:B75E::
FtLauderdale, FL û 26.12156 n 80.12878 w X721:D821:B208::
PembrokePines,FL û 26.02427 n 80.24018 w X721:CD50:2C74::
South Miami, FL û 25.70025 n 80.30141 w X721:C743:9C32::
Key Biscayne, FL û 25.69210 n 80.16248 w X721:C757:653D::
Homestead, FL û 25.47664 n 80.48385 w X721:C52B:2B95::
Locations within a 40km square - Chicago area (~Metro)::/22
Skokie, IL û 42.03617 n 87.73283 w X72A:3E97:06F4::
Schaumburg, IL û 42.05807 n 88.04819 w X72A:3EC8:53B0::
Chicago, IL û 41.88585 n 87.61812 w X72A:3E58:3436::
Oak Brook, IL û 41.78910 n 87.94009 w X72A:3EF3:E7FD::
DownersGrove, IL û 41.80343 n 88.01375 w X72A:3EEC:9433::
Orland Park, IL û 41.61938 n 87.84225 w X72A:3E2C:0D25::
Hain Expires March 2003 7
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
Examples of existing exchange points & potential prefixes:
LINX, London û 51.50717 n 0.00117 w X7D7::/12
AMS-IX, Amsterdam û 52.3025 n 4.93533 e X282::/12
NYIIX, NY - 40.70350 n 74.00783 w X72E::/14
STARTAP, Chicago û 41.87650 n 87.63467 w X72A::/14
LAIIX, LA - 34.04233 n 118.24383 w X66C:5000::/20
PAIX, Palo Alto - 37.44083 n 122.15683 w X66C:9000::/20
SIX, Seattle - 47.61321 n 122.33799 w x6C4:3000::/20
NSPIXP6, Tokyo - 35.62500 n 139.90750 e x368::/16
SII, Shanghai - 31.30200 n 121.49167 e x333::/16
Site-Level Aggregation Identifier
The SLA 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 SLA ID field supports
65,535 individual subnets.
Organizations may choose to either route their SLA ID "flat" (e.g.,
not create any logical relationship between the SLA identifiers that
results in larger routing tables), or to create a two or more level
hierarchy (that results in smaller routing tables) in the SLA ID
field. The latter is shown as follows:
| n | 16-n | 64 bits |
+-----+------------+-------------------------------------+
|SLA1 | Subnet | Interface ID |
+-----+------------+-------------------------------------+
| m |16-n-m | 64 bits |
+----+-------+-------------------------------------+
|SLA2|Subnet | Interface ID |
+----+-------+-------------------------------------+
The approach chosen for structuring an SLA ID field is the
responsibility of the individual organization.
The number of subnets supported by this address format should be
sufficient for all foreseeable multi-homing uses. When the number of
multi-homed subnets exceeds 2 ^ 16 per 100 square meters of the
earth's surface, alternative allocation mechanisms may be required.
Interface ID
Interface identifiers are used to identify interfaces on a link.
They are required to be unique on that link. They may also be
Hain Expires March 2003 8
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
unique over a broader scope. In many cases an interfaces identifier
will be the same or be based on the interface's link-layer address.
Interface IDs used in the Provider-Independent global unicast
address format are required to be 64 bits long and to be constructed
in IEEE EUI-64 format [9]. These identifiers may have global scope
when a global token (e.g., IEEE 48bit MAC) is available or may have
local scope where a global token is not available (e.g., serial
links, tunnel end-points, etc.). The "u" bit (universal/local bit
in IEEE EUI-64 terminology) in the EUI-64 identifier must be set
correctly, as defined in [3], to indicate global or local scope.
The procedures for creating EUI-64 based Interface Identifiers is
defined in [3]. The details on forming interface identifiers is
defined in the appropriate "IPv6 over " specification such as "IPv6
over Ethernet" [10], "IPv6 over FDDI" [11], etc.
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 [12], and the resolution of readily
available handheld GPS receivers. Additional benefits of separation
are the ability of the site to switch providers without renumbering,
and the ability of transport connections to survive loss of
connection to one of the site's providers.
Multi-site networks are expected to internally advertise all the
appropriate natural prefixes and let the [6] rules sort it out. This
would result in systems selecting a source address that most closely
matches the destination. Thus return traffic would naturally be
directed toward the boundary site closest to the destination site
(ie: traffic would traverse the public network as little as
possible).
General Considerations
The policy considerations : about when it is appropriate to use
this address format are discussed in the companion document [5].
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 22-bit resolution. When
available, 5 places of significance right of decimal in lat/long
Hain Expires March 2003 9
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
readings results in 1 m increment, or well within rounding error of
22 bit resolution : while between +/- 15 degrees latitude, using
only 4 places of significance results in 11.1 m increments which is
longer than the side ~ 9.5 m of the grid being identified.
(Currently available consumer-grade GPS receivers are generally
accurate to 4 places.)
Alignment of the site boundary supporting SLA with the [12] 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 xhhh: in the examples needs to be replaced by the
value assigned by IANA.
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 [12] allocations.
Appendix A:
Example Perl script
#!/usr/bin/perl
#
# This piece of crap written by mcr@sandelman.ca.
#
# $Id: gen-geo-pi.pl,v 1.1 2002/04/30 01:18:24 mcr Exp $
#
# See http://www.sandelman.ottawa.on.ca/SSW/ietf/geo-pi/ for
updates.
#
print "Please enter your lattitude: ";
chop($lat=<STDIN>);
print "Please enter your longitude: ";
chop($long=<STDIN>);
print "Please enter radius of reference: ";
Hain Expires March 2003 10
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
chop($radius=<STDIN>);
($longdeg, $longmin, $longsec) = split(/ /, $long);
($latdeg, $latmin, $latsec) = split(/ /, $lat);
if($longdeg < 0) {
$longdeg = 360 - $longdeg;
}
if($latdeg < 0) {
# south
$south = 1;
# $latdeg = -$latdeg;
}
$latdeg = 90 + $latdeg;
$wgs84long = $longdeg + ($longmin / 60) + ($longsec / 360);
$wgs84lat = $latdeg + ($latmin / 60) + ($latsec / 360);
#$wgs84long = ($longdeg * 360) + ($longmin * 60) + $longsec;
#$wgs84lat = ( $latdeg * 360) + ( $latmin * 60) + $latsec;
# this is really not good, we blow 32 bits here, but turns out
# that 64 is a common factor, but we still blow 32 bits!
#$wgs84long = int(($wgs84long * (4194304/64)) / (129600/64));
#$wgs84lat = int(($wgs84lat * (4194304/64)) / (129600/64));
$wgs84long = int($wgs84long / 0.0000858306884765625);
$wgs84lat = int($wgs84lat / 0.0000858306884765625);
# convert to binary
@lat = &convert_to_binary($wgs84lat);
@long = &convert_to_binary($wgs84long);
print "Raw lat: ",join('', @lat),"\n";
print "Raw long:",join('', @long),"\n";
# need to shift @lat/@long along a bit.
foreach $i (1..10) {
shift(@lat);
shift(@long);
}
@geopi=();
foreach $i (1..22) {
my($a,$b);
$a = shift(@lat);
$b = shift(@long);
push(@geopi, $a);
push(@geopi, $b);
}
print "Digits ",join('', @geopi),"\n";
print "Lat: $lat Long: $long -> X";
Hain Expires March 2003 11
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
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) {
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 2374
for consistency.
1 RFC-2026 Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
2 RFC-2460 Deering, S., Hinden, B. "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
3 RFC-2373 Hinden, B., Deering, S. "IP Version 6 Addressing
Architecture", RFC 2372, July 1998.
Hain Expires March 2003 12
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
4 RFC-2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
5 APPL, draft-hain-ipv6-PI-addr-use-03.txt, Hain, T., " Application
and Use of the IPv6 Provider-Independent (Geographic Reference)
Global Unicast Address Format", Aug 2002.
6 addr-selection, Draves, R., " Default Address Selection for
IPv6", draft-ietf-ipngwg-default-addr-select-04.txt, May 2001.
7 http://www.wgs84.com/files/wgsman24.pdf
8 mobile-ipv6, Johnson, D., Perkins, C., " Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-13.txt, November 2000
9 IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html,
March 1997.
10 RFC-2464, Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
11 RFC-2467, Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC 2467, December 1998.
12 RFC-2374, Hinden, B., O'Dell, M., Deering, S., " An IPv6
Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
Acknowledgments
Early feedback was provided by Iljitsch van Beijnum, Brian
Carpenter, Sean Doran, and Geoff Huston. Thanks to Michael
Richardson for providing the initial Perl script, and Michael H.
Lambert for suggesting the alternate origin.
Author's Addresses
Tony Hain
Cisco Systems
500 108th Ave. N.E. Suite 400
Hain Expires March 2003 13
An IPv6 Provider-Independent Global Unicast September
Address Format 2002
Bellevue, Wa. 98004
Email: alh-ietf@tndh.net
Hain Expires March 2003 14
| PAFTECH AB 2003-2026 | 2026-04-23 06:04:06 |