[arin-ppml] IPv6 Non-connected networks
David Farmer
farmer at umn.edu
Tue Mar 30 16:50:27 EDT 2010
David Farmer wrote:
> William Herrin wrote:
>> On Fri, Mar 26, 2010 at 10:39 AM, David Farmer <farmer at umn.edu> wrote:
>>> A ula.nro.net type mechanism is the way to coordinate the creation of
>>> the
>>> random prefixes. How about something like this.
>>
>> David,
>>
>> Something is escaping me here. For *registered* ULA's what's the point
>> of randomization? Wouldn't we better served with sparse? Or perhaps
>> split the space and do half sparse and the other half linear when the
>> requested net count is too large for the largest free space in the
>> sparse area?
>
> I'm not sure it is entirely necessary. But, there is an elegance to
> both kinds of ULA using an identical prefix selection algorithm. The
> only difference is if the Local/Central is being set or not. Which I
> believe was the original intent of how ULA was designed. This would also
> underscore the differences between ULA-C and PI addressing.
>
> Some people have said that ULA-C needed to have a random prefix
> selection algorithm too, I don't really care either way. But, if we
> allocate large blocks to the RIRs, why not let the RIRs manage the whole
> assignment process and just use their normal processes. I don't see any
> benefit to allocating large blocks and then requiring the RIRs to use a
> random prefix selection algorithm within those blocks. If your going to
> have a different prefix selection algorithm, between ULA-C and ULA-L,
> why make a third one, just use the RIRs normal one.
michael.dillon at bt.com wrote:
>David Farmer wrote:
>> for assignment to organizations using process similar to
>> those used for GUA today and using policies designated by the
>> RIRs.
>
> This risks people doing things like blocking ULA-C addresses
> from other RIR regions but routing them openly in one region.
> The current thinking has been to allocate them randomly so
> that they cannot be aggregated either by network or by region.
As I said I'm agnostic on this point, there are a number of people on
the list who want large blocks assigned to each RIR, we need to pick one
or the other. Who wants to compromise? But their is no point trying to
move this forward if we can't find consensus on this point.
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
More information about the ARIN-PPML
mailing list