[AfriNIC-rpd] New policy proposal: IPv6 ULA-central

[Geoff Huston]

Haitham,


>To make it short:
>
>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".
>
>}
>
>I'm not with you in *multiple organizations* means individual RIRs; 
>How to divide the block FC00::/7 on five RIRs??  According to the 
>stated format in the RFC4193 ? the first 7 bits are fixed and the 
>eighth bit either '1' or '0' and the next 40 bits are 'global ID' 
>which has it's mechanism to be calculated using [NTP] which is 
>depend on time, system-specific identifier, then SHA1 algorithm...
>I think IANA meant by multiple organizations : representative of 
>multiple organization in the Single allocation organization, or get 
>approval for allocation from multiple organizations (prefer to be 
>RIRs of course). I don't know exactly but that what I think...


One thought that we had when we were reviewing this draft in detail a 
couple of years ago is that one single body would generate a number 
of blocks of unique random numbers and pass the blocks to each 
distribution authority. Its much the same as happens today, but with 
the change that the number blocks are no longer sequentially numbered.


>
>Geoff Hi,


Hi!

>{the 'nature' of the distribution function for this part of the
>        IPv6 address appears to be an allocation to be undertaken in
>        perpetuity....}
>Agree with you; and suggest that the Single Allocation Organization 
>(SAO) could apply the same rules of RIR for global IPv6 addresses 
>when it comes to apply ULA.

That is certainly an option, but then there are a number of 
considerations about the nature of the service and the similarities 
and differences between 'conventional' unicast address allocations 
and these C-ULA allocations that would need careful consideration 
here. There are _almost_ the same functions (uniqueness, maintenance 
of public record and the same, routeability in a 'global' context 
differs, but then again the RIRs never make any assertions about the 
routeability or otherwise of any allocated prefix in any case)



>
>{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.....}
>
>Agree with you ... and suggest that SAO could apply same policies of 
>RIRs for global IPv6 addresses, and it's prefer to make all publish 
>all addresses allocated as it's not routable so not reachable.

With the caveat that the RIR's have no real ability to declare any 
prefix 'routeable' or not, and routeability itself is not a single 
assertion - there are many forms of routing contexts.

>
>
>{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?
>}
>supporting you ... It should be declared in the draft, Also ASO 
>could apply same policies of RIRs for de-allocate. and again asking 
>to make it all public..

As you point out, it starts to look more and more like a 
'conventional' allocation as a result.

>
>{ 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-paid prefixes into manufactured devices?
>       If not, could this form of use of the central registry services be
>       supported using mechanisms described in the current proposal?
>}
>
>I suggest to allocate different block by IANA dedicated for 
>manufactured devices.
>

The entire issue of 'blocks' (which I take to mean sequentially 
numbered blocks) or random pools (which I take to mean a set of 
randomly generated but unique numbers) was what I was attempting to 
get at with this comment.

>{Associated information and pointers. The proposal 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.
>}
>
>I think so :)

Interestingly enough this was one of the topics which took some time 
in the IETF mailing list when this draft was being considered. As the 
prefix is globally unique then there is no particular barrier to 
admission in the reverse DNS logically. There are some considerations 
about the ultimate size of the zone file.


>
>{ ...Pricing for the
>       service may need to be determined within the parameters ...
>}
>
>Agree.


The is some consideration about the true distinction between C-ULA 
address blocks and conventional unicast address blocks. If the 
address allocations in the C-ULA block are published by the RIRs in 
precisely the same manner as other unicast address allocations, are 
able to be entered into the reverse DNS in the same manner as other 
unicast address allocations, and if the RIRs are not the determiners 
of whether an address block is actually routeable or not, then what 
precisely is the distinction between this C-ULA address distribution 
function and the conventional unicast address distribution function? 
Why are C-ULA address necessary? What problem is this proposal 
actually attempting to solve here? And if the problem can be 
identified clearly then the subsequent question is whether there are 
alternative mechanisms that could solve the same problem in different ways?

i.e. What is the problem that C-ULA addresses are intended to solve 
and what alternatives are available to us in looking at this problem? 
So far I have yet to see the proposer of this policy address this 
quite basic question. I suspect that the proposal would be a fair 
deal clearer in intent, and a fair deal clearer in terms of whether 
or not the proposal should be adopted, if we all clearly understood 
what the underlying problem (or what shortfall in the existing 
address distribution mechanisms) is that this proposal is intending to address.


regards,

    Geoff Huston
     APNIC