moving to IPv6

Fri Nov 7 14:01:18 UTC 1997

Karl Denninger <karl at Mcs.Net> writes:

> IPng needs to have enough *prefix* length that every autonomous system
> currently in existance or which will come into existance during its lifetime
> can have a *unique*, *single* prefix.

This has the advantage of maximizing site aggregation,
however it has the disadvantage of scaling badly with
respect to the number of sites.

> Then the whole address ownership issue becomes moot - each ASN becomes a
> prefix (heh, now that's novel - why not just use the ASN
> - duh!)

Sure, but the problem is not now who deserves a /19 but
who deserves an ASN.  Moreover, there is no plan in place
for a hierarchical distribution of AS numbers, and ASes
are not laid out very hierarchically (or in any kind of
useful order) right now.

If a very strict limit were placed on the number of ASes
in this type of Internet, then distributing connectivity
maps likely would be tractable; this leads into
discussions about a global link-state routing protocol,
some of which happen from time to time for other reasons.

However, if you are not prepared to refuse to give out AS
numbers to anyone who wants one, you will run into the
same political problems as refusing to give out
provider-independent addresses to anyone who wants some.

Alternatively, if you provide a mechanism for aggregation
of ASes (and don't go mad in the process), thus implying
hierarchical routing, then your idea is workable, except
that suddenly there is no difference between the semantics
of your ASN+IPADDR and the IPv6 provider-based addressing
scheme.  The big difference would be in the requirement
that only a fixed-size field be routed upon, which is very
much like imposing prefix-length filtering on IPv6
addresses.

The only known means for any IP-like protocol to scale to
complex topologies is hierarchical routing.  This imposes
constraints on address assignment.  There is no way around
these constraints other than abandoning topological
complexity or routing efficiency.

I believe that the functionality you are trying to achieve
is having a system in which renumbering is unnecessary
when a change is made in the physical topology, or where
address uniqueness is not guaranteed.   NAT is currently the
appropriate technology to be used in both cases, and has
the advantage that no NAT-friendly deployed software needs
to be changed to talk a new protocol.

> This kind of logical design, of course, cannot be allowed to happen within
> the realm of the Internet, which is why we'll never see it in our lifetime.

Why not?  NATs delineate two addressing scopes, and
protocol translating NATs are an extension of this.  Pablo
Bevilacqua has already pointed out an existing
implementation from OFRV.

There is no reason why a series of NATs which each border
on different IPv4 addressing scopes cannot share a common
protocol and addressing region on the "outside" of each of
these IPv4 addressing scopes.  That is, among a group of
NATs there is no strict need to run IPv4, so long as
straightforward translations into and out of the local
IPv4 addressing scopes are possible.   Consequently, there
is no reason why some part of the Internet cannot test or
even deploy your hypothetical protocol.

Personally I encourage you to go for it; there is alot we
need to learn about what ought to be "in the middle" to
keep the Internet permanently scalable, and the concept of
protocol translating NATs needs some thorough deployment
experience.

	Sean.