Subject: [NRO comment on ULA 3] Needed changes

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Jun 2004 06:31:00 -0400

3) Separate from 2), are there any areas where the RIRs think some
     changes might be useful to consider, based on their experiences and
     perspectives? E.g., are there particular operational concerns?  Is
     the document overly prescriptive in ways that don't necessarily
     seem helpful? Are their potential issues that this document doesn't
     address (or doesn't speak enough to) that warrant additional
     thinking/discussion?  I think it would be useful to discuss these
     (with the WG), as they may be willing to revise some of the wording
     accordingly. (i.e., although the WG has asked the IESG to consider
     the document, do not take that as meaning additional input would
     not be welcome or that the document is unchangeable at this point).

A number of aspects of this address space have the potential to raise
issues:

      - 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 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 charge
        applicable to this service 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, but may well not be
        limited to:

          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-registered prefixes into manufacture
       devices?  If not, could this form of use of the central registry
       services be supported using mechanisms described in the current
       draft?

     - Associated information and pointers. The draft 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 from the IETF on 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 draft is also silent on WHOIS entries. It appears that there
       is an implicit privacy assumption which precludes 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 mintain that they take no
       position on the routeability of prefixes that they assign. It
       would appear that this position extends to any central-registry
       managed site local prefix. It may be that the IESG is also silent
       on routeability of these prefixes as this is more a business/
       operational issue that a standards-based issue.

       It is noted however that while assigned address space may or may
       not be routable, the registration of assignments within a WHOIS
       database is guaranteed.  If prefixes assigned under this policy
       are routable yet not registered, then that assumption may no
       longer be valid. In this case, there are impacts on a variety of
       common policies and approaches to operational stability and
       security, which should be understood.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 30 Jun 2004 22:25:32 -0500

Thus spake "Brian Haberman" <[email-masked]>
>           Would anyone be able to ask whether a specific prefix was

This makes sense, whether or not the particular registrant is named.

>           Would a holder be able to 'recover' their prefix from the

What does 'recover' mean in this context?

>           Could a holder request the registry to expose their holding to

Presumably the registrant would be given some sort of non-repudiable proof
of their registration which could be shown to a third party, but the draft
doesn't require this nor does it cover the case where such proof is lost.

>           within the purview of the IETF?

Given that the target market for local addresses are typically those who
would normally not be RIR members, it seems illogical to let the RIRs set
policy over consumers who have little or no representation.  For lack of a
better body, the IETF should retain control.

>        be permanent or of some fixed term with a periodic renewal option?

A return could be effected because the registrar necessarily knows who it
assigned each prefix to, even if that information is not published.  I don't
see how it would be possible for a registrar to discard this information,
since the registrant may want to make changes (eg. DNS, WHOIS) after the
initial assignment, or transfer it to a third party.

>        services be supported using mechanisms described in the current

Can we get an example of how this might be useful?

>        delegation be allowed?

Section 7.0 of the first draft seems to cover this adequately.

>        and the privacy of these assignments are related matters.

The presence of WHOIS entries should follow the same policy as DNS entries.
WHOIS has an interesting corner case, as the registrar may wish to indicate
a prefix is assigned but not to whom (see first question).

>        operational issue that a standards-based issue.

I thought the difference was implicit in Section 4.0 of the first draft with
the general ban on inter-domain routing absent specific exceptions; this is
signiticantly different than merely not guaranteeing routability of normal
unicast prefixes (which is a case of the RIRs covering their asses since
they have no control over ISPs).

Is there a stronger wording that makes this difference more explicit?

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov