Mailing List Archive

Hm, routing wars. Fun stuff. Expect much heat on this shortly... :(

Essentially, the point-of-appeal would probably be the IEPG
or NANOG mailing lists, and who would get believed would probably
get worked out after some protracted flameage, consultations with
lawyers, and arguments about how routing registry technologies
will save the planet from routing wars, pollution, and too-strong coffee.

My own personal advice wrt people who are thinking of using
others' address space without permission is pretty simple:
don't do it, you'll lose.

Sean.

> and arguments about how routing registry technologies
> will save the planet from routing wars, pollution, and too-strong coffee.
>

With all due respect Sean, the world does not need to be
saved from too-strong coffee

:)

Larry Plato

At the moment, JPNIC -- the Japanese country NIC -- charges 20,000 yen
(about $200) for one-time transaction fee to register the IP address
for the requestor.

JPNIC delegates address blocks to Japanese NSPs, and the address
assignment from the delegated space by a NSP is charged 10,000 yen
(about $100). This discount is intended to cover NSP's cost to talk
with not-well-knowledged-clients and cost to submit their request form
in emails. JPNIC does not monitor how much NSPs actually charges their
clients.

When a client changes its NSP, JPNIC does not currently charge the
one-time registeration fee to the client unless the new address space
is not larger than before. This is because these change requests are
usually submitted in emails and JPNIC people do not have to talk the
requester nor have to create a form from snail-mailed or faxed
applications.

-- Akira Kato, WIDE Project

Hank expresses concern:

<condensed>

>
> What are people doing in this area today? Are we going to start
> seeing routing wars?
>

Hank,

In the practical spirit of your question.....

I distinctly remember in 1993, preCIDR deployment, when the question was
asked around the table at a major corporation (.... not a net discussion,
an old-fashioned, face-to-face, meeting :-) We were brainstorming
future implementations of CIDR. I had been in the early hot seat as big
corps came onto the capital-I Internet, vis-a-vis marketing types having
a difficult choice (i.e. their potential big $$ client was using
unregistered address space) of renumbering an entire enterprise or
losing the account. I held fast, doing the 'right thing', and was
very unpopular to the marketing gurus as I held ground stating
*renumber* or take your business elsewhere. Luckily, management
supported our engineering decisions.

Then, in parallel, CIDR was hailed as the 'way to help save B space
deletion problems'. At the time, very few had a crystal ball and
believed the use of address space would explode to it's post WWW
rate. (some did, is the amazing thing!)

I have stated this innumerable times, and by saying so put myself in
a very unpopular position with certain Internet groups; at the time
we consided CIRD blocks to be *portable*. "After all", we stated,
"the address space does *not* belong to the provider of connectivity".
We also, as a major player at the time, had the unwritten policy "
portability of the customer address space, so they could easily
move to another provider, was a number one priority".

We understood that this opened the door for punching zillions of holes
in CIRD, but after all, CIRD was only to be an *interim solution* for
a few years for B space depletion. IPv6 would take care of that.

Like most people, I moved on to greener, more profitable career pastures
and was very surprised to learn that our vision of "completely portable"
CIDR address space have been overshadowed by the success of CIDR in
another problem area that only those with keen insight at the time
could predict, routing table explosion.

It was very suprising to me to learn that fate had changed the course of
history and aggregation was now the accepted practice for solving most I
problems and was not an *interium* or temporary fix, but was to be
a core Internet solution.

Technically, the aggregation advocates were correct. Socially and politically,
aggregation on a global cooperative scale has problems. Historically,
when society has been forced into a solution that the general population
finds unacceptable, those decisions come back to haunt and trouble
us. This is causality, and causality always holds true, IMO.

This does not mean that aggregation is not a good thing, it certainly has
proven to be the saving technology of the Internet. On the other hand,
there are future social and political implementations of global aggregation
that are negative. We have discussed these issues and roasted the
'core ideas' repeatedly and my body is scared from raging fires.

Cause and effect.

No matter what we hope, pray, or design.... it is impossible to design,
hope or pray causality out of the event stream. Even the best laid
plans of both 'mice and men' ride the big causal ferris wheel.

