[arin-ppml] IPv6 Non-connected networks

[Steve Bertrand]

On 2010.03.30 17:25, Chris Grundemann wrote:
> 
> 
> On Tue, Mar 30, 2010 at 14:50, David Farmer <farmer at umn.edu
> <mailto: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 <mailto:farmer at umn.edu>> wrote:
> 
>                 A ula.nro.net <http://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 <mailto: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).

When ULA-C does succeed, my preference would be to have each RIR manage
this space for itself, so policy decisions can be made in the same
fashion by the same people who create the policy for the rest of the
regional space.

Although I don't follow too closely or participate, I belong to the RIPE
addr pol group. I like some of the things that they are doing, but there
are some things that make me happy to be in the ARIN region. I can't
even fathom the policy/discussion nightmare if there was only one
central, global authority.

I think that IANA should designate a very large single block for ULA-C,
divide it up, and allocate this space to each RIR, keeping at least 33%
reserved in the event new RIRs pop up.

Administratively, an RIR should be able to utilize their existing
infrastructure to manage this space in a separate but similar matter,
and operationally, it would allow engineers/ops to make filtering
decisions for ULA-C based on global, regional, or Joe's network.

I don't have a problem whatsoever if Mike's net wants to slot in Joe's
ULA-C, or if I want to allow a route to connect a couple of mutual
clients that are a few blocks away from each other. I do have a problem
if the entire ULA-C space is not aggregate-able into one (or a small
number) of prefixes.

Also, if filtering/classification is easy, then I also don't have any
problem with ARIN charging lessor fees then PA/PI, so long as the lessor
cost is directly relevant to the time savings they (ARIN) achieve if
less overhead administrative and/or management work is required.

Each to their own. From my (relatively limited) experience in S&M
enterprise I can see the desire for ULA-C, particularly from the
standpoint of networks that _require_ *true* division and separation.
>From the SP side of things, I'd rather just see CPE get fixed in order
to eliminate NAT ;)

Steve