[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Regionally aggregatable address space for multihoming
Here is the text of a very drafty-draft I have been working on for a couple
of weeks to address this specific issue. If things are not aligning right,
try putting the font in Courier 12. Comments please.
Tony
Multi-6
Internet Draft T. Hain
Document: draft-hain-ipv6-geo-addr-00.txt Cisco
Expires: December 2001 June 2001
An IPv6 Provider Independent (Geographic) 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 [i].
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 [IPV6] and the "IPv6 Addressing
Architecture" [ARCH]. It is designed to facilitate scalable Internet
routing when sites attach to multiple service providers, by using a
geographic reference to the site. A natural byproduct of this address
allocation mechanism is that all addresses are portable 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 [ii].
Introduction
This document defines an address format for the IPv6 provider independent
global unicast address assignment based on geographic location. This address
format is expected to complement the Aggregatable [RFC 2374] format by
addressing some of the scaling concerns related to site multi-homing. Recent
observations show that sites are frequently connecting to multiple service
providers, and this breaks the base aggregation assumption in rfc 2374. The
geographic nature of this provider independent address format is designed to
provide sites with addresses which aggregate well in direct proportion to
the distance from the site. It also allows a site to change providers
without impacting the nodes or connections within a site. The mechanism
breaks down the geographic location of the site into prefix lengths that map
well into existing routing protocols. This will allow efficient routing
aggregation for single sites that connect directly to multiple providers and
for sites that connect to metropolitan scale exchanges. Sites will have the
choice to connect to either type of aggregation entity. The details about
specific site topology will be limited to the service providers that are
making the direct connections. This format will also work well for
organizations with multiple sites distributed geographically, when used
concurrently with [draft-draves-addr-selection]. As each end system will
select the source address that has the longest match with the destination,
connections will naturally find the transition point between the
organizations private network and the public Internet that is closest to the
publicly connected site.
The basic mechanism is an Earth surface location defined by WGS-84
latitude/longitude that represents the center of a nominal square
approximately 10 meters on a side. An interleave is used to create a 44-bit
address, if necessary dropping the low order nibbles allows for local
management and increases flexibility of assignments to sites by expanding
the grid scope.
While this address format is designed to support exchange-based aggregation
in a metro context, it is not dependent on exchanges for it's overall route
aggregation properties. It will provide efficient route aggregation in a
global context when providers in a metro region interconnect by whatever
means, and only announce the shorter prefix outside. Any provider announcing
a short prefix SHOULD be able to deliver packets to anywhere in the region,
either directly or through other arrangements. In the case where a service
provider does not interconnect with others in its region it MUST advertise
the longer prefixes associated with its customers.
IPv6 defines the case that nodes will have multiple addresses so having a
set of provider independent ones as well as potentially several sets of
provider dependent ones should not present any particular concerns to the
end nodes. The primary technical issue will be limitations in the size of a
DNS response packet. There may be concerns raised about timing out
connection attempts, but [addr-selection] selection rules should
consistently provide the optimal pairing of addresses.
Addresses defined with this format prefix are not portable by definition.
Entities that expect identifiers to be portable across physical location
moves MUST use alternatives such as provider-based addresses [rfc 2374] or
DNS names. Multi-site organizations SHOULD be using all the available
prefixes; so if any specific facility moved, deprecating one should be a
non-event for all but very long lifetime connections.
Another issue is the business model being flipped from the current
destination's ISP choice determines sources routing; to one of source's ISP
choice determines at least its first hop. The other consideration is this
may cause the traffic flow between ISPs to flip from dump-early to dump-late
(in smallest peering scope of destination). The number of packets carried
should remain the same, but the transit agreements may be the opposite
direction from provider-based allocations.
Question about how does an ISP find out what scope they can aggregate. If
everyone just starts announcing site specific /48's and use the upstream
pressure / feedback to correct the situation there is no need for a specific
registration. Clearly all of the significant players in a region need to
communicate well to contain the specifics, but the consequence of not doing
that is simply a larger table at the next larger boundary. Providers at the
larger scopes are motivated to encourage providers in the smaller scopes to
interconnect locally and avoid announcing the specifics any wider than
necessary.
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.
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 0001 (binary) Format Prefix
for Geographic 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 "0001" Format Prefix is defined
here.
IPv6 Geographic Global Unicast Address Format
Provider Independent addresses are organized into a nibble-based hierarchy
using a 2-bit interleave of the WGS-84 based latitude and longitude of a
site. While the available 44-bit field allows for resolution of a grid
approximately 10 meters on a side, addressing privacy concerns may require
the allocation to be at 40-bits with site assignments in that 40 meter grid
to be managed by the smallest local jurisdiction. Accommodating dense
population areas may require that the grid size be increased to 150 meters
or more to allow a sufficient number of bits in the locally assigned field
identifying the specific site. This will allow more flexible assignments for
multi-story buildings and business centers with multiple independent sites
per geographic grid. Actual assignments within a geographic grid will be a
local jurisdictional issue (matching scope jurisdiction; building owner,
community board, local government, etc.), and independent of any service
provider. The only rules are that the allocation point MUST be measured at
the center of, a grid and any overlap must be coordinated. If a grid needs
to be expanded to accommodate density, it MUST avoid or otherwise coordinate
use of any existing values that fall within its new boundaries.
In the case where the local jurisdiction acts as a local service provider to
its tenants, it MAY choose to allocate prefix lengths longer than /48 as
appropriate for the number and needs of its customers. In any case the
allocation MUST NOT exceed 64 bits in length.
In a few places there may exist regions with extreme densities (greater than
1M independent sites per square 25 km on a side) where it is not reasonable
to expand any given grid to a sufficiently large area to provide enough
addresses for local administration. Generally these are expected to be
adjacent to sizable regions of water where it is highly unlikely there will
ever be permanent Internet service provided. The local jurisdiction for
areas of extreme density may choose to map a nearby unusable grid onto an
area requiring more addresses. When this is done the jurisdiction MUST
coordinate with neighbors to avoid duplication.
This address allocation mechanism SHOULD NOT be used on a dial access
network pop, as scaling routes to sites attached this way are best addressed
through provider based allocations consistent with Aggregatable [RFC 2374].
Service provision from points of attachment for wireless nodes MAY choose to
allocate prefixes longer than 48 bits (from the site prefix for the antenna)
as appropriate for the number and needs of the customers currently attached.
In any case the allocation MUST NOT exceed 64 bits in length.
Geography provides distinguished meaning to the term 'home address'.
The basic mechanism is a 2-bit interleave of the WGS-84 latitude / longitude
values to minimize routing table size on 4-bit increments. While the prefix
length MAY be established on any nibble boundary, the requirement for all
service providers at that boundary to directly peer with all others will
naturally limit the operational choices.
Core routing SHOULD be based on best match of sparsely populated table using
fixed first 3 bytes (FP + 20 bits) to find a region.
Regional routing SHOULD be based on best match of moderately populated table
using next 2-3 bytes to find neighborhood-site.
for layer-3 exchanges to work there has to be a way to do source routing
within a region to select ixc : rest of the system dst based routing
simple directory lookup on flat 48 bit site id
if so lec would dest route within region / src route to ixc
ixc would dest route to next region
dest lec would dest route within region
Specification of the WGS-84 reference point SHOULD be the responsibility of
the layer-1 service provider, and SHOULD represent the demarcation point of
the layer-1 service. In the case where reference points overlap, the layer-1
service provider MUST coordinate the specification with the local
jurisdiction.
translation of deg.xxxxx into 44 bits of 2-bit interleaved binary
the base angle is found by dividing 360 by the 2 ^ # of bits
{ie: Microsoft Excel formula > = 360/(2^22) }
16 bits ~ 0.0054931640625 deg (grids 32763 lat - 65526 long)
18 bits ~ 0.001373291015625 deg (grids 131052 lat - 262104 long)
20 bits ~ 0.00034332275390625 deg (grids 524208 lat - 1048416 long)
22 bits ~ 0.0000858306884765625 deg (grids 2096832 lat - 4193664 long)
Formation sequence:
1. for east/west (convert all west values to east - ie: 90w = 270e)
2. divide degrees (5 significant decimal places) by 0.0000858306884765625
(5 places of significance right of decimal in lat/long readings results in 1
m increment : within rounding error of 22 bit resolution : while 4 places of
significance results in 11.1 m increments which is longer than the side ~
9.5 m of the grid being identified)
3. convert each of the integers to 22-digit binary
4. north/south (set MSB for south)
5. interleave 2-bits lat, 2-bits long into 44-bit result
(examples below)
6. convert result to 11-digit hex, insert : between digits 3-4 & 7-8
7. prepend FP 0x1 to form 12-digit hex as /48 prefix
Format
This document specifies the format for format prefix (FP) 0001 binary.
| 4 | 44 | 16 | 64 bits |
+---+---~---~---~---~~~~~-----+--------+---------------------------+
|FP | Region / Metro }{ Site | SLA | Interface ID |
+---+---~---~---~---~~~~~-----+--------+---------------------------+
The geographic reference field MUST be calculated at 44-bits, but may be
used in routing calculations on any 4-bit boundary. The approximate surface
area covered by each grid value 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 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 1000:0000:0000/48 covers an area ~ 10 m on a side,
centered at equator and the 0 meridian (Greenwich).
Core routing table examples:
Region lat long 2-bit interleave
---------------------------------------------------------
W. Europe 080000 : 000000 -> 1080:0000:0000
S. Africa 260000 : 000000 -> 1848:0000:0000
NE Africa 030000 : 030000 -> 100F:0000:0000
E. Europe 080000 : 060000 -> 1092:0000:0000
C. Asia 030000 : 0C0000 -> 103C:0000:0000
E. Asia 060000 : 180000 -> 1168:0000:0000
Australia 260000 : 180000 -> 1968:0000:0000
Alaska 0C0000 : 240000 -> 12D0:0000:0000
NW US 080000 : 2B0000 -> 12A3:0000:0000
Central America 030000 : 2E0000 -> 123E:0000:0000
SE US 060000 : 300000 -> 1348:0000:0000
South America 260000 : 300000 -> 1B48:0000:0000
NW Africa 000000 : 3D0000 -> 1331:0000:0000
Airport location examples:
MIA - 25.78 n 80.28 w 1341:A766:517A
ATL - 33.63 n 84.42 w 1344:FFB9:B387
IAD - 38.93 n 77.45 w 134A:CBAF:8EEE
JFK - 40.63 n 73.77 w 134E:3E86:26D5
ORD - 41.97 n 87.90 w 134C:5D7B:2586
DEN - 39.85 n 104.70 w 127D:1646:B7F8
SFO - 37.62 n 122.37 w 126A:8F32:3832
LAX - 33.93 n 118.40 w 126A:3383:1F34
SAN - 32.73 n 117.18 w 1267:C627:8442
ANC - 61.16 n 150.00 w 1299:D5DD:5D55
SYD - 33.97 s 151.17 e 185A:239B:332E
NRT - 35.75 n 140.37 e 105A:47BD:0165
DEL - 28.55 n 77.01 e 1047:163C:474F
CAI - 30.10 n 31.40 e 1045:5695:D80B
CPT - 33.95 s 18.60 e 1848:3187:2688
CDG - 49.00 n 2.53 e 1080:8D78:30AD
LHR - 51.47 n 0.350 w 13B7:3B48:4D42
GIG - 22.80 s 42.23 w 1B60:13F6:894C
SCL - 33.38 s 70.78 w 1B47:DAEE:2BA5
MEX - 19.43 n 99.07 w 123E:5E43:435E
N Pole - 90.00 n 0.00 e 1400:0000:0000
S Pole - 90.00 s 0.00 e 1C00:0000:0000
Routing protocol should only announce a short prefix if the router can get
to the entire concatenation, if not it will need to announce specifics.
The result is that at some point in the nibble hierarchy all service
providers in a region have to share routes, and it becomes an engineering
tradeoff between the size of the routing table, and the number of points
where peering occurs. Basically expect tier-1's to run their core routers on
a sparsely populated 8 bit table, their regional routers on a full
population of the next 8 bits, with tier-2-3's looking at moderately
populated 20 bit tables. Since 20 bits is nominally what tier-1's do today
on a global scale I don't think this is out of line for scale or
performance, and it bounds the problem to the set of providers where the
multi-homing occurs.
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 each organization has a much greater number of
subnets. The 16 bit SLA ID field support 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 but the most densely packed spaces. When the number of subnets
exceeds 2 ^ 16 per 10 meter square 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 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 aggregatable global unicast address format are
required to be 64 bits long and to be constructed in IEEE EUI-64 format
[EUI-64]. 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 [ARCH], to indicate global or local
scope.
The procedures for creating EUI-64 based Interface Identifiers is defined in
[ARCH]. The details on forming interface identifiers is defined in the
appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER],
"IPv6 over FDDI" [FDDI], etc.
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 (to address the scaling problems that mechanism creates
when sites connect to multiple providers), and the need to preserve the
subnet structure defined in [Aggregatable]. An additional benefit of
separation is the ability of the site to switch providers without
renumbering.
Multi-site networks would internally advertise all the natural prefixes and
let the [addr-selection] 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 site boundary closest
to the destination site (ie: traffic would traverse the public network as
little as possible).
Security Considerations
<Every draft should have a security section.>
Appendix
Location measurements based on WGS84
World Geodetic System 84 provides a common geodetic reference : surface of
an ellipsoid approximating the true shape of the Earth geoid.
Origin = Earth's center of mass
Z-axis = Conventional terrestrial pole - Bureau International de l'Heure
X-axis = Intersection of the reference meridian plane and the equator
Y-axis = right-handed Earth-fixed orthogonal coordinate system measured in
the plane of the equator east of the X-axis
equatorial radius = 6378137 m
flattening = 1/298.257223563 ( f = (a-b)/a or b = a - (f*a) )
pole radius = 6356752 m
equatorial circumference = 40075016 m
pole circumference = 39940650 m
pole is .33% smaller than equator
References
Significant portions of this text are directly copied from RFC 2374 for
consistency.
< Your references will be listed here. View "Page Layout" if they are not
currently visible. >
Acknowledgments
<Add any acknowledgements>
Author's Addresses
Tony Hain
Cisco Systems
500 108th Ave. N.E. Suite 500
Bellevue, Wa. 98004
Email: alh-ietf@tndh.net