| Addressing Possibilities for IPv6
By Steve Silverman
Houston Associates
One fact that is often overlooked is that the first critical addressing
problem in the IPv4 space was not the lack of addresses, but rather, the
fact that there were too many addresses in the routing tables, leading
to a router table explosion. Network addresses were given out almost at
random and each network had to be advertised to everyone in the world.
This had the advantage that a network could be relocated and communications
reestablished very quickly, an important criterion in the original design.
However, the processing load on each router and the resulting routing
table size were directly proportional to the size of the Internet. Consequently,
the original design did not scale.
In the Internet Engineering Task Force (IETF), lack of scalability is
the ultimate insult. The solution to this problem was Classless Internet
Domain Routing (CIDR). Large blocks of address space were allocated to
large Internet Service Providers (ISPs). Each ISP would then allocate
part of that block to lower-tier ISPs or the networks. This allowed each
ISP to aggregate many of their customers into one routing advertisement,
minimizing both the number of routing advertisements and the resultant
processing.
When the time came to design IPv6 addressing, we were quite aware of
the foregoing history and the routing scalability issue. Therefore, we
attempted to push users to a hierarchical addressing model. The address
includes a 13-bit Top Level Aggregation (TLA) field, limiting the routing
table entries for this type of address to 8K entries. These addresses
are to be issued to top-level Internet Service Providers. User organizations,
in turn, are to get their network addresses from their ISPs. In the case
of multiple levels of providers, the lower-level ISPs would use part of
the upper-level ISP’s address space, thus maximizing address aggregation.
This does not treat the issue of multihoming unless the organization
gets one of the TLA addresses, which is not a generally-acceptable solution.
One obvious solution to multihoming would be for a user organization to
use one network address for each ISP and have the Domain Name System (DNS)
server return multiple IP addresses (one for each ISP) to a query for
a name. Unfortunately, this easy solution was rejected by the IETF many
years ago, in the belief that it would place too much of a burden on the
DNS server. How a slightly longer record would place a significant additional
burden on a DNS server is not obvious. This is the solution in use for
IPv4/IPv6 dual stacking.
There are two major alternatives to ISP-based addressing that are being
supported by the Internet Assigned Numbers Authority (IANA) at this time.
Each of these would support provider-independent addressing and would
allow multihomed users to be accessed by multiple ISPs.
- Geospatial addressing - This uses the user’s geographic latitude
and longitude to generate an address. One proposal by Tony Hain describes
a way of using GPS values to derive a 44-bit network prefix. Because
this address is provider-independent, it solves the issue of multihoming.
(See the drafts by Tony Hain under “References” below.)
Routing entry explosion would be limited by simply filtering on overlong
prefixes from physically-remote networks. If the most-significant bits
are the same, the destination is physically near the shortened prefix.
The catch, of course, is the difference between physical proximity and
network proximity. Two networks may share the same geographic space
but not be directly connected to each other. Traffic for one should
not be routed to the other. This demonstrates a need for a local routing
protocol (and/or possibly a local network entity) that ensures that
everyone in a local area can find everyone else in the local area. One
outstanding question is the size of the area and how each area is to
be organized. As far as I know, this issue has not yet been addressed.
- Geopolitical addressing – This uses a variant of the telephone
model. If we divided the world into 250 countries and assigned each
a number, the second byte of the address could be the country code.
(The first byte would indicate that geopolitical addressing was being
used.) Each country would be responsible for assigning numbers within
its area. Many countries would prefer to retain control over this type
of issue. It is an excellent patronage opportunity and, of course, each
country understands its own needs better than a single remote bureaucracy.
A large country, in turn, could be subdivided into 250 zones. This could
lead to limited (and relatively stable) routing tables, as well as simplified
and very deterministic routing. It could alleviate the current problem
of very inefficient routing. (Current BGP routing often yields circuitous
routes.) Unfortunately, some members of the IETF would rather drink
hemlock than accept a proven solution used by the International Telecommunications
Union (ITU), especially a solution that predates the Internet.
While the IETF is probably not going to move in this direction, the
ITU has noticed that the Internet is assuming much of the telecommunications
functionality over which it used to preside. It is now looking into
Internet governance. The IANA functionality would certainly be an obvious
place to start. Much of the world is unhappy with the IPv4 numbering
experience. Given the lack of current government control of the Internet,
an ITU attempt to control it would be an interesting exercise. We shall
see what happens.
References
The following documents are available at http://www.ietf.org/rfc.html:
- RFC 1518: An Architecture for IP Address Allocation with CIDR
- RFC 1519: Classless Inter-Domain Routing (CIDR): An Address Assignment
and Aggregation Strategy
- RFC 2373: IP Version 6 Addressing Architecture
- RFC 2374: An IPv6 Aggregatable Global Unicast Address Format
The following drafts by Tony Hain are expired but still available at
: http://www.ietf.org/ID.html:
- draft-hain-ipv6-pi-addr-07: An IPv6 Provider-Independent Global Unicast
Address Format
- draft-hain-ipv6-pi-addr-use-07: Application and Use of the IPv6 Provider-Independent
Global Unicast Address Format
Mr. Hain has promised to submit updates for the upcoming meeting in August.
|