At 01:03 AM 3/05/2007, Shane Kerr wrote:
All,
I think the draft this proposal refers to:
http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01
Is an early version of what eventually became RFC 4193:
http://tools.ietf.org/html/rfc4193
The RFC does not have any centrally assigned addresses.
I didn't actually follow the discussion in the IETF about this document, so I don't know why the centrally assigned version was removed.
The IETF history of this document was that an original proposal was for two pools of ULA addresses - one a "self-draw" and one "centrally assigned". The draft was split into two drafts, and the draft describing the "self-draw" pool was published as RFC4193 while the IPv6 working group abandoned work on the centrally assigned address pool
It's not actually clear to me what the policy proposal is. Does it intend for the RIPE NCC to act as a central registry for all local IPv6 addresses? Does it intend for a special membership category be set up for this?
I posted the following comments and question to the Afrinic policy mailing list in response to this proposal - I suspect that these questions and comments are relevant here as well. When this was under consideration within the IETF some years back I performed an evaluation of the draft from the perspective of the RIRs as a potential operator of this service. In reading through this proposal these considerations appear to remain relevant today, and it may be useful to consider these issues when considering the operational aspects of provision of such a registry service. The evaluation report included the following considerations: ----------------------------------------------------------------- - the 'nature' of the distribution function for this part of the IPv6 address appears to be an allocation to be undertaken in perpetuity. It is possible to interpret this allocation in terms comparable to some form of 'freehold property' given that the self-allocation via the central registry gives the entity exclusive unqualified right of access without any form of expiration or renewal of the original allocation. Current RIR allocations of unicast public address space are undertaken under conditions that are broadly consistent with a non- assignable lease. It may be that this issue of assignments performed in perpetuity vs fixed period renewable assignments should be a matter of choice by the client as the time of assignment, and that pricing for this address assignment reflect the different cost structure of secure maintenance of assignment records for a fixed period vs costs for this record maintenance to be undertaken in perpetuity. - it is unclear whether the privacy of the assignee is intended to absolute or under what circumstances the central registry operator would divulge this information and to whom. It was noted that all information held by the RIR is not covered by any binding privilege. It is the case that such RIR-held information is discoverable by others using legal means under certain circumstances. Open questions include: Would anyone be able to ask whether a specific prefix was allocated or not? Would a holder be able to 'recover' their prefix from the registry? Could a holder request the registry to expose their holding to a specific third party? Could the privacy requirement be changed at a later date? Would any future changes to the privacy requirement (or any other characteristics of these addresses) be a policy matter to be determined within the addressing community, or would any changes to the characteristics of this space remain solely within the purview of the IETF? - Permanence of allocation. Should there be a capability for an assignee to voluntarily return an allocation? How can the assignee and the returnee be matched? If the allocation is not public knowledge how can a return be effected? Should these allocations be permanent or of some fixed term with a periodic renewal option? - 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? - Associated information and pointers. The proposal is silent on reverse DNS for these prefixes. Perhaps the final version of this document could explicitly say that this requires private DNS (two- faced DNS) deployment and that placing these prefixes in the ip6.arpa zone is not to be supported. Or should such reverse DNS delegation be allowed? After all these global IDs are unique and in and of itself putting them in the public DNS is not going to harm the DNS. Of course the random nature of these assignments has the potential to, over time, create an extremely large flat DNS zone. This may have implications in terms of signing the zone with DNSSEC of course. Some guidance the preferred approach of populating the DNS reverse zones would be preferred, if reverse DNS is to be supported for these addresses. If this reverse DNS is to be allowed, does this compromise the private nature of the assignment? The proposal is also silent on WHOIS entries. It appears that there is an explicit privacy issue where that precludes any inclusion in the WHOIS databases, but an explicit statement to this effect in a final version of this document would be preferred. It is probable that inclusion in the public DNS, whois information and the privacy of these assignments are related matters. - Routability of these prefixes. The RIRs maintain that they take no position on the routeability of prefixes that they assign. It would appear that this position extends to this central registry managed site local prefix. - There is no doubt that there would be some effort expended on the part of the RIRs to implement this registry operation. Pricing for the service may need to be determined within the parameters of a cost recovery function for operation of the function distinct from the costs of other RIR functions, and within the parameters of the anticipated costs of secure maintenance of records in perpetuity. The is some consideration about the true distinction between C-ULA address blocks and conventional unicast address blocks. If the address allocations in the C-ULA block are published by the RIRs in precisely the same manner as other unicast address allocations, are able to be entered into the reverse DNS in the same manner as other unicast address allocations, and if the RIRs are not the determiners of whether an address block is actually routeable or not, then what precisely is the distinction between this C-ULA address distribution function and the conventional unicast address distribution function? Why are C-ULA address necessary? What problem is this proposal actually attempting to solve here? And if the problem can be identified clearly then the subsequent question is whether there are alternative mechanisms that could solve the same problem in different ways? 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.