[arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6
sethm at rollernet.us
Fri May 29 19:33:43 EDT 2009
Ted Mittelstaedt wrote:
> Stacy Hughes wrote:
>> Hi Everyone, Chuck precisely makes one of my points here. When I
>> voted against this concept last time around, I felt just like Ted.
>> Like, you're not a real ISP or player if you don't have 200 customers.
> I never said that. As I mentioned in the response to the NoX question,
> there is already a micro allocation policy that applies to them.
>> But there are real ISPs that are small that deserve the minimum
>> allocation of IPv6 just as much as the 200+ers. If we want everyone
>> participating in IPv6, we must make sure they can get it - especially
>> ISPs, large and small.
> If they are real ISPs that are small then it is not that much of a
> burden for them to get their IPv6 from an upstream and reassigning
> it to their customers. If they are
> multihomed then nothing is stopping them from advertising that block.
> Granted, there will be a larger advertisement for the block their
> smaller block is part of out there but that shouldn't matter. It
> certainly doesn't matter for IPv4 since before we got our IPv4 space
> in 2004 we used non-portable IPv4 space in this fashion with no problems.
In IPv4 land it's a huge problem (to me) because you have to give PA
space back and renumber into PI space in order to ever qualify for more
PI space. As much as everyone things renumbering is a big deal, it is. I
*still* have customers asking why PA space from an upstream I dropped
over three years ago doesn't work. Even further back, people are still
hitting my test bed I set up while I was still in college; talk about
out of date. I have no idea where they find those old addresses.
Renumbering is a headache that never ends.
> By contrast, the problem of table bloat in routers is very real. You
> are essentially asking thousands of orgs out there to put money into
> tens of thousands of routers out there to replace them with new gear
> that will hold and manage a fantastically gigantic IPv6 table, just to
> make it a slight bit easier for small orgs to advertise a /32, who
> have absolutely no use for a /32 and would be happy with a /48, and
> who are getting the /32 because they are still scared to death about the
> old renumbering bugaboo - which doesn't even exist with IPv6 anyway.
I tried to make the same point. Routers with a lot of TCAM space are
horribly expensive. Many people have already bought equipment expected
to last for the next X years (where X is greater than 1) and it's
already inadequate. Bleh. Besides, there's no reason a small org can't
just get a /48 and apply for more space later. No renumbering required.
> You speak of a disincentive to adopting IPv6. Well let me say that for
> us, right now the additional ram consumed in our routers by the small
> IPv6 table is NOT a disincentive.
I'm using several ISR series routers that hold routes in cheap DRAM in
front of my TCAM-based switches because those can't even handle a
fraction of the IPv4 table.
> But if 5 years from now that table has balloned and is maxing our
> routers ram out, and I still don't have customers asking for IPv6,
> then your going to put me into a position where I have the choice of
> tossing a lot of money into buying new hardware for a numbering scheme
> that none of my customers wants or is paying for, on the idea
> that -someday- it will be important, or just abandoning
> the scheme alltogether and going back to IPv4 and waiting until
> eventually there's demand for IPv6.
> Seems to me your ignoring the disincentive that gigantic routers with
> enormous amounts of memory will cost.
You, me, and everyone else is supposed to just bend over and eat the
cost because it somehow makes it easier to adopt. Didn't you get the memo?
There seems to be a failure to recognize that the cost to entry for IPv6
will become very non-trivial if the routing table gets horrendously
large and requires equally expensive hardware to deal with it, even
hurting some of us early adopters if we can't keep up hardware-wise.
More information about the ARIN-PPML