[arin-ppml] IPv6 Non-connected networks

[michael.dillon at bt.com]

> > I think that we should go ahead with allocating a /8 for ULA-C 
> > addresses without any significant technical changes to this 
> Internet 
> > draft <http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-02>
> 
> Are there changes between Tony's Draft and this one that you 
> object to?
> 
> Tony's draft seems to be the most current.

That draft is fine. The most important thing missing from
it is mention of the global RIR policy, and a discussion of
what aspects are covered by the RIR policy and what are 
covered by the RFC. For instance, 3.2.1 could be less vague.
The question of renewal and de-allocation is probably out
of scope for an RFC and should be left to the RIRs.

The sample algorithm should be replaced by "the algorithm
to be used by the RIRs' ULA-C registry is as follows". And
that may be a slightly different algorithm. It would be
good if it included a check for collisions, and some means
of resolving the issue of up to 5 RIR's using it at the
same time while maintaining coherency. I expect this is a
job for a NoSQL database rather than a full-blown relational one.

The registration services section might be changed to just
say that the RIRs will operate a single joint directory lookup
service, that is entirely separate from the whois directorys
of each RIR, and that each RIR will place an entry for the entire
ULA-C range in their whois directory with the following 
disclaimer: ...

The DNS issues section should be replaced with a note that it
will be necessary for sites to run their own internal DNS 
in order to handle reverse DNS because ULA-C addresses will
not be accepted in the public ip6.arpa zone. There will only
be a single delegation for the entire zone to an IANA server
that will have no further info, similar to IPv4 RFC 1918 addresses.

5.0 could have some mention of RFC 5156 and note that as a result
the ULA blocks are likely to be listed in bogon lists which result
in active blocking of traffic using ULA addresses.

In 7.0, I think it should explicitly state that the RIRs will 
jointly run a single replicated database for this registry, and
the details of whether or not ARIN and RIPE end up running it
for the other 3 RIRs, would be left to global policy, or even just
unstated. There should be no need of an RIR RFC, since the details
can be worked out now and incorporated into the final ULA-C RFC.

--Michael Dillon