[arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations
tedm at ipinc.net
Tue Nov 10 16:58:22 EST 2009
Seth Mattinen wrote:
> Ted Mittelstaedt wrote:
>> Seth Mattinen wrote:
>>> Neither will my customers if they're forced to renumber more than never.
>>> Remember, an incoming colo customer may have already had to renumber to
>>> come to me and will have to renumber to leave me. My concern is the
>>> hardship to customers and if they say "screw this, if I have to renumber
>>> anyway, goodbye".
>> I think the most important thing you can convey to your customers is
>> that renumbering is inevitable, no matter what ISP they select. Even
>> if they quit you and go to a larger ISP, what do they think is going
>> to happen when the IPv4 shortage a few years after runout is so bad that
>> even the large ISP's have programs to cleanup sparse assignments so
>> they can offer IPv4 blocks for sale?
> The point I was trying to make was that the large ISP will still survive
> whereas the small one won't.
Well, one of the unspoken assumptions of the policy proposal is that
in a post-IPv4-runout world, all ISP's will still need some IPv4 around
even if they are going full-scale IPv6 deployment.
Even if they are completely fully IPv6 and have it deployed everywhere,
to all customers, they still are going to need a few IPv4 numbers to
put on an IPv4 translator to supply IPv4 to their customers that need it.
That is why we feel that the small ISPs that don't have portable IPv4
numbers now because they cannot qualify, are going to be at the mercy
of the larger ISPs post-IPv4 runout. Thus, let's help them get those
assignments now, before IPv4-runout - understanding that due to concerns
with dfz growth, a lot of people aren't going to support just dropping
the minimums unless there's something in it that will mitigate the
growth of the dfz.
>> But in any case, you always have the choice to continue using your
>> LIR-assigned IPv4 and NOT filing for an initial allocation. If your
>> very happy with your upstream and are sure they will always be nice
>> to you, then it would make the best sense to just keep using their
>> numbers and let them deal with having to dig around on the transfer
>> market post-IPv4 runout to find more.
> Having recently has a glimpse into the world snowshoe I have a different
> view. There is so much space being "rented" right now it's not even
> funny. A huge amount of it sits around idle so it will "clean up". I can
> get multiple /18's and up with a phone call and enough money. We don't
> have to wait for runout, these guys will be ready and willing to sell
> addresses to a brand new market when the time comes.
If your right and the hoarders flood the market with IPv4 once the RIR's
run out, then so be it - I guarantee that if what they do causes a
problem, the ARIN community will shut it down. That's the problem with
designing a business plan around hoarding - it's going to
be tolerated only as long as you don't make a nuisance of yourself.
>> It seems to me that your describing only one side of the proverbial
>> "between a rock and a hard place"
>> A small ISP that gets a provisional assignment from ARIN is no worse
>> than a small ISP that has LIR-assigned numbers. If their upstream
>> LIR decides to jack up their rates, and their only option is to
>> go to another upstream feed, they are going to have to renumber anyway,
>> thus downstream customers will have to renumber.
> If I had PA space (I don't) and that happened, I would just pass it on
> to the customer as a fee.
which then triggers the scenario you originally described, the
"screw this, if I have to renumber anyway, goodbye" which your
trying to avoid, I thought.
> I believe we will see the routing table
> explode as people grab PA space and multihome it, sending everyone
> scrambling to damp it with new prefix filters.
>> The only small ISPs that would come out worse under this are the
>> ones who qualify NOW under the multihomer section, and are sitting on
>> their hands doing nothing - and the ONLY THING they lose is that
>> they know that if they file for an initial allocation sometime in
>> the next 2 years, that is under a /20 in size, that it might be
>> permanent if they upgrade later. But if they don't qualify now, in
>> 2009, then when do they think they will qualify under Section 18.104.22.168?
>> Next year? Two years from now? I got news for them - by then the
>> virgin IPv4 will be gone. And if they DO qualify now and are doing
>> nothing, then why are you wanting to allow them to continue to do
>> nothing for the next 2-3 years until IPv4 runout makes it so they
>> definitely won't be able to get numbers from the RIR?
> Are there really any ISP's out there operating on a single /24 anymore?
> (serious question) The days of small ISP's with a rack-o-modems in the
> back room is long gone. No policy change we make will motivate anyone.
I think there's WISP's operating out there with 2 or 3 /24's.
>>> Why would their assigned space go away post runout? Are they forced to
>>> give it back or something? I must have missed something.
>> It won't go away but you can imagine that in a few years after IPv4
>> runout, that LIR's who are having to pay a lot of money for IPv4
>> transfers for new blocks are going to pass those costs along to
>> their customers, particularly customers who have a lot of IPv4
>> from them.
>> And in some cases, suppose a customer has a /22 from an ISP that
>> went bankrupt, and was sold to a second ISP, and that second ISP
>> already has a /17 with space available in it, well that second
>> ISP may go to that customer and tell them they have to renumber
>> into the /17 so that they can vacate the /22 and sell it.
> I'd "sell" my /22 and /21 on a transfer if this kind of policy hurts me
> enough to where I need to money to close up without a bankruptcy, so
> keep that in mind when crafting policies that could potentially drive
> someone of my size out of business and help create supply. Maybe shell
> it out to the brokers I mentioned earlier.
I don't think our idea is to try driving someone small out, rather the
reverse. Our idea is that the small ISP's are going to get hit with
this IPv4-to-IPv6 transition and it's going to be painful for them,
more painful than for the large ISPs - yet, it wasn't the small ISPs
out there chewing up IPv4 space lickty-split that is causing the
IPv4 runout to begin with. It's a bit unfair.
>>> So then let me ask a practical question.
>>> I have a /22 - been using it for a few years now since renumbering from
>>> two PA /24's. I just got a /21 because I moved to a new, larger place
>>> only last month giving me the physical space to take on more colos. What
>>> happens when I need to apply for more space? Do I just tell my customers
>>> too bad you can't expand and close up shop when too many leave?
>> You did not get your numbers when a policy like this was in force so you
>> never agreed to renumber and return that /21 in order to get a larger
>> additional allocation. It's only the people who haven't filed by
>> the time a policy change like this goes into effect who are going to
>> have to agree to renumber and return their small holdings.
> Can't this possibly trigger people starting to horde addresses earlier?
> First thing that came to mind for me is "crap, I'd better think about
> latching on to some additional space right now if this passes."
I think the looming IPv4 shortage has already caused a lot of people to
I just yesterday setup a brand shiny new T1 for a customer to a national
ISP (not us, unfortunately) and they were applying a /30 to the span
itself - separate from the /29 that went to the customer. It was public
IPs, not private, not unnumbered. Of course there's tons of legitimate
technical reasons that they might choose to do this. But, it's POSSIBLE
to do it unnumbered. I would think that post-IPv4 runout in about 5-10
years, that this national ISP will be running unnumbered on these links.
Does this national ISP's use of a public /30 today on a span constitute
hoarding? Well, let's just say that if 5-10 years from now their
policy is to run unnumbered on T1 spans, then there seems to be no
technical reason they can't do it today. Sure it's only 4 numbers -
but this is one of the largest national ISPs out there, and I'm sure
they have tens of thousands of spans.
I think in 5-10 years we will be looking at this particular ISP and
be saying "yep, they were hoarding" And they won't be the only
ones. Likely there will be a horde of hoarders. ;-)
>>> I guess I really don't understand this at all and as long as I'm
>>> protected as legacy, so I withdraw my original opposition and neither
>>> support nor oppose this policy.
>> I can't guarantee you will be protected as legacy, as there's been
>> discussion in the past about the old legacy holders from pre-ARIN days
>> and possibly getting some of their /8's and such back. But, I
>> think that the very largest players on the Internet are totally
>> uninterested in participating in an IPv4 transfer market because
>> they know that as they have the deepest pockets, they will get the
>> most screwed over - and as a result, they all are planning on being
>> ready with IPv6 when IPv4 runs out.
> We can't really do anything about pre-ARIN or existing agreements, so
> it's best to forget about it and move on and up. But I don't believe
> they are all planning on IPv6 in the near term. See my recent somewhat
> public fight with Verizon re: exactly that. Maybe if someone could
> convince the world to route IPv6 as fully as IPv4... but no, they're
> trying to keep costs down, and *not* supporting IPv6 completely is part
> of that goal.
There is a famous old quote (which I can't find the source to right now)
"My enemies make their plans out of wire, I make my plans out of string,
because string is a lot more flexible than wire"
I suspect that a lot of them are making their IPv6 deployment plans
out of string.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML