Re: moving to IPv6

[Karl Denninger <karl () Mcs Net>]

On Fri, Nov 07, 1997 at 09:01:18AM -0500, Sean M. Doran wrote:
> Karl Denninger <karl () 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.

Not if you define "site" as "one network owned by an entity or related set
of entities".

Of course, then what happens is that you have to revoke the multiple ASNs
that some providers have - which IMHO should NOT have been issued.

"Administrative convenience" isn't a valid reason to be issuing ASNs all
over the place.  There is no *need* to do so - there may be a *want* to do
so, primarily because people don't want to carry their own customer's
traffic for the majority of the trip in even one direction (which IMHO is
baloney, but heh, that's just my point of view).

> > 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.  

Anyone who connects to and exchanges routes with two or more other ASN 
holders. If you're part of the mesh, then you need an identification 
number to *BE* part of the mesh.

> 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.

Not very relavent, really.  Think about it - right now BGP4 uses the path
length as the first-order determinant.  If you had one route entry for each
ASN, and only one, then By Golly, we'd have something like 5,000 prefixes in
the table right now.

Heh, anyone like the idea of being able to run on AGS+ platforms again and
other things with limited RAM and CPU power?  Sure would be nice, wouldn't
it?

> 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.

Yep.

> 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.

Well, no.  You give out AS numbers to anyone who is a member of the mesh.
By *definition* to be a mesh member you must exchange information with more 
than one other party.  

If you do, then you're a mesh member.  

If you do not, then you are not.

> 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.  

Aggregation of ASNs is interesting, but I believe both unnecessary and
politically dangerous (for the same reason that I believe that aggregation
of IPv4 addresses now can be dangerous in that it can be used to restrain
trade).

> 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.

Yep.  In fact it is *exactly* that; the fact that the high order bits are
defined as the ASN is an administrative convenience.

> The only known means for any IP-like protocol to scale to
> complex topologies is hierarchical routing.  

One multiply-connected entity, one hierarchy.  The requirement of multiple
connections is a natural limit to an explosion of hierarchies.  Also,
with address space being effectively unlimited, there is no longer a reason
for people to persue this for any reason other than route exchange - it buys
you NOTHING.

See my other posting regarding low-order-bit confederation agreements to
allow full portability at the *customer* level without people needing to
have their own ASN.  This instantly removes the argument for and desire to
obtain ASNs for what some people now call "vanity" purposes (and what I 
call a survival requirement).

> This imposes
> constraints on address assignment.  There is no way around
> these constraints other than abandoning topological
> complexity or routing efficiency.

The point is that constraints on an unlimited resource which *STILL* looks
unlimited after the constraint is applied are null operations as far as the
external impact goes.  This is why the split that I've described works and
doesn't really inconvenience (or screw) anyone.

> 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.   

Correct.  I am trying to achieve a level playing field.

> 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.

NAT is *not* currently the appropriate technology because people have
designed brain-dead protocols which encode endpoint addresses INSIDE THE
PAYLOAD REGION of datagrams.  This requires all kinds of special-casing.

That the IETF has *approved* such protocols, and continues to do so, is a
huge problem.  In fact it is THE problem which makes NAT unworkable in the
general sense.

Unfortunately, one of those protocols is one of the earliest - FTP.

But its not the only abuser by any stretch of the imagination.

> 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.

We need to fix the broken protocol problem too Sean... Fix that and
translation at boundaries becomes VERY workable.  In fact, if we fix 
that I will agree that such a reference implementation is worth my 
effort and will see what I can code up for precisely this purpose.

--
-- 
Karl Denninger (karl () MCS Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
                             | NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal