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

[AfriNIC-rpd] Summary of Discussion on Policy for IPv6 ULA-Central

Hisham R Rojoa hisham at
Mon Apr 16 05:02:11 UTC 2007

Dear all

As AfriNIC-6 meeting in Abuja is very close, we are sending a summary of
the IPv6 ULA-Central Policy from Jordi Palet Martinez (1 April 2007)

Below is a summary of discussions with regards to this policy

Geoff Huston (2 April 2007)
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.

Alain Aina (3 April 2007)
Is NRO going to be the allocation authority ?
The draft does not say anything about that "allocation authority"
The RFC mentioned has expired

Jordi (3 April 2007) in response to above 
The proposal suggest that this (AfriNIC) RIR do it for this region, and
the same for each one of the other RIRs.
I guess it may happen that the NRO could decide, if the proposal goes
thru all the regions to implement a central registry instead of 5
"distributed" central registries for this purpose, but I guess this is
out of the scope of the proposal, and could be a "next step". I'm not
sure if this could work, but I can imagine that if we reach consensus in
every region, it may made sense to have a single registry, if it reduces
the cost, and this being funded by the NRO common funds.
I believe there has not been a similar case before.

Anyway, as said, the proposal here is to talk about the *AfriNIC* scope,
at least at this stage.

The draft is expired, but as you know can be revived at any time, just
with a new submission. The goal is to do so, in parallel with the
advancement of the PDP in the different regions. The important think
here is also to realize that the space is already allocated to IANA by

Alain Aina (3 April 2007) in response to above
The draft proposes a unique central authority, which differs from your
RFC4193 only defines L=1
IETF does not define yet L=0, and i guess we need L=0 defines before we
move forward. 

Jordi (3 April 2007) in response to above 
1) The draft introduces the concept and one way to manage this, however,
in section 7.0, IANA considerations, is already indicated "... If deemed
appropriate, the authority may also consist of multiple organizations
performing the allocation authority duties".

2) Even if only L=1 is defined, the entire block is on IANA hands, as it
is a /7, not /8.

3) The definition of L=0 is done by this document. We just need to move
it forward again, which as said before, can be done in parallel with the
PDP in the RIRs. I don't think there is any rule that says "must be done
in serial mode" and if this helps to win time, why not ?

Alan Barrett (4 April 2007)
The whole point of centrally-assigned unique local addresses is to get
addresses that are guaranteed to be globally unique (as opposed to
locally-assigned unique local addresses, which are generated in a way
that is likely to be unique, but not guaranteed to be unique). The
expired draft draft-ietf-ipv6-ula-central-01.txt (available from
<>) talks about
an escrow function to ensure uniqueness.

It seems to me that a "central" ULA registry operated by AfriNIC
(presumably in parallel with other similar registries operated by other
RIRs) would not satisfy the requirement for guaranteed global
uniqueness.  There would be a possibility of collisions in the
assignments made by different registries, unless there was a way of
performing some kind of cross-registry uniqueness check.  I think that a
realistic proposal to establish a central ULA registry should address
the mechanism for performing the uniqueness checks.  The proposal on the
table does not do so.
I'd also like to see some consideration of mechanisms to prevent
hoarding of addresses.

Jordi (4 April 2007)in response to above
I understand your point, but in my opinion, policies should not enter
into details of how they become actually implemented from an operational

This is also what I've heard several times from the staff en many RIRs.

For example, it may be the case that the RIRs (those where the policy
get approved by the membership) may decide (via the NRO or other means),
to implement a single central register, instead of different registries.

One more possibility could be to breakdown the ULA-central prefix in
several smaller chunks to be allocated by IANA to each RIR.
Again, operational details should be left on the hands of the RIRs
(otherwise, we should do the same in all the policies, define all the
operation instead of trusting the RIR staff capabilities).

Alain Aina (4 April 2007)
the same IANA session  also says:

"The IANA is instructed to designate an allocation authority, based on
instructions from the IAB, for centrally assigned Unique Local IPv6
unicast addresses.  This allocation authority shall comply with the
requirements described in Section 3.2 of this document, including in
particular allocation on a permanent basis and with sufficient
provisions to avoid hoarding of numbers."

Yes "if deemed appropriate". And if "we" think RIRs can do this do, we
need to make sure it is done accordindly to established rules. others on
this list have made some good points on this isssue. and you need to get
the desired block(L=0) from IANA to the designated authority(ies). 

I am not confortable with AfriNIC adopting "the policy as proposed"
without clarifications the issues mentionned.

Alan Barrett (4 April 2007)
That goeas against the original idea that ULAs would not have any kind
of geographical or topological significance.

Jordi (4 April 2007)
If I'm not wrong, there are two possible scenarios if we adopt this

1) IETF moving this document to RFC, which is the original idea (and
this can include specific text about the RIRs if needed). This can be
considered equivalent, I think to the original IPv6 /23 allocations to
the RIRs ?

2) One more global policy for the ULA-central block, in order to get it
from IANA, similar way as the actual IPv6 /12 allocations to the RIRs.

In both cases it is clear the cooperation among the RIRs so I don't see
how it could happen that "they don't talk each other".

I believe the board could decide, in order to avoid any problem if the
proposal passes the PDP, to hold the proposal implementation until
either 1 or 2 are done. In fact is not possible otherwise.

Andrew Dul (4 April 2007)
I actually think we are approaching this issue from the wrong side.
This policy would be implemented based upon an expired Internet-Draft,
with no new draft currently being sponsored or even under discussion.
Before any RIR should consider this issue the issue needs to be
discussed again in the IETF.  I'd agree that the work can happen in
parallel but we at least need an active draft in the IETF, such as what
happened with the 4-byte ASN.  I would discourage any RIR from adopting
any policy based upon an expired draft.

As far as I know there hasn't really been a lot of discussion in the
IETF since the last draft expired.  (Although I might not be on the
right mailing list.)  I haven't seen any new text proposed to update the
last draft to deal with the issues that were raised by the RIR community
after the initial draft was published.  Thanks to Geoff Huston for
reposting a summary of the issues after the last round of discussion.

Alain Aina (4 April 2007)
I don't see how this policy will oblige IETF and/or IANA to  give this
job to RIRs. 

If we want the RIRs  to this job, then let talk about  the operational
issues regarding adding the ULA-central registry services to the current
ones. Geoff raised some interesting points, we can use as starter.

And if we don't have to, i will like to hear from the RIRs.

>From the above discussions on the mailing list, it seems that at the
moment there are more people against the current formulation of the
proposed policy than those for.

Best Regards

More information about the RPD mailing list