[ppml] Policy regarding subnets smaller than /64

Brian Dickson briand at ca.afilias.info
Fri Nov 16 18:06:26 EST 2007


Scott Leibrand wrote:
> Ok, so you basically want to be able to SWIP (reassign to customers) 
> prefixes longer than /64?
>
> I don't think that is necessary, and feel that it would have enough 
> negative side effects to be something we don't want to encourage.  
> Consider a monopolistic telco, for example, who likes to artificially 
> differentiate and charge more for "value-added" services.  If they are 
> allowed to do so, they may wish to assign /124s to all their 
> customers, on the assumption that if you have more than 16 hosts, you 
> obviously need a more expensive tier of service.  This would stifle 
> innovation at the edge, precluding the use of HBA, CGA, or 
> autoconfiguration. 
I don't think the inability to SWIP addresses will in any way affect the 
behavior of any monopolistic telco.
And as such, I think the telco vs SWIP issue is a red herring.

I agree that entities allocating prefixes to customers without 
consideration of the needs of customers, will harm innovation (and 
customers).

I do not agree that it is the business of ARIN to attempt to curb 
monopolistic abuse - there are much better places, and much better 
equipped organizations, for that kind of activity (e.g. FTC, FCC, DOJ, 
etc. in the US, and similar organizations in the other ARIN countries.)

And, considering that I already gave an example of how SWIP of a prefix 
/N, regardless of the value of N, is an activity that could be 
considered not only valid, but necessary, I have to emphasize that I see 
this as important for support of non-trivial deployments of IPv6.

> In my opinion, if you have different organizations, different 
> contacts, etc. for different networks, there's no real reason not to 
> give a different /64, /56, or /48 to each org as needed.
Forcing specific sizes of end-use *within* a site, flies in the face of 
allowing sites to use IPv6 as they see fit.

Brian




More information about the ARIN-PPML mailing list