Subject: draft-ietf-ipv6-ula-central-02

From: <[email-masked]>
Date: Mon, 18 Jun 2007 22:40:23 +0100

In this draft it has some requirements for generating ULA-C prefixes and
then in 7.0 it requires the RIRs to publish an RFC documenting how they
will implement these requirements.

I think it would be better not to require the RIRs to also go through
the RFC process after a ULA-C RFC has been issued, if it ever gets to
that point. One possible solution is to downgrade this to simply require
the RIRs to publish an RIR document explaining how they implement
section 3.2.

But a better way is for the ULA-C document to include this. I note that
any algorithm for checking (and registering) a generated prefix in the 5
RIR databases could easily be done in advance so that each RIR keeps a
supply of unique ULA-C prefixes on hand based on their forecast rate of
requests for such addresses. That means that an applicant does not have
to wait for turnaround time of the uniqueness test. As far as protocols
for communication between the RIRs, this should also be specified in the
ULA-C document, however it should not develop any new protocols, merely
specify that something like XML-RPC or REST be used, and the semantics
of the transaction which should be atomic, i.e. test uniqueness and
register in one transaction. This transaction should provide some kind
of positive response so that there is no possibility of a false
positive. And since it will likely be most heavily used to register
batches of unique ULA-C prefixes, it should allow for a single
transaction to register the entire batch (or at least as many are
actually unique). Race conditions can occur here but it is not necessary
for a protocol or application to resolve these since this can be done by
some manual exception process. As long as conflicting prefixes (ones
which have not passed all 5 RIR checks) are removed from all the
databases regularly, that is sufficient.

-------------------------------------------------------
Michael Dillon
Capacity Management, 66 Prescot St., London, E1 8HG, UK
Mobile: +44 7900 823 672 
Internet: [email-masked]
Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
http://www.btradianz.com
 
One Community One Connection One Focus 

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Jun 2007 11:14:26 -0400

> will implement these requirements.

I don't think the RIRs necessarily need to publish an RFC. The main
point is for the RIRs to have sufficiently documented what they
propose to do so that everyone is happy with proposal and it's written
down somewhere. The details of exactly what documentation is
sufficient can be discussed and shouldn't become a rathole relative to
the bigger question of whether ULA-C shold go forward at all.

> But a better way is for the ULA-C document to include this.

Well, one thing to balance here is the part the IETF specifies and the
part the RIRs specify (in terms of operational policy). Putting it all
in one document complicates that and might result in the some of the
text appearing to come from the IETF (and the IETF then being
authoritative) rather than the RIRs. I don't think we want that either.

> I note that any algorithm for checking (and registering) a generated
> prefix in the 5 RIR databases could easily be done in advance so
> that each RIR keeps a supply of unique ULA-C prefixes on hand based
> on their forecast rate of requests for such addresses.

There are lots of ways of achieving uniqueness. One thing the authors
discussed quite a bit (with rough consensus at best!) was to what
degree the operational details of how to carry out the proposal should
be specified in this ID. Personally, I'd rather see less detail in the
IETF document, with it concentrating on the desired/required
properties of ULA-Cs. Presumably, if we define the properties
clearly/properly, how they are produced operationally would be a
detail and not really our concern, i.e., so long as the desired
properties are preserved.

Thomas