Subject: Re: Enforcing unreachability of site local addresses

From: Dan Lanciani <[email-masked]>
Date: Tue, 11 Feb 2003 03:34:53 -0500 (EST)

Brian E Carpenter <[email-masked]> wrote:

|Dan Lanciani wrote:
|...
|> |I wasn't around then, but from what I have been told and read I think
|> |everyone was very aware of the scaling issues. But decided to put them
|> |forward and buy time.
|> 
|> Well, I was around and I don't recall any major concern.  
|
|This is hard to reconcile with some of the words in RFC 1380,
|or what I remember when I first arrived in late 1992.

IMHO, by the time 1380 was published in 1992, RFCs were not quite the
reflection of community feeling that they had once been.  RFC1380 was an
attempt to highlight the problem and encourage the concern as much as it was
an expression of that concern.  Note that while 1380 does brief lip service to
other possible solutions (including a distributed one!), it quickly concludes
without proof that aggregation must be part of any long-term solution.  At
least that's the most obvious reading of a sentence that isn't quite English...

|My recollection
|is of a consensus to buy time with CIDR.

There was a consensus to use provider-based hierarchical allocation as a
temporary fix for a projected problem.  Unfortunately, there was some confusion
about how much time we were trying to buy and exactly what we were buying that
time for.

Initially the plan was presented as just that: hierarchical *allocation* by
providers to end users.  The addresses so allocated were to be portable and
were to belong to the end user.  The theory was that this would slow routing
table growth, but would ultimately put us right back where we started once
enough people changed providers and took their addresses with them.  This
scheme was perfectly consistent with the notion of "buying time" and it was
not going to be a serious burden for end users.

Very soon the "allocations" from providers turned into loans (or, at the low
end, rentals).  It was quickly pointed out that the original notion of letting
users take their addresses with them "didn't scale".  Suddenly we weren't just
buying a little time, we needed to buy indefinite time until some new routing
mechanism could be implemented.  But since provider control of addresses worked
out so well (at least for everyone but new end users) we never saw much effort
go into developing that new routing mechanism.

Eventually it turned out that what had really been meant by "buy time" was to
put off the problem until a new next generation protocol suite could be built.
There had never been any intention to return to portable v4 addresses.  At
least not in retrospect.

Now here we are a decade later deploying the next generation of IP and we
just need to "buy some time" with provider-based hierarchical address loans.

What have we done with all the time we already bought?  We didn't do anything
to restore portable v4 address allocations.  We have a new protocol suite, but
it suffers from exactly the same limitation in this respect as v4.  What will
we do with more time?  Some people are quick to point out that we don't have a
clue how to solve the problem and that we don't even know how we should be
approaching it.  If this is true then we might as well be honest and admit that
we aren't just "buying time" anymore:  IPv6 really is just IPv4 with more
address bits.

|(Just as PA addressing in IPv6
|buys time; this was in fact strongly debated during the formative
|stage of IPng in 1993/94.)

Yes, it was strongly debated.  Given how long it has taken for v6 to go
anywhere, the arguments that there just wasn't time to do anything better
initially look less than convincing.  In retrospect.

I would like to know specifically for what we are buying time with PA addressing
in v6, and just how much time we are trying to buy.  Absent a visible plan it
seems that we will merely repeat the v4 scenario.   We will buy time with PA
addressing until there is no longer any possibility of getting rid of it.
Contrary to the popular quip, it is not easier to go from aggregated to non-
aggregated than the reverse--especially if the transition requires any change
in the deployed code.

|> We were aware
|> that there might ultimately be a problem but we were much more open-minded
|> about solutions relying both on faster hardware and on new protocols.  I
|> think that's why some (a lot?) of us were more than a little annoyed at
|> being sandbagged by the "CIDR" two-step.  What was supposed to be a temporary
|> fix quickly evolved into the effective extinction of new portable addresses.
|> Since then, hierarchical allocation has become so ingrained that some people
|> have trouble even conceptualizing other solutions.
|
|It's true that RFC 1380 assumed hierarchical allocation. But it also
|clearly expressed the distinction between interim solutions (specifically
|CIDR) and the long term.

It made a distinction between the solutions and then asserted without evidence
that any long-term solution had to involve aggregation.  By strange coincidence
that was the short-term solution as well.  I'm sure we could argue the exact
semantics of "aggregation" at great length, and certainly in the most abstract
sense of summarization it could mean simply that you have to be able to start
from *something* and eventually figure out how to route a packet.  For such a
definition of aggregation the claim that aggregation is necessary is a truism
devoid of substance, so I doubt that that is what was intended.

|What I think it missed was the whole topic
|of identifier/locator separation. That seems to be what we (for
|some definition of "we") need to focus on now.

I've been trying to focus attention on portable identifiers (which are really
just a thinly disguised form of source routing) for years.  There seem to be
several issues that keep getting in the way:

-It is highly unlikely that any solution along the lines of a separate
identifier is going to be totally without cost.  If we accept the view
that any cost is too great then clearly portable identifiers are DOA
regardless of the details of the proposal.  So I again suggest that we
try to reach consensus on how much (if anything) it is worth to us to
provide end users with some sort of identifier that is independent of
the locator.

