[ppml] Policy Proposal 2007-15: Authentication ofLegacyResources

michael.dillon at bt.com michael.dillon at bt.com
Thu Jul 26 07:53:55 EDT 2007


> ARIN could spend a lot of time, energy, and good will arguing 
> whether or
> not the information exchanged between legacy address holders 
> and whoever
> was allocating addresses is a contract that binds ARIN. 
> 
> Or ARIN could create a policy that incorporates legacy address holders
> into the ARIN process while preserving the expressed or implied rights
> under the rules that existed when legacy address holders were assigned
> addresses 15 years ago.
> 
> Which would be more constructive?

It's not such a simplistic either-or decision. Several people are
bullying ARIN into creating special rights for legacy address holders
based on the fear that legacy holders could win lawsuits against ARIN.
I'm pointing out, that not only is the legal position of legacy holders
weak, but there are other organizations waiting in the wings who can
also launch lawsuits.

While I don't believe fear of lawsuits is a good motive to make policy,
I do think that whenever policy is being made that people need to look
at the big picture. And today, the big picture is in the future not in
the past.

Rather than spending so much effort on enshrining special status that
some people are claiming was given to them 15 years ago, we should be
looking at how to deal with the very real and imminent problem of IPv4
address exhaustion. It is a complex issue that will hurt some
organizations no matter what ARIN does. But we can make policy in such a
way as to 1) minimize the damage and 2) spread the pain.

Spreading the pain, means that ARIN must force legacy holders to provide
justification for their entire allocation/assignment under current ARIN
rules, or reclaim those addresses for those organizations who can
justfify their requirement. Yes, this is robbing Peter to pay Paul, but
when the endgame for IPv4 happens, Paul will be happy to receive a
slightly worn set of addresses rather than nothing at all. And Peter, if
he really needs the addresses, has nothing to fear.

Anyone who does not want to see this scenario come to pass, should
become an IPv6 evangelist within their company and their industry. If
enough infrastructure shifts to IPv6, then the demand on IPv4 can be
reduced to the point where we will never run out of IPv4 addresses.
There is no grand master plan that will make this happen. There is no
organization that will tell us how to do this. There are no experts
whose opinions can be trusted to point the way through the murk. We each
have to educate ourselves on IPv6, study our own company's strengths and
weaknesses, and then navigate a path forward. 

The issue has not really hit the press yet, but it will soon. When it
does, the non-technical people who make buy-sell decisions on the stock
markets, will drive the debate. They are not concerned with technical
details; they just want to know that the CEOs and management teams of
publicly traded companies have control of the situation and have a real
plan to navigate the business through the IPv4 endgame either unscathed,
or reaping great profits. The killer application of IPv6 is that it will
cause  CEOs to sink or swim when the IPv4 endgame tsunami hits us.

This could be sooner than you think. Large ISPs do not go to the RIRs as
frequently as you imagine. And when they do, they receive very large
chunks of space. Go to http://www.apnic.net and type in 126 for the
whois search. An entire /8 to one company. A few more such requests and
the rest of the IPv4 space will quickly be allocated. In addition, there
are several companies who are known to be running out of RFC 1918 space
in their internal networks. They will be applying for large blocks of
registered IP addresses to continue growing their internal
infrastructure.

We really need to spend more time and energy looking at the future,
particularly the IPv4 endgame, and less time worrying about the hurt
feelings of a few people who are hoarding legacy address allocations
that they have no technical justification for.

--Michael Dillon



More information about the ARIN-PPML mailing list