Mailing List Archive

We have considered assigning a /32 to each root name server and asking
everybody in the universe to carry these 10 or so routes in the interest
of complete and permanent provider independence. So rather than worry
about the /24's ... :-)
- - - - - - - - - - - - - - - - -

Interesting. Well, in that case the rest of the /24 they are in now would
have no excuse not to renumber, now would they? :)

How would the routes for these /32s get propagated? I assume you'd want
them to be announced via BGP, so everyone would have to rewrite their
filters to let those routes in. Right?

-BD

----------
> From: Paul A Vixie <vixie@wisdom.home.vix.com>
> To: nanog@merit.edu
> Subject: Re: The SWAMP
> Date: Sunday, September 08, 1996 7:12 PM
>
> We have considered assigning a /32 to each root name server and asking
> everybody in the universe to carry these 10 or so routes in the interest
> of complete and permanent provider independence. So rather than worry
> about the /24's ... :-)
- - - - - - - - - - - - - - - - -

> How would the routes for these /32s get propagated? I assume you'd want
> them to be announced via BGP, so everyone would have to rewrite their
> filters to let those routes in. Right?

We'd take them from a low numbered Class C to avoid the new-block filters.
- - - - - - - - - - - - - - - - -

> We have considered assigning a /32 to each root name server and asking
> everybody in the universe to carry these 10 or so routes in the interest
> of complete and permanent provider independence. So rather than worry
> about the /24's ... :-)

If there has to be a separate route for each one anyway, why not just
blow 253*10 addresses and announce a /24 for each root name server, even
if only one IP out of each /24 is used?

Less CPU to blow holes in filters that normally deny > /24.

Avi

- - - - - - - - - - - - - - - - -

> If there has to be a separate route for each one anyway, why not just
> blow 253*10 addresses and announce a /24 for each root name server, even
> if only one IP out of each /24 is used?
>
> Less CPU to blow holes in filters that normally deny > /24.
>
> Avi

How far does this get extended, then? What if, to encourage aggregation,
/24s start to be filtered? Do you then blow a /23? A /22? I guess the real
question is how do you balance between two scarce resources, router CPU and
IPv4 address space.

-BD
- - - - - - - - - - - - - - - - -

>> We have considered assigning a /32 to each root name server and asking
>> everybody in the universe to carry these 10 or so routes in the interest
>> of complete and permanent provider independence. So rather than worry
>> about the /24's ... :-)
>
> If there has to be a separate route for each one anyway, why not just
> blow 253*10 addresses and announce a /24 for each root name server, even
> if only one IP out of each /24 is used?
>
> Less CPU to blow holes in filters that normally deny> /24.

I agree with your ammendment to the proposal. It makes it somewhat more
sensible.

But I gotta ask why we have to pollute the world with a few more /24s.
Everybody who has introduced /24s probably thinks that their reason is
justified. Commons, meet sheep.

randy
- - - - - - - - - - - - - - - - -

> I agree with your ammendment to the proposal. It makes it somewhat more
> sensible.
>
> But I gotta ask why we have to pollute the world with a few more /24s.
> Everybody who has introduced /24s probably thinks that their reason is
> justified. Commons, meet sheep.
>
> randy

Why do we have RAs at XPs, each taking up a potentially valuable IP
address on the XP network - and more importantly, each a potential
security risk (a Unix machine on the XP network)?

I'd say the RA machines and root servers are something of common interest,
esp. to the people who "make things go". I can't think of many/any other
examples that I'd say deserve such special treatment.

Avi
- - - - - - - - - - - - - - - - -

> I'd say the RA machines and root servers are something of common interest,
> esp. to the people who "make things go". I can't think of many/any other
> examples that I'd say deserve such special treatment.

Skip RSs. They use address space from networks on which they reside,
perfectly natural and reasonable.

'Deserve'? Is this like China 'deserves' a /8? Do root servers have egos
that need coddling?

