[ppml] Policy regarding subnets smaller than /64

Scott Leibrand sleibrand at internap.com
Fri Nov 16 17:39:04 EST 2007

Brian Dickson wrote:
> Scott Leibrand wrote:
>> I'm not sure I understand your first use of "assignment" there.  
>> Currently, there's nothing to stop you from *using* a longer prefix 
>> as a subnet.  Are you advocating for something more than that, like 
>> the ability to assign a network longer/smaller than /64 between 
>> organizations?
> Yes. The analogous kind of thing would be the ability to assign down 
> to a /29 in IPv4.
> Registration of what is used, can be important for all of the things 
> that go along with registration, e.g. different abuse contacts, 
> technical contacts, etc.

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 think 
the current guidelines are much more appropriate, encouraging /56's for 
residential users, /64 for networks with known single-subnet needs, and 
allowing everyone who wants a /48 to get one.

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.

> Ditto delegation of ip6.arpa reverse mappings on the nibble boundary, 
> below the /64 level (not sure if this is an issue, but just want to 
> list it as something necessary for such assignments.)

I'm pretty sure this can be done today.


More information about the ARIN-PPML mailing list