Now, let's see, where are my winterized, flame proof, long johns? After
this email, I'm sure to need numerous layers :-) ;-)

Regards,

Tim


+--------------------------------------------------------------------------+
| Tim Bass | #include<campfire.h> |
| Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ |
| The Silk Road Group, Ltd. | take_one_down(); |
| | pass_it_around(); |
| http://www.silkroad.com/ | } |
| | back_to_work(); /*never reached */ |
+--------------------------------------------------------------------------+

> Hm, routing wars. Fun stuff. Expect much heat on this shortly... :(
>
> Essentially, the point-of-appeal would probably be the IEPG
> or NANOG mailing lists, and who would get believed would probably
> get worked out after some protracted flameage, consultations with
> lawyers, and arguments about how routing registry technologies
> will save the planet from routing wars, pollution, and too-strong coffee.
>
> My own personal advice wrt people who are thinking of using
> others' address space without permission is pretty simple:
> don't do it, you'll lose.
>
> Sean.
>
Ah, but Sean, you missed the essential element of the previous post.

Like so many other situations in the middle-east, you have two different
factions, both of whom feel that they have legitimate title to the
address space in question. Neither of them feels that it belongs
to the other. Hence the conflict.

The question boils down to who really does own the address space, and
frankly, the fact that money changed hands causes me to lean more towads
the person who paid.

Owen

Zachary,

> Well, but was the changing of money for a *purchase* or a *lease* ? The comi
ng
> CIDRization seems to lend itself more toward leasing your IPs from your provi
der
> than purchasing them... much like small companies rarely buy a suite in a lar
ger
> building, instead they lease... with IPs though, the length of term of the le
ase
> would be something to the effect of 'while getting service from the same prov
ider'.

The issue of leasing vs owning addresses is discussed
in draft-ietf-cidrd-addr-ownership-04.txt Internet Draft.

Yakov.

Owen said:
>Sean said:
>> Hm, routing wars. Fun stuff. Expect much heat on this shortly... :(
>>
[...]
>
>The question boils down to who really does own the address space, and
>frankly, the fact that money changed hands causes me to lean more towads
>the person who paid.

Well, but was the changing of money for a *purchase* or a *lease* ? The coming
CIDRization seems to lend itself more toward leasing your IPs from your provider
than purchasing them... much like small companies rarely buy a suite in a larger
building, instead they lease... with IPs though, the length of term of the lease
would be something to the effect of 'while getting service from the same provider'.

--Zachary

> Owen said:
> >Sean said:
> >> Hm, routing wars. Fun stuff. Expect much heat on this shortly... :(
> >>
> [...]
> >
> >The question boils down to who really does own the address space, and
> >frankly, the fact that money changed hands causes me to lean more towads
> >the person who paid.
>
>Well, but was the changing of money for a *purchase* or a *lease* ? The coming
>CIDRization seems to lend itself more toward leasing your IPs from your provider
>than purchasing them... much like small companies rarely buy a suite in a larger
>building, instead they lease... with IPs though, the length of term of the lease
>would be something to the effect of 'while getting service from the same provider'.
>
> --Zachary
>

Er... Remeber that this works for providers as well. They don't "own" the CIDR
blocks they have either. They have them on loan from the address registries.

--
--bill

Owen -

I direct you to Yakov Rekhter's various drafts and commentaries
that underline the fact that address ownership is irrelevant.

Prefixes are simply strings of bits.

What's important is the routing system.

The fact that you are registered in registry X as being
the "owner" of prefix Y is completely irrelevant if pretty
much the entire Internet is going to route X towards Z.

Now, fortunately, people are working on systems which will
keep histories of route announcements and withdrawals so we
can see which direction any given prefix was routed towards
on a more historical basis. This may be as helpful in solving
disputes as it will be in debugging routing.

Sean.

In regards to:

>(Tim Bass)
> Technically, the aggregation advocates were correct. Socially and
> politically, aggregation on a global cooperative scale has problems.
>(Noel)
>Which is why we need *two* namespaces: one for the routing to do what
>mathematics forces it to, and one for the humans to be able to dork with.

This idea has been around *long* enough. When do we separate the name
spaces? How about along with the IPng transition?

-Mike

<CIDRD is the wrong list for this: CIDRD is for *deployment*, not
architectural debate. Please follow-up on Big-Internet.>


From: Tim Bass

Then, in parallel, CIDR was hailed as the 'way to help save B space
[depletion] problems'. ... very surprised to learn that our vision of
"completely portable" CIDR address space have been overshadowed by the
success of CIDR in another problem area that only those with keen insight
at the time could predict, routing table explosion.

You keep saying this, but it is *NOT TRUE*. You didn't need "keen insight" to
know it was coming, you only needed to be able to *read*, viz (from
"Supernetting: an Address Assignment and Aggregation Strategy" RFC-1338, June
1992):

As the Internet has evolved and grown over in recent years, it has
become painfully evident that it is soon to face several serious
scaling problems. These include:

...
2. Growth of routing tables in Internet routers beyond the
ability of current software (and people) to effectively
manage.
...
It has become clear that the first two of these problems are likely
to become critical within the next one to three years. This memo
attempts to deal with these problems by proposing a mechanism ...

So, the routing table problem was well known to be coming at the time that
CIDR was under discussion, and the effects of CIDR on address allocation were
pointed out in *great* detail in a discussion on the *main* IETF list (look in
the archives for the thread "Re: Vote NO on R-L-G IP Address Allocation
proposal", and in particular my message of "Sat Oct 31 19:26:04 1992", the
infamous "fnortz" message, which pointed out in some detail why renumbering
was inevitable). So, if anyone who are around then missed it, they have only
themselves to blame.

I am damned tired of people rewriting history. Please cease and desist before
I become extremely upset.


after all, CIRD was only to be an *interim solution* for a few years for B
space depletion. IPv6 would take care of that. ... aggregation was
now the accepted practice for solving most I problems and was not an
*interium* or temporary fix, but was to be a core Internet solution.

There is a certain amount of truth to this. CIDR did assume that some "better"
fix was coming as part of IPng (and let's not forget, the CIDR debate predated
the IPv6 debate - SIP only started to be discussed late that summer).

However, as is now I hope obvious to everyone, it's impossible to have a
single namespace which is both i) used directly for routing, and ii)
identifies hosts directly. To get rid of "renumbering", the Internet needed to
split "addresses" as host-identifiers from "addresses" as routing-names,
and map one into another.

No matter how hard I and some others argued for doing this, though, people
didn't want to take that "radical" step of two namespaces. Everyone's moaning
now about the painful consequences? Tough.

(I take great delight in the fact that one of the principal opponents of
splitting off the host-identification function is also one of the people most
upset at renumbering. I expect by now, with hindsight to help his understanding
along, the irony will have dawned on him.)


Technically, the aggregation advocates were correct. Socially and
politically, aggregation on a global cooperative scale has problems.

Which is why we need *two* namespaces: one for the routing to do what
mathematics forces it to, and one for the humans to be able to dork with.

there are future social and political implementations of global aggregation
that are negative.

There are some very painful routing consequences, even with two separate
name-spaces (e.g. things like inbound traffic bias), but these are technical
problems which will only admit of technical fixes. We have to investigate
various possible technical solutions, and weigh the costs of them against the
benefit of doing it the way we'd like, but that debate has to be a purely
technical one, *not* a policy debate.


Now, let's see, where are my winterized, flame proof, long johns? After
this email, I'm sure to need numerous layers :-) ;-)

Hah! When I get *really* grumpy, you better have something better than
miserable protective clothing! Try a bunker reinforced to +125 PSI blast
overpressure! :-)