Why do they NEED special address space? What's the matter with the address
space of the normal networks in which they reside? If there is someing bad
about those networks, then they need fixing, and access to the root (or
other) servers will be fixed with that change.

randy
- - - - - - - - - - - - - - - - -

> > I'd say the RA machines and root servers are something of common interest,
> > esp. to the people who "make things go". I can't think of many/any other
> > examples that I'd say deserve such special treatment.
>
> Skip RSs. They use address space from networks on which they reside,
> perfectly natural and reasonable.
>
> 'Deserve'? Is this like China 'deserves' a /8? Do root servers have egos
> that need coddling?
>
> Why do they NEED special address space? What's the matter with the address
> space of the normal networks in which they reside? If there is someing bad
> about those networks, then they need fixing, and access to the root (or
> other) servers will be fixed with that change.
>
> randy

Actually, I put my foot in this only to point out that if you're going
to announce routes, wasting 253*10 addresses might be worth not having to
deal with legitimizing /32 announcements for any reason.

But thinking about it, if each root server has a semi-permanent IP/route
attached to it, it's easier to move it to a different provider in case
of trouble/emergency/etc..., no?

Avi

- - - - - - - - - - - - - - - - -

> But I gotta ask why we have to pollute the world with a few more /24s.
> Everybody who has introduced /24s probably thinks that their reason is
> justified. Commons, meet sheep.

