I was doing my daily traceroutes to see who was down today, and i noticed some interesting things. One thing I noticed was that: c.root-servers.net e.root-servers.net g.root-servers.net i.root-servers.net all appear to be in the "twd", as well as being in the swamp. A well-known router vendor's web site also appeared to be in this category. 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. I also think it would be hard to convince someone to renumber out of a /24 in 192, when they can say, "well almost half of the root servers haven't renumbered, why should I?". Just my observations. I'll crawl back into my little stub of the 'net and resume being a spectator. :) -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 ... :-)
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
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
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 ... :-)
For those not at the last IEPG mtg, this was discussed with the trade off being 13 host routes vs coordinating root cache updates for 20-30 million end nodes. -- --bill
Let's also analyze the cost of wasting the remainder of /24s in this special case. Much worse has happened.
For those not at the last IEPG mtg, this was discussed with the trade off being 13 host routes vs coordinating root cache updates for 20-30 million end nodes.
participants (6)
-
Avi Freedman -
bmanning＠isi.edu -
Bradley Dunn -
jon＠branch.com -
Paul A Vixie -
randy＠psg.com