[arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension]

[Owen DeLong]

On Feb 22, 2011, at 3:17 PM, George, Wes E [NTK] wrote:

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Tuesday, February 22, 2011 1:08 PM
> Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address
> Extension]
> 
> 
> On Feb 22, 2011, at 7:19 AM, George, Wes E [NTK] wrote:
>> 
>> [WEG] We're going around in circles again. If they were able to 
>> justify this allocation, they would have already requested it (prior 
>> to IANA exhaust) in an effort to reduce or eliminate the need for NAT 
>> in the first place. The problem is that we're trying to insulate 
>> against something that may or may not happen based on expectation of 
>> future growth. Assuming that the same ISP already has enough addresses 
>> for their current customers, it is perfectly legitimate to expect them to transition some of those
> existing customers to CGN so that they have address space available for NAT pools, outside AND
> inside.
>> 
>> Wes George
> 
> Your logic here is flawed. It's entirely possible that they would first attempt to do the right
> thing and request a shared block through the policy process falling back to these requests while
> they are still possible, but, after exhausting the policy option.
> [WEG] No, that's not flawed logic, it just doesn't agree with your view. Possible != only course of
> action. No matter how good of citizens they're trying to be, if the two are in conflict, "right
> thing for the Internet and the world" loses vs. "right thing the company what signs the paycheck"
> most of the time.
> 
> You criticize them from bringing a study that is not ARIN-specific to the ARIN region for what is a
> global issue, but, they tried to address this globally and it failed to achieve resolution.
> [WEG] It failed because people were unconvinced by the same arguments that are being used here, but
> that's not why I brought regional relevance into the discussion. I gave some of the same criticism
> before too. The study is not representative of the pool of devices available outside of the JDM and
> so is too narrow in focus for anywhere except Japan.
> I think it's pretty simple to provide real evidence to support your point:
> Take each of the "usual suspect" manufacturers of CPE gear, and plot out the default block that they
> use - look for commonalities (eg do DLink and Linksys use the same default?) as well as what space
> is not in conflict with any of them. Compare against what you know about your personal network's
> installed base (or failing that, a rough estimate of installed base that is derived from market
> share of each manufacturer * your customer size), and characterize the order of magnitude of risk
> for each block within 1918, either by /24 or by larger block. If you can show that there's more than
> a trivial number of devices populating each block, then that will be good evidence that 1918 isn't
> workable. Otherwise we're left with comments like, "well X% of 20M users is still a huge number to
> have to reconfigure" without knowing what the value of X actually is.
> 
> Wes
> 
> 
I don't have the time or resources to provide you with a scientific study, but, my rough
experience encountering those devices across a wide range of SMB and SOHO
environments where I have done consulting is that there is no safe haven within
RFC-1918 where some significant proportion of these devices are not deployed.
I have encountered boxes which default to:

	1.	Random 10.x.x.x subnet
	2.	10/8 (literally assigning randomly from the /8)
	3.	172.16.0.0/12
	4.	172.16.0.0/16
	5.	172.16.0.0/24
	6.	192.168.x.0/24	(Where X= {0,1,5,10,12,17,22,54,79,100,128, 172,192,224,245})
	7.	192.168.0.0/16
	8.	Completely random subnet picked from entire RFC-1918 range
			(As in when you factory-refresh the device, it picks some random
			10, 172.x, or 192.168 /24 at random. Kid you not.)

In addition to this, I've seen more than a handful of situations where someone chose
to reconfigure the default to some other arbitrary RFC-1918 range. I've encountered
this in a sufficiently high incidence to believe that depending on the defaults to
save you is unlikely to create a positive outcome.

When this was brought before the IETF, I was also unconvinced. After discussing
the matter in person with several affected providers at the Cable Labs meeting,
I became convinced of the problem. It's not like I didn't bring up all the things
you are saying during that discussion.

Owen