[address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central)

Geoff,

Thanks for this background and analysis.

> i.e. What is the problem that C-ULA addresses are intended to solve
> and what alternatives are available to us in looking at this
> problem? So far I have yet to see the proposer of this policy
> address this quite basic question. I suspect that the proposal would
> be a fair deal clearer in intent, and a fair deal clearer in terms
> of whether or not the proposal should be adopted, if we all clearly
> understood what the underlying problem (or what shortfall in the
> existing address distribution mechanisms) is that this proposal is
> intending to address.

I think this is the key question.

RFC 4193 hints at the use cases, although does not talk too much about
the motivation for these addresses.


The basic motivation for local IPv6 *seems* to be RFC 1918 space
(10.0.0.0/8 and the like) for IPv6. That makes a certain amount of
sense. RFC 4193 space basically works like that today, right?

The motivation for a version with a central registry however is not so
obvious to me. The only justification I can think of is that you can
be sure not to pick the same /48 as someone else has picked. But the
chances of that are *billions* (that's "thousands of millions" to
British folk) to one!

If you consider a 1:10000000000 odds too great for you, then there are
a couple other options:

- get a /48 from someone with an RIR allocated block

- take an IPv4 address that you have been assigned and convert it to a
  2002::/48 block

People more clever than me will surely be able to think of other
options.


If the motivation is something beyond the scope of basic networking,
then the use cases should be outlined more clearly.


>     - the 'nature' of the distribution function for this part of the
>       IPv6 address appears to be an allocation to be undertaken in
>       perpetuity. 

If we do decide we need a central registry for local IPv6 addresses,
then looking at these local addresses as if they were comparable to
the current RIR allocations is a mistake IMHO.

If there were to be a central registry, I think the simplest model
would be the best:

- The *only* thing that the registry would contain is a list of which
  /48 have been allocated.

- Once allocated a /48 is allocated forever.

- The list would not be publically visible (I would prefer that it be
  visible in the interest of transparency, but then someone could
  learn *when* a specific /48 was allocated, which could in theory
  have some privacy implications).

There is no "ownership" or "transferance", no privacy issues. If you
somehow forget which /48 you had, get another one.

The routeability issue is the same as for RFC 1918 space I think. The
existing RFC already says in big letters "please don't be route this".

I don't have any answers about DNS, because frankly I think reverse
DNS is stupid, and IPv6 reverse doubly so. Hey, I'm prejudiced, I
know. :)

>    - Distribution functions. Should there be some form of 'wholesale'
>      form of bulk access to this registry, to allow, for example, a
>      manufacturer to place pre-paid prefixes into manufactured devices?
>      If not, could this form of use of the central registry services be
>      supported using mechanisms described in the current proposal?

This is a possible concern. But I think this indicates that there are
other use cases that need to be considered. Right now the IETF seems
like the best place to handle these, not the RIRs.

--
Shane