[ppml] Policy regarding subnets smaller than /64
briand at ca.afilias.info
Fri Nov 16 16:26:18 EST 2007
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
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. :-))
More information about the ARIN-PPML