[arin-ppml] IPv6 Non-connected networks

[Chris Grundemann]

On Tue, Mar 30, 2010 at 14:50, David Farmer <farmer at umn.edu> wrote:

> 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.


Allocating them randomly (no regional blocks) will further discourage their
use as cheap-GUA-equivalents at any point in the future as it causes the
most pain to do so. Therefor, this is the best course of action if we want
ULA-C.

This is of course slightly more complicated than handing out regional blocks
since it requires a truly central registry (as opposed to the five distinct
registries for GUA, ASNs and IPv4) but I think that can be overcome without
too much difficulty. There are three possibilities:
1) IANA takes on the duty directly
2) IANA delegates the duty to an existing RIR (or group of RIRs)
3) IANA/ICANN create a new ULA-C registry

In any case, the assignee interface should remain at the current RIR level,
keeping the new duties to the bare minimum required to guarantee uniqueness
(a prefix generator and a directory).

~Chris


>
>
>
>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu <Email%3Afarmer 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
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100330/b91c3980/attachment.htm>