[ppml] Policy Proposal: IPv4 Soft Landing

David Conrad drc at virtualized.org
Fri May 11 15:40:30 EDT 2007


Hi,

On May 11, 2007, at 9:06 AM, David Williamson wrote:
> On Fri, May 11, 2007 at 04:14:31AM -0400, Member Services wrote:
>> Policy Proposal Name: IPv4 Soft Landing
>
> This is, by far, the best idea I've seen along these lines.

Thanks.

> The
> staging would enforce a gradual buildup in requirements for further
> IPv4 allocations, and provides a nice 'carrot and stick' approach to
> forcing migration to IPv6.

Actually, it is more of a "growing stick" approach.  The carrot is  
handled elsewhere (e.g., waiver of IPv6 fees).

> Still, as much as I'd like to say I'm in favor of this proposal, I'm
> hesitant to do so.  On philophical grounds, I'm not sure that a soft
> landing is strictly necessary.  When we run out of IPv4 space, we run
> out of space.  Once we're out, does it matter if the landing was hard
> or soft?

Yes, very, VERY much so.

The issue here is that Internet resource management does not operate  
in a vacuum.  There is constant pressure that most of you all don't  
see for Internet resource management to be done by "professionals",  
e.g., within national governments, the ITU, other international or  
inter-governmental treaty organizations, etc.  Failure to adequately  
provide for at least some semblance of a reasonable transition from  
Internet v1 to Internet v2 will be used as justification for a  
fundamental restructuring of how Internet resource management is done.

To date, there have been no proposals that explicitly try to drive  
increased deployment of IPv6 as a means to get over the chicken-and- 
egg problem that has hindered the deployment of IPv6.  "IPv4 Soft  
Landing" is a first, undoubtedly flawed attempt to try to provide  
real incentive for a transition.

> As long as we can walk away, it's a good landing, and IPv6
> provides an alternative network protocol.  If your organization gets
> screwed by the lack of IPv4 space, perhaps you should have been  
> looking
> at IPv6 earlier.

"Hi Grandma.  You can't send e-mail?  Well, of course not.  You  
didn't deploy IPv6 on your home router.  What were you thinking?!   
Sheesh.  By the way, how's that new IP-monitored pacemaker working?   
Err, hello?  Hello?"

The vast majority of people using the Internet are not aware and if  
they were would not care about whether they are using IPv4 or IPv6.   
What the vast majority of people using the Internet care about is  
reaching the content that is relevant to them.  Saying "you should've  
known better" when an infrastructure that national economies depend  
on runs into trouble is the right approach if you want governments  
involved.

IPv6 has created a second Internet.  Unfortunately, all the services  
and content are still on the old Internet.  As long as there is no  
incentive to start populating the Second Internet, people are not  
going to migrate.  Got to break the chicken-and-egg problem somehow...

> The other reason I don't think I can quite endorse this proposal is
> that it is entirely focused on ISPs and PA space.  There's no mention
> of how PI assignments might be handled, and I think that's a fatal
> flaw.  Perhaps a revision to account for that is in order.  I'm told
> that very few PI applicants come back for more space, so we'd have to
> have a phased policy change that forces initial assignments to be much
> more difficult to get.  (And additional space, too, of course.)

This would go against current trends of liberalizing PI allocation  
policies in all RIRs.

One reason I didn't include PI in this proposal is that it was my  
impression that PI allocations make up a really, really tiny of all  
address space that is allocated.  I thought it best to go for the big  
targets first.  It may be that my assumptions were wrong... ARIN  
staff might be able to provide input on this.

However, with that said, I'm happy to revise the proposal to include  
a second section that deals with PI.  Or, perhaps better, provide a  
second proposal as adding a second section might trigger Michael  
Dillon's "too complicated, too long" rants (:-)).  (Those rants, by  
the way, I generally agree with -- policies should be short and to  
the point).

Rgds,
-drc




More information about the ARIN-PPML mailing list