Noel

Date: Wed, 15 Nov 1995 15:16:59 -0000
From: Sean Doran <smd@icp.net>
Message-ID: <95Nov15.151700-0000_est.20701+5@chops.icp.net>

What's important is the routing system.

This is certainly true.

The fact that you are registered in registry X as being
the "owner" of prefix Y is completely irrelevant if pretty
much the entire Internet is going to route X towards Z.

As is this from a practical sense - but we really need to
look a little beyond that.

If we simply look at the routing system, we find that longest
match preference is the way to go, which argues, very strongly
that in order to keep routing working, everyone should inject
(at least) /24's (no shorter) prefixes, so they won't be
overrideden by a longer prefix from elswhere, to be absolutely
safe all advertisments should probably be /32's for every host
in every organisation, backed up by /31's /30's /29's ... going
back as far as needs routing so the longest possible length
will get through any prefix length filters that exist.

I don't think that is quite what cidrd is attempting to
accomplish.

If we step beyond letting the routing system be the sole arbiter
of what addresses are useful, so people can be encouraged to
advertise shorter prefixes, with consequent greater risk of
them being overridden, there really needs to be some way that the
controllers of routing policy (who filters what) can determine
that they're doing the "right thing" when they refuse to
accept a longer prefix, but still not longer than any prefix
length limits, and route according to a shorter one instead. Or
that they should allow the longer prefix to override a shorter
one.