-It has been suggested that we already depend strongly on being able to infer
topology hints from identifiers, even at high levels (i.e., in applications).
This is of course anathema to the very goal of making an identifier independent
of the locator.  Clearly it would be possible to make both the identifier and
the locator available to applications, but again this is not going to happen
without cost.  We should decide whether we really need this and how much we
are willing to pay for it.

-There seems to be some sentiment that any solution to the portable identifier
problem must also solve all other related problems and do so optimally--right
away.  I think that this is completely backwards.  Even a partial solution now
that puts in the hooks for further development is better than nothing.  As it
stands, there is nothing in v6 that makes it more amenable to a separation of
identifier and locator than is v4.  The only advantage we have (if indeed we
still have it) is early access.  If we buy time for v6 deployment with PA we
will again be in the position of having to wait for another new next generation
protocol to solve the problem.

|I don't think most people whose BGP tables were exploding felt in the 
|least sandbagged by BGP4.

Of course not; by and large they were the ones doing the sandbagging.
Aggregation offers many benefits to providers (increased life for cheaper
hardware and address rental revenues being chief among them) at the expense
of end users.  Sure, there were some end users taking full BGP feeds and
they may have been happy to put off a router upgrade.  (There were also
plenty of users who already had or could quickly get all the portable address
space they thought they would need.  The transition was of little concern to
most of them, though you can bet they won't give up that space now for PA v6
addresses.)  But I don't think there is any serious debate about where most of
the benefit accrued.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Alan E. Beard" <[email-masked]>
Date: Tue, 11 Feb 2003 13:17:45 -0500 (EST)

Dan, Brian:

A bit of historical information and some comments on the current issue
included below.

AEB

> |or what I remember when I first arrived in late 1992.
I _was_ around, and I _do_ remember these events.  Here is the best of my
recollection.

About 1992 the community of user-network admininstrators (of which I was
then a member) began to show considerable uneasiness about a looming
shortage of IPv4 registered address space.  Within two years class B
address allocations were becoming very scarce, and registered class Bs
were becoming increasingly hard to get.  In 1996, a company for which I
was acting as network administrator _gave_ one of their registered Class B
allocations to a local residential community with had been unable to
obtain sufficient registered space via the normal applications process!
Many networks converted to VLSM, and others began to use PNN space, in an
attempt to stave off the inevitable restrictions on growth which the
scarcity of registered IPv4 space was expected (not inaccurately) to
impose. The later introduction of CIDR and provider-based addressing, as
you well know, enabled the vast growth of the "online" services (AOL and
entities of that ilk), but at the cost of great operational difficulties
for privately-operated networks which needed to expand.  Use of PNN and
NAT grew explosively.

In summary: yes, there was knowledge and concern over the IPv4 address
scarcity issues as early as 1992.  There were some administrative (as
distinguished from technical) managers who chose to play ostrich (you know
what that bird exposes when it sticks its head in the sand), but the
user technical community was aware of, and alarmed about, the issue.

Subsequent experience with provider-based addressing has convinced almost
all administrative managers of privately-operated networks, and most
technical managers and network administrators, that renumbering is to be
avoided at any cost short of summary hanging. Absent the ready
availability of provider-independent, globally routable address space, I
suspect that most of my clients will continue to require the use of
non-globally-routable addressing in their internal networks, with NAT and
application-level gateways used where public-network access cannot be
avoided.  As indicated by the general sentiment in this WG, the conditions
described immediately above are, to put it politely, far from desirable.
This account puts me in mind of a quote from Mark Twain (Sam Clemens),to
wit: "a cat, once he has sat on a hot stove lid, will not do so again; but
he'll never sit on a cold one either".  The user-network managers are
unlikely to change their opinion in the foreseeable future, engineering
advice to the contrary notwithstanding.

> |is of a consensus to buy time with CIDR.
This accords with my memory: CIDR was seen as a stopgap, to provide, at
best, temporary relief until IPNG could be got into service.  CIDR and
its familiar, aggregation, were considered necessary as distinguished from
desirable.  Provider-based addressing was seen by most user-network
administrators as a definite evil, and there was considerable
consternation when the PA model was specified as the default allocation
scheme for IPv6.

So much for the historical context from the standpoint of end-user-network
administrators.  We are now (as pointed out at some length by others
below) reaping the consequences of a decision to use hierarchical PA as a
tool to achive route aggregation: the situation is about as appetizing as
attempting to swallow a porcupine wrong-end-to.  Based on experience with
my clients, I strongly suspect that end-user networks will not embrace
IPv6 enthusiastically unless registered, globally routable PI space is
readily available.  Independent of the technical merits of routing
aggregation, PA addressing, with its history of lack of portability and
the renumbering overhead, will be seen as a probibitively disruptive for
almost all end-user-network administrative managers, and for most
technical managers and network administrators.

> not going to be a serious burden for end users.
[...]
> 				ddl@danlan.*com

That's my $.02 worth.

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529