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

Owen DeLong owen at delong.com
Tue Feb 22 22:00:39 EST 2011


On Feb 22, 2011, at 6:04 PM, George, Wes E [NTK] wrote:

> -----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.
> 
As I said, I have neither time nor resources to conduct such a study, nor do I think that one
could be meaningfully conducted in the time remaining before the proposal will be overtaken
by events.

> [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"

This may be true, but, what happens when the default configuration ALSO doesn't work
due to the fact that some of the modifications to the default were done for a reason other
than just randomly changing the address?

What about the situation where there are multiple hosts that have static addresses
configured on them behind said CPE in the same network range, but, outside of
the DHCP scope?

What about the scenarios where the people on site don't even really know how to recognize
the router. Some consultant set it up years ago and nobody has touched it since.

These aren't just residential customers that will be effected. They'll be the majority,
but, you also have to include many SMB and SOHO customers as well.

Owen




More information about the ARIN-PPML mailing list