History of routes may allow some of that to be automated, but
that is never going to be sufficient.

What's needed is a list of just where routes should be accepted
from - which equates pretty much with address owneship, though
says nothing about the permanence of that ownership.

kre

Noel,

With all due respects, no one is rewriting history. In early
1993 I had little time to read IETF threads on the aggregation issue, kind
sir. We were working 12-16 hours a day moving big corporations
and corporate networks into a position to be a part of the
big I. It was the AGS+ --- 7000s were just a dream.......
and from our vantage point the future address space problems
were the least of my worries. Keeping corporate network
managers from getting fired because they could not move packets
or had to renumber three class Bs to connect were my issues.
Keeping high power marketing experts from going way over your
head and doing battle over ordering a client to renumber was
a daily event.

The historical IETF WGs have their history, as you remind us.
But it is only fair to point out that there are other practical
perspectives and day-to-day operations that have historical
significance. The IETF is not the *only* organization allowed
to have an opinion (and I use the word "organization" very
loosely).

I do not wish to argue with my Noel. I would rather
pick a fight with the devil..... at least I would stand
a fighting chance :-) The topic, I thought was something
like "router wars" and address space issues. I simple
point out that it is causal that there will be problems
with global aggregation; and the social, political, and
economic ramifications may possibly overshadow any
technical drafts the IETF stores in it's archives.

Please do not send any life 200 mm shells toward this bunker.
I am still having trouble finding my asbestos long johns
and teflon helmet ;-) I'm not one to question your dominance
in the field, only to learn and work toward similar goals.

Best Regards,

Tim


+--------------------------------------------------------------------------+
| Tim Bass | #include<campfire.h> |
| Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ |
| The Silk Road Group, Ltd. | take_one_down(); |
| | pass_it_around(); |
| http://www.silkroad.com/ | } |
| | back_to_work(); /*never reached */ |
+--------------------------------------------------------------------------+

Salutations.

] >(Tim Bass)
] > Technically, the aggregation advocates were correct. Socially and
] > politically, aggregation on a global cooperative scale has problems.
] >(Noel)
] >Which is why we need *two* namespaces: one for the routing to do what
] >mathematics forces it to, and one for the humans to be able to dork with.
] (Mike)
] This idea has been around *long* enough. When do we separate the name
] spaces? How about along with the IPng transition?

I ask the following question naievely because I don't know how to
ask it maturely.

