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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