the goal of the /32 proposal (which we've not made formally btw) is to
give root servers permanent addresses even if they change identity,
locations, providers, or owners.
- - - - - - - - - - - - - - - - -

> the goal of the /32 proposal (which we've not made formally btw) is to
> give root servers permanent addresses even if they change identity,
> locations, providers, or owners.

i understand that. i do not see the negligible merit of the goal as worth
the additional route pollution.

randy
- - - - - - - - - - - - - - - - -

> 'Deserve'? Is this like China 'deserves' a /8? Do root
> servers have egos that need coddling?
>
> Why do they NEED special address space? What's the matter with
> the address space of the normal networks in which they reside?
> If there is someing bad about those networks, then they need
> fixing, and access to the root (or other) servers will be fixed
> with that change.

I will echo Randy's sentiment here: is there a technical reason
why the root name servers need special "provider-independent"
addresses, or is this a solution looking for a problem?

As far as I know, as long as one of the IP addresses in a local
name server's root hints file is correct and that root name
server is reachable, the local name server will operate
correctly. Changes to the root hints file are currently not
terribly frequent, and updating it once per half year (or maybe
even less frequent) does not seem like an inordinately heavy
burden.

Without a technically well-founded reason for doing "weird"
things with the routes for the root name servers, you can expect
so see similarly ill-founded justifications from other folks
wanting to do the same or similar things. As the recent events
should make evident, the last thing we need right now is creating
a precedent for spreading /32 routes or needlessly propagating
other "special-purpose" and non-aggregateable routes.

Regards,

- Havard
- - - - - - - - - - - - - - - - -

Isn't the argument of the non-default routing tables growing by an
additional 13 entries or not is specious noise? The routing bucket is
leaking through bloody great open chasms and we are wondering about
the incremental damage throuigh a pinhole!

The more critical issue in this conversation is the assumption that
the Internet world has so completely transformed itself into a
classless world capable of full permeation of /32 routes that we can
push the DNS root name servers off the classfull cliff. I know we've
tried the experiment with the 39 prefix, but I for one am not happy
with the robustness of this assumption in today's Internet.

thanks,


Geoff


- - - - - - - - - - - - - - - - -

> Isn't the argument of the non-default routing tables growing by an
> additional 13 entries or not is specious noise? The routing bucket is
> leaking through bloody great open chasms and we are wondering about
> the incremental damage throuigh a pinhole!

The 13 additional entries are not the issue. The issue is one of
setting a bad high-profile example.

Any suggestions for closing the open chasms in the routing
bucket?

- Havard
- - - - - - - - - - - - - - - - -

> As far as I know, as long as one of the IP addresses in a local
> name server's root hints file is correct and that root name
> server is reachable, the local name server will operate
> correctly. Changes to the root hints file are currently not
> terribly frequent, and updating it once per half year (or maybe
> even less frequent) does not seem like an inordinately heavy
> burden.

I should probably not answer this since it has likely
been answered. The tradeoff is one of a small number
of well known routes that won't change vs periodically
updating an increasingly large (20-20 million+) root
hints files.

> wanting to do the same or similar things. As the recent events
> should make evident, the last thing we need right now is creating
> a precedent for spreading /32 routes or needlessly propagating
> other "special-purpose" and non-aggregateable routes.
>
> - Havard

Cisco Routers are going to fail, regardless of what we
do with regard to controling routing table entries. We'll
hit that brick wall soon and will bounce off and move on.



--
--bill
- - - - - - - - - - - - - - - - -

On Mon, 9 Sep 1996 Havard.Eidnes@runit.sintef.no wrote:

> Any suggestions for closing the open chasms in the routing
> bucket?

Gather weekly stats of top 10 worst offenders (ala Tony's old list) and ask
Bob Metcalfe to publish them in his rag? He did say he wanted to help..

;)

-dorian

- - - - - - - - - - - - - - - - -

> > Isn't the argument of the non-default routing tables growing by an
> > additional 13 entries or not is specious noise? The routing bucket is
> > leaking through bloody great open chasms and we are wondering about
> > the incremental damage throuigh a pinhole!
>
> The 13 additional entries are not the issue. The issue is one of
> setting a bad high-profile example.

Quite frankly with the root nameservers the issue os one of stable and
highly reliable functionality! The profile of the general
applicability of the adopted mechanism is a minor consideration I'd
suggest.

But of more importance is the question:

> Any suggestions for closing the open chasms in the routing
> bucket?

My humble suggestion is forced non-local proxy aggregation. Where an
aggregrate and more specifics are visible through the same next AS
hop, the specific advertisements can be dropped without change in the
the policy environment. Similarly where multiple advertisements can be
aggregated into either a single cohesive aggregate, or aggregates plus
different specifics, then if the operation reduces the number of
routing entries then the routing tables can be aggregated.

Right now the routing tables in the default free areas are expressing
a forwarding table which has very little to do with the scope of
forwarding decisions at the default free zone (as such a decision
table is quite small as there are not a massive number of paths into
such zones and forced non-local aggregation appears to be potentially
beneficial here) and more to do with diversity in AS paths for
networks reachable from the zone.

However I know I'm covering well worn paths with this suggestion and
that such a mechanism can yeld coarse outcomes which may not produce a
precise match to desired traffic flow policy in all situations, as
information is being masked through this process. Here again the issue
becomes a qualitative issue of whether its better to damp down the
routing tables at the expense of close accuracy to express traffic
flow preferences or to allow the tables to grow to ensure absolute
integrity of traffic flow preferences across the entire Internet.

Thanks,

Geoff


- - - - - - - - - - - - - - - - -

Now,

to create another sub-thread on this subject...

Bradley Dunn wrote:

> Now I don't run anything nearing a real router, so I checked
> route-server.cerf.net, and sure enough they are being
> advertised as /24s. I realize renumbering the root servers is
> not really a good place to start.:-) Yet I think it shows what
> a massive task we have ahead of us, if we are to make progress
> in aggregating 192/8.

The massive task of aggregation is not only in 192/8. Earlier
today I took a dump of the BGP routing table on the above
mentioned router (thanks to CERFnet!) and threw it at one of my
Perl scripts which produces a report showing the distribution of
prefix lengths for announced routes in each individual /8 block
within the "class C" address space. The result is attached
below. Note that the two "100% announced" entries are due to a
well known jester announcing a couple of /8s... I will however
here repeat the summary for all of the "class C" routes which
shows the total number and the distribution over prefix lengths:

All >=24 /23 /22 /21 /20 /19 /18 /17 /16 </16
#Rts 33220 24504 2388 1785 1170 933 918 486 226 642 168

Anyone for "War on /24"? (Oh, well, probably a lost cause before
it got started...)


- Havard

I believe, in a limited case like this, the scarce resource is all
the time it takes many people to put in an exception for this and
the additional unreliability that exceptions cause.

A few extra routes or a few extra addresses are insignificant.

> > If there has to be a separate route for each one anyway, why not just
> > blow 253*10 addresses and announce a /24 for each root name server, even
> > if only one IP out of each /24 is used?
> >
> > Less CPU to blow holes in filters that normally deny > /24.
> >
> > Avi
>
> How far does this get extended, then? What if, to encourage aggregation,
> /24s start to be filtered? Do you then blow a /23? A /22? I guess the real
> question is how do you balance between two scarce resources, router CPU and
> IPv4 address space.
>
> -BD
- - - - - - - - - - - - - - - - -

> My humble suggestion is forced non-local proxy aggregation. Where an
> aggregrate and more specifics are visible through the same next AS
> hop, the specific advertisements can be dropped without change in the
> the policy environment.

In the presence of multi-homing, this will create shorter prefixes visible
through the path which proxy-aggregates, thereby changing policy another hop
away and changing the load distribution.

This is similar to Sprint's aggregating multi-homed customer announcements
at Sprint's external borders. They justify this with words about saving
prefixes, which might be credible if one did not look at the rest of what
they actually announce. Rant, rave, foam, ...

> such a mechanism can yeld coarse outcomes which may not produce a precise
> match to desired traffic flow policy in all situations

I suspected you might have seen the problem.

> Here again the issue becomes a qualitative issue of whether its better to
> damp down the routing tables at the expense of close accuracy to express
> traffic flow preferences or to allow the tables to grow to ensure absolute
> integrity of traffic flow preferences across the entire Internet.

I suspect that we will get the major part of the win if folk clean up the
messes they are making today, and we can hold proxy aggregation in reserve
if that does not work. I have hope that Tony will resume publishing, and
that will encourage some serious offenders to clean up their announcements.

randy
- - - - - - - - - - - - - - - - -

>I will echo Randy's sentiment here: is there a technical reason
>why the root name servers need special "provider-independent"
>addresses, or is this a solution looking for a problem?

Root name servers is the only legitimate use for fixed IP
addresses.

How about allocating some "good sounding" IP addresses for them,
(like 1.0.0.x/32) and hard-wiring them into resolver code? Would
save quite a lot of configuration headaches for newbies.

--vadim
- - - - - - - - - - - - - - - - -

Geoff Huston <gih@aarnet.edu.au> wrote:

>My humble suggestion is forced non-local proxy aggregation.

That is unfortunately more easily said than done. I can
recite PSI's blocks if you wake me up in the night...

--vadim
- - - - - - - - - - - - - - - - -

> How about allocating some "good sounding" IP addresses for them,
> (like 1.0.0.x/32) and hard-wiring them into resolver code? Would
> save quite a lot of configuration headaches for newbies.

Hardwiring anything like this into a system like DNS sounds like a really
bad idea if only for the simple reason that DNS is not just used on the
Internet, but also within private networks. Having hardwiring IP numbers in
this case would cause headaches of unimaginable proportions.

Nick
- - - - - - - - - - - - - - - - -

On Monday, Sep 9, 1996, Nick Hilliard writes:
>> How about allocating some "good sounding" IP addresses for them,
>> (like 1.0.0.x/32) and hard-wiring them into resolver code? Would
>> save quite a lot of configuration headaches for newbies.
>
>Hardwiring anything like this into a system like DNS sounds like a really
>bad idea if only for the simple reason that DNS is not just used on the
>Internet, but also within private networks. Having hardwiring IP numbers in
>this case would cause headaches of unimaginable proportions.
>
>Nick

Good point. So make sure there's a way to override the hardwired defaults,
is all... Anyone setting up a private network with private resolvers, etc,
will be clueful enough to know to include --rootserverfile named.root
on the command line...

--Zachayr
- - - - - - - - - - - - - - - - -