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
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
