[ppml] Policy Proposal: 2007-12 IPv4 Countdown Policy Proposal

[michael.dillon at bt.com]

> Others have already raised that we may want to alter the IANA to
> RIR policies so they don't have to allocate /8's, and to better allow
> all the RIR's to run out around the same time.  I like that concept,
> but I'm a bit unsure exactly how to put that into policy.

Personally, I would suggest informal discussions with people from all
regions first. Then draft a policy along with co-authors from RIPE and
APNIC areas, at a minimum. Get LACNIC and Afrinic co-authors if you can.
Then send a copy of the proposal to nro at nro.net announcing that you
intend this to be a global policy. And then submit it to one or more
RIRs, noting prominently at the beginning of the Rationale (or whatever
section) that this is intended to be a global policy. Obviously, having
a co-author from each RIR helps greatly in submitting the policy
proposal to the RIRs and in presenting it at each RIR meeting. Nobody
has to travel very far.

I think that will greatly improve the wording of your proposal, knock
off rough edges that won't fly in other regions, build a groundswell of
interest, and set you up well for the hard part. Which, of course, is
getting people to vote for it.

> 2) How do we manage the "run on the bank" as the space runs out.  No
>    matter what this will occur, the goal is to make it the 
> least painful.

Somehow we have to have tighter policies akin to gas-rationing of the
Nixon years or food-rationing in Europe during and after WWII. But we
don't need to put rationing in place until it really is needed because
IPv6 uptake may be on an exponential track, ready to explode in 3 years
from now and save us.

> 3) How do we manage the IPv4 space when it is "full".  Do we have to
>    alter any of our policies to properly function in that world?

We need to make sure that we KEEP TRACK of the address space so that it
can be reclaimed and reissued if needed. Maybe 20 years from now someone
will come up with a great application for IPv4 networks that need to be
run separately from IPv6 networks.

> 4) How do we make sure the RIR is effective in the new world?  In
>    particular I'm concerned about our IPv6 policy keeping up with the
>    market if there is an accelerated shift.  We don't have enough
>    experience with the existing policy to fine tune it for widespread
>    adoption.  It's likely the rate of change will outpace the 
> RIR's policy
>    process.

I've always thought that ARIN was not terribly innovative or
entrepreneurial. RIPE builds tools and runs measurement projects. APNIC
has a chief scientist. ARIN could do a better job in building new
services that are of value to the whole community. 

1. Replace the bogon list with the official ARIN list of address ranges
in good standing
2. Run an ARIN clearing house for network abuse incidents. This would be
an automated system rather like a blacklist that would accept issues
from members regarding an address range, and report statistics to the
public. For instance, AOL might send in an issue like "Address block a
through B sent me 16,782 SPAM emails today" and I might subscribe to "a
list of address blocks which have sent greater than 10,000 SPAM messages
in the previous 7 days but don't count reports from AOL and GoogleMail".
3. Run a lit-address service that is good enough that ISPs can, during
their provisioning and decomissioning processes, report when they light
up an address range for a customer. Then, people can build finer grained
filters that block traffic from unused address ranges within an ISP's
allocation. Don't accept the argument that SOME hardware can't do this
filtering because hardware continues to improve.
4. Run a meetme service that applications can use to break through NATs.
For instance, I boot my machine in a hotel room and my
voice-conferencing app tells the ARIN meetme service where I am. If
someone calls me, their app asks the meetme service how to reach me
which tells them what to do. Maybe they can send packets to a specific
port on the hotel's NAT gateway. Maybe they can send packets to my
hosted relay server in Germany. Or maybe they can relay a connect
request to me via the meetme server and my app will call back. The point
of course, is to facilitate NAT without needing every protocol to come
up with STUN-alikes (Google SIP STUN). And facilitating NAT means fewer
registered IPv4 addresses are needed. A meetme service like this needs
to have servers as widespread as the DNS roots, i.e. all over the world
are major traffic interchanges. It doesn't work as a commercial product
because there needs to be ONE service in the infrastructure, like DNS.

ARIN is a service organization. It runs the in-addr.arpa service, the
(creaky old) whois service, a route server, a registry service, and so
on. Why not some new stuff too.

> Absolutely.  I believe we need to make policy in all of these other
> areas as well.

Only make policy if it is absolutely necessary. 

> I think now is the time for people to start thinking about proposals
> for the fall, so they can be socialized at the spring meeting and
> posted shortly afterwards.

--Michael Dillon