[arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

ggiesen+arin-ppml at giesen.me ggiesen+arin-ppml at giesen.me
Tue Jun 23 21:01:42 EDT 2015


Adam,

 

In an ideal world, I would like to offer address space to anyone who wants it. In reality, in drafting the original proposal (I am the author), I had to try to balance a number of factors:

 

1)      Cost of end-user renumbering

2)      Cost to everyone else to carry the prefix

3)      Cost to everyone of lack of (or slow) adoption of IPv6 because users can’t get address space

4)      Cost to everyone of technical hacks such as NPT

 

In the end I hope the 13 site threshold (/40) - (which is based on 6.5.8.2) struck the right balance. They are the third tier in terms of allocation size (/48, /44, /40), so as to avoid unnecessarily polluting the routing table with every mom and pop shop, but small enough that organizations who would have genuine hardship without being able to get their own address space would be encouraged to adopt IPv6 rather than delay or implement technical hacks.

 

Cheers,

 

GTG

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Adam Thompson
Sent: June-23-15 8:46 PM
To: Matthew Kaufman; arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

 

I'll point out that at my current employer, I cannot justify obtaining PI v6 space. So I've deployed ULA + NPT in order to guarantee uniqueness.
I see IPv6 allocation making some of the same assumptions humans have made through time (e.g. "640k should be enough for anyone "), so I'm not sure I *should* be able to get PI space.

NAT, NAT66, NPT, etc. are ubiquitous enough that anyone designing "pathological" protocols that rely on embedded IP addresses (e.g. FTP, SIP, et al.) should probably be taken out behind the shed and put out of their misery.

Based on that, I disagree that ULA+NAT is harmful to the internet anymore. That ship has already sailed. (Irony: my phone autocorrected that to "failed". How true.)

Nonetheless, I don't oppose this policy.

If we truly want to get rid of NAT and eliminate "unreasonable" renumbering costs , there can logically be no needs testing at all. Renumbering even a 10-person office would be an unreasonable expense to me.

I don't feel strongly about this, but the individual points the policy considers *are* valid.

Here, have another bucket of popcorn...

-Adam

On June 23, 2015 7:25:06 PM CDT, Matthew Kaufman <matthew at matthew.at <mailto:matthew at matthew.at> > wrote:

On 6/23/2015 1:07 PM, ARIN wrote:

 Recommended Draft Policy ARIN-2015-1
 Modification to Criteria for IPv6 Initial End-User Assignments



I am of mixed opinion on this policy. I agree that it should be quite 
easy for an organization to receive their own IPv6 space. And I was 
fully supportive until I got to "many smaller enterprises are unlikely 
to adopt IPv6 (currently perceived as an already tenuous proposition for 
most users given current cost/benefit)". Since there's still major 
barriers to deploying IPv6, despite this being over a decade since it 
should have happened, the amount of popcorn I am able to consume as an 
observer over the next few years if smaller enterprises find even more 
reasons to not adopt v6 (such as the one this policy wishes to correct) <
 br />is
vastly increased. I like popcorn, and so I'm opposed on that basis alone.

Matthew Kaufman
matthew at eeph.com <mailto:matthew at eeph.com> 


  _____  


PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150623/2e9543b3/attachment.htm>


More information about the ARIN-PPML mailing list