[ppml] Policy regarding subnets smaller than /64

[Brian Dickson]

Scott Leibrand wrote:
> Brian Dickson wrote:
>>
>> The problem I'm illustrating is the hammer/nail problem.
>> If it is not *possible* to do any kind of bit-mapped plan, then we 
>> are not supporting those who *might* choose to (or need to) do so.
>
> Ok.  I'm not opposed to allowing the use of subnets longer/smaller 
> than /64, although I do oppose your earlier policy proposal to 
> encourage it via ARIN guidelines.
>
>> This is neither about encouraging, nor about requiring, a particular 
>> plan. It is about *allowing* it, by providing the essential tools to 
>> support it.
>> The only tool needed, currently, is the ability to register 
>> allocations >/64 - something I perceive the current policy to 
>> prohibit. (And now we stray into discussions about policy, rather 
>> than about the use cases.)
>
> Ok, let's discuss the policy then, as this is the public policy 
> mailing list.  :-)
>
> IMO it's entirely appropriate to use subnets smaller/longer than /64 
> for certain use cases, like the one you outlined.  I do not believe it 
> is appropriate to allocate anything smaller/longer than a /64 to a 
> downstream customer, as doing so limits their ability to grow as 
> needed.  In order to support your subnetting scheme, I believe an LIR 
> should reassign an appropriately sized netblock (/64, /56, or /48), 
> and the recipient network should subnet that assignment as needed to 
> support their need for variably-sized subnets.  If they don't need an 
> entire /64, then they can reserve the rest of it for future growth.
>
As long as the ability to do assignments within the allocated block 
below the /64 exist, I don't have a big problem with making a /64 the 
smallest aggregate available for assignment.
(I do think it would be reasonable to assign longer prefixes, but I 
acknowledge that those of us who feel that way are currently in the 
minority, or are primarily lurkers on the ppml.)
> What other "essential tools" do you believe are missing from current 
> policy?
>
> -Scott
None that I am aware of.

Can anyone else think of requirements that would affect ARIN policy? Or 
requirements of any kind?

(The development of dual-stack address management tools is left as an 
exercise for the LIRs and/or their customers. :-))

Brian