IPv4 address shortage? Really?

Wed Mar 9 11:34:18 UTC 2011

On Tue, 2011-03-08 at 07:37 -0500, Steven Bellovin wrote:
> > 
> > ...well, kind of. What you don't mention is that it was thought to be
> > ugly and rejected solely on the aesthetic grounds.  Which is somewhat
> > different from being rejected because it cannot work.

> No.  It  was rejected because routers tended to melt down into quivering
> puddles of silicon from seeing many packets with IP options set -- a fast
> trip to the slow path.

Let me get it right... an important factor in the architectural decision
was that the current OFRV implementation of a router was
buggy-by-design?

Worse, when having a choice between something which already worked (slow
as it were - the IPv4 options) and something which didn't exist at all
(the new L3 frame format) the chosen one was the thing which didn't
exist.

Any wonder it took so long to get IPv6 into any shape resembling
working?

> It also requires just as many changes to applications
> and DNS content, and about as large an addressing plan change as v6.  There
> were more reasons, but they escape me at the moment.

Not really. DNS change is trivial; and if 64-bit extended IPv4 address
was choosen (instead of a new address family) 80% applications would
only needed to be recompiled with a different header file having long
long instead of int in s_addr.  Most of the rest would only need a
change in a data type and maybe in custom address-to-string formats.

Compare that with try-one-address family and if failed try another logic
which you need to build into every app with the dual-stack approach.

Do you remember the mighty trouble with changing from 32-bit file sizes
to 64-bit size_t in Linux? No? That's the point.

Valdis.Kletnieks at vt.edu wrote:

> Steve, you of all people should remember the other big reason why:
> pathalias tended to do Very Bad Things like violating the Principle of
> Least Surprise

As the guy who implemented the country-wide domain name e-mail router
over UUCP, I remember this issue pretty well.  In any case, it is not
applicable if you structure 32-bit address spaces into a tree. Which
maps very nicely onto the real-life Internet topology.

Steven Bellovin wrote:

> And then some other dim bulb will connect one of those 5 layers to the
> outside world...

A dim bulb has infinite (and often much subtler) ways of screwing
routing in his employer's network.  Protecting against idiots is the
weakest argument I ever heard for architectural design.

(Now, I don't deny value of designing UIs and implementation logic in a
way which helps people to avoid mistakes... how could I, having been
doing GPS Z to SQL just a few hours ago, in IMC:)

So. You pretty much confirmed my original contention that the choice was
made not because of technical merits of the LSRR or IPv4 extended
address option but merely because people wanted to build beautifully
perfect Network Two - at the expense of compatibility and ease of
transition.

Well, I think IPv4 will outlive IPv6 for precisely this reason.  The
real-life users don't care about what's under the hood - but they do
care that the stuff they used to have working will keep working.  And
the real-life net admins would do whatever it takes to keep the users
happy - even if it is ugly as hell.

--vadim