What are the correlations and contrasts between our current
backbone routing problems (wrt space and # of routes) and the FCC
decision several years ago to make 1-800 numbers portable.

Is there any correlation? I realize (think) that the FCC ruling
was localized to the US, perhaps not.....

I ask because I see the a potential scenario when we are forced to
play hardball wrt non portability of new CIDR routes. Imagine
this... Big corporation leaves us having been allocated /21 of
address space. We tell them to get new IP numbers from their provider
and backbone smart people make it known they won't propogate
routes (you wouldn't, right Sean?). They say get stuffed, and get
a congress person to propose a bill that all IP numbers are
portable. This bill passes.

It could happen.

Any thoughts?

-alan

>Any thoughts?

Yup, when that happens, the USA ends up being the big loser
in the game of global Internet connectivity.

Sean.

Silly. We already *do have two namespaces*. One is EIDs in form
of FQDNs. They are portable. Another is IPv4 addresses which aren't.

How about fixing the real problem -- i.e. making renumbering easy
and removing all hardwired addresses from the software? (And, yes,
fixing DNS).

The magic-cookie EID scheme is nothing more than more complexity to work
around the broken implementations. That extra level of indirection
is patently useless otherwise. Even funnier, implementation of magic
cookie EIDs requires changes in exactly the same pieces of software
which need to be changed to repair existing two-level scheme.

Note that fixing DNS (and you *have* to do that anyway if you want
to use intermediate EIDs) is a lot easier than replacing routers,
and does not introduce compatibility problems at the transport level.

Sorry, nobody managed to make any reasonable case pro magic-cookie EIDs
as yet. The best rationale i've heard was from Noel who said that
his "architect's sense" tells him so. Funny thing, a surgeon i know
was at loss when i asked him about this function of organism, should be
a new discovery in medicine.

--vadim

In regards to:

>(Tim Bass)
> Technically, the aggregation advocates were correct. Socially and
> politically, aggregation on a global cooperative scale has problems.
>(Noel)
>Which is why we need *two* namespaces: one for the routing to do what
>mathematics forces it to, and one for the humans to be able to dork with.

This idea has been around *long* enough. When do we separate the name
spaces? How about along with the IPng transition?

-Mike

Silly. We already *do have two namespaces*. One is EIDs in form
of FQDNs. They are portable. Another is IPv4 addresses which aren't.

A FQDN is NOT useable as an EID. The host is not the endpoint.

Sorry, nobody managed to make any reasonable case pro magic-cookie EIDs
as yet. The best rationale i've heard was from Noel who said that
his "architect's sense" tells him so. Funny thing, a surgeon i know
was at loss when i asked him about this function of organism, should be
a new discovery in medicine.

Consider process migration.

Tony

>A FQDN is NOT useable as an EID. The host is not the endpoint.

Ok. FQDN + port number. The endpoint does not have to be *named*,
btw. It is quite enough to disallow TCP sessions to survice change
of source or destination TLA (which is more than enough to cover
the change of service providers) or to keep track of address changes
the same way the post service does (i.e. forward and ask the addressee
to notify the sender).

>Consider process migration.

Any commercial OS out there which does process migration? Most
OS people became quite convinced that process migration does not
pay for itself.

Process migration is a lame excuse for building a whole new level
of indirection and doing a hell lot of changes everywhere.

And, magic cookie EID is *not necessary* for process migration (you
may want to read rationale for TRAP). It can (and should) be done w/o
it. No matter how you jump, the migration requires dynamical rebinding
of EID->TLA, and the complexity of the task does not depend on the
nature of EID. So why bother with extra level of indirection? It does
not simplify anything, and like any extra layer anywhere only makes for
a lot of headache (why do i think of ATM?).

And then, there's a document describing how to do process migration w/o
magic cookie EIDs, and so far nobody found a fundamental fault (or
inherent inefficiency) in it. As i discussed that with Noel the
aforementioned "architect's sense" came up :)

The statement that migration is impossible w/o magic cookie EIDs amounts
to the denial of the existance of the postal service. It does the
two-level addressing (the EID is the identity of the addressee, the
TLA is the postal address). When you move your magazines keep coming
to you, right? Even if the "host" (i.e. home) didn't move with you.

--vadim

PS Computer science is the formalized branch
of general bureaucratology.

From: Alan Hannan <alan@gi.net>

What are the correlations and contrasts between our current
backbone routing problems (wrt space and # of routes) and the FCC
decision several years ago to make 1-800 numbers portable.

Well, the 800 number problem was a little easier, since phone numbers are
variable length, and the 800 number database maps the numbers into another
phone number, which may be a 13-digit carrier-id+phone-number combo...

They say get stuffed, and get a congress person to propose a bill that all
IP numbers are portable. This bill passes. It could happen. Any thoughts?

Exactly which court do they go to to get this enforced on non-US parts of the
Internet?

Noel

> Robert Elz <kre@munnari.OZ.AU> writes:
>
> What's needed is a list of just where routes should be accepted
> from - which equates pretty much with address owneship, though
> says nothing about the permanence of that ownership.

A routing registry strongly coupled with an assignment registry:
The RIPE database.

Daniel

> Alan Hannan <alan@gi.net> writes:
>
> What are the correlations and contrasts between our current
> backbone routing problems (wrt space and # of routes) and the FCC
> decision several years ago to make 1-800 numbers portable.

Correlations are manifold.

The most striking contrasts:

- Implementation on the 1-800 numbers was straightforward

- number space quite small
- routing fairly centralised
- on the level of the 1-800 address space there is
quite static routing, I understand that database updates
at that time were done by shipping magtapes

- The problem was local to one country and jurisdiction
due to the addressing hierarchy

> I ask because I see the a potential scenario when we are forced to
> play hardball wrt non portability of new CIDR routes. Imagine
> this... Big corporation leaves us having been allocated /21 of
> address space. We tell them to get new IP numbers from their provider
> and backbone smart people make it known they won't propogate
> routes (you wouldn't, right Sean?). They say get stuffed, and get
> a congress person to propose a bill that all IP numbers are
> portable. This bill passes.

They also passed a bill once to make PI 3 or some such, didn't they?


Daniel

>
> > Robert Elz <kre@munnari.OZ.AU> writes:
> >
> > What's needed is a list of just where routes should be accepted
> > from - which equates pretty much with address owneship, though
> > says nothing about the permanence of that ownership.
>
> A routing registry strongly coupled with an assignment registry:
> The RIPE database.
>
> Daniel

Unfortnately, those of us who aren't actual registries can't use the RIPE
setup in quite the same fashion. Personally, I'd prefer to just run a
RIPE-like RR, rather than running an RR and an RWhois server, or running
an RR and sending in SWIPs all the time.... Unfortunately, the Internic
doesn't quite seem to see it from my perspective.

_k

At 08:22 PM 11/15/95 -0500, Vadim Antonov wrote:
>
>>Consider process migration.
>
>Any commercial OS out there which does process migration? Most
>OS people became quite convinced that process migration does not
>pay for itself.

Vadim,

In many areas you and Noel know a lot more than me. You are the eagles, I am
only a hawk.

But over in corporate networks, we have had much of this for years. In
VTAM. Yes sessions do not survive rollovers, but reconnects go immediately
to the new system. We have WORKED VERY HARD trying to manage this in DNS.
Notify has helped and Dynamic will help more. But that is for host, not
process. So we have to have multiple A records for different names and that
breaks in-addr.arpa!


GRRRRR......

Talk to my at Dallas and I will give you living examples of BBBIIIGGG mobile
processes VERY mission critical.....

Enough. I got to head over to the AIAG office. Talk to me about that also
at Dallas.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

>
> > Owen said:
> > >Sean said:
> > >> Hm, routing wars. Fun stuff. Expect much heat on this shortly... :(
> > >>
> > [...]
> > >
> > >The question boils down to who really does own the address space, and
> > >frankly, the fact that money changed hands causes me to lean more towads
> > >the person who paid.
> >
> >Well, but was the changing of money for a *purchase* or a *lease* ? The coming
> >CIDRization seems to lend itself more toward leasing your IPs from your provider
> >than purchasing them... much like small companies rarely buy a suite in a larger
> >building, instead they lease... with IPs though, the length of term of the lease
> >would be something to the effect of 'while getting service from the same provider'.
> >
> > --Zachary
> >
>
> Er... Remeber that this works for providers as well. They don't "own" the CIDR
> blocks they have either. They have them on loan from the address registries.
>
> --
> --bill
>
The problem comes when the idea of lease vs. purchase was unclear at the
time money changed hands. If the policy of lease is enforced at the time
of assignment, then all is well. If the addressee (for lack of a better
term) received the address under a perceived buy which was later turned
into a lease without any notice until they attempted to move the space,
that is another issue. It is much the same issue as my outrage at NSI
for retroactively modifying the terms of existing domain names.

Owen