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