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

[George, Wes E [NTK]]

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Tuesday, February 22, 2011 8:37 PM

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.)
[WEG] Appreciate the other anecdotal evidence. I never doubted that there were defaults that did
strange things. I think that the important point is the statistical distribution to characterize how
much of a risk these assorted "weird" implementations may be, rather than the examples themselves.

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.

[WEG] If someone changed it from the default, it's perfectly acceptable to say "sorry, that
configuration is not supported, please restore the defaults and let us know if that resolves the
problem"
There are far more frustrating things in most ISP's support scripts when you call them for
troubleshooting assistance than a request to restore the default config. I simply don't buy the
argument "we can't do that on the off chance that someone might have changed their config from the
default in a way that might break things"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6781 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110223/3dec7ae9/attachment.p7s>