Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] New policy proposal: IPv6 ULA-central

Geoff Huston gih at apnic.net
Sun Apr 1 21:55:27 UTC 2007


At 05:39 AM 2/04/2007, JORDI PALET MARTINEZ wrote:
>Hi all,
>
>This is a new policy proposal, just to make sure to avoid any confusion: It
>is NOT related with the IPv6 PI.
>
>As discussed with the NRO, I'm submitting this proposal to all the RIRs.
>
>Please, read the text and make sure to ask any questions that you may have.


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.

-----------------------------------------------------------------

regards,

   Geoff Huston
   APNIC




More information about the RPD mailing list