[arin-ppml] IPv6 Non-connected networks

Chris Grundemann cgrundemann at gmail.com
Tue Mar 30 17:25:49 EDT 2010

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

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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100330/b91c3980/attachment-0001.html>

More information about the ARIN-PPML mailing list