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

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.