Search RPD Archives
[AfriNIC-rpd] FW: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central)
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Thu May 3 08:03:23 UTC 2007
I sent this email yesterday night to RIPE policy WG mail exploder. The same
questions were previously raised by Geoff in this mailing list, so answer
applies to both the same :-)
Regards,
Jordi
------ Mensaje reenviado
De: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
Responder a: <jordi.palet at consulintel.es>
Fecha: Thu, 03 May 2007 01:30:53 +0100
Para: "address-policy-wg at ripe.net" <address-policy-wg at ripe.net>
Conversación: [address-policy-wg] 2007-05 New Policy Proposal (IPv6
ULA-Central)
Asunto: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6
ULA-Central)
Hi Geoff,
I guess it is important to clarify that the authors of the draft are working
on a new version. I've not yet seen it, so I'm not sure if it is addressing
already any of your points below.
Trying to answer your points below, but as a general comment, I think they
are operational aspects that the community should rely on the RIRs staff to
manage. At least, I personally trust them. There have been many similar
examples discussed in other regions of operational issues and once the RIRs
are asked about if they want to have a policy, the message is clearly
negative: They need freedom to implement things.
In this case it is more evident. The implementation can be different if it
is taken by one or several RIRs, or by the NRO itself, etc. I'm happy if the
result of the implementation is that somebody can get allocated a
ULA-central prefix (I don't really care the price, because I understand need
to be based on a cost recovery model and to be decided by the board), to be
used as for the example in the proposal for infrastructure microallocations,
instead of wasting global address space.
I also guess that this can be done with a much simple document not detailing
so much as the actual ID. This is why I think this "parallel" (RIRs+IETF)
process is important, because it may actually help to provide inputs for
subsequent versions of the ID.
See below, in-line.
Regards,
Jordi
> De: Geoff Huston <gih at apnic.net>
> Responder a: <address-policy-wg-admin at ripe.net>
> Fecha: Thu, 03 May 2007 08:20:21 +1000
> Para: Shane Kerr <shane at time-travellers.org>, "address-policy-wg at ripe.net"
> <address-policy-wg at ripe.net>
> Asunto: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central)
>
> At 01:03 AM 3/05/2007, Shane Kerr wrote:
>> All,
>>
>> I think the draft this proposal refers to:
>>
>> http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01
>>
>> Is an early version of what eventually became RFC 4193:
>>
>> http://tools.ietf.org/html/rfc4193
>>
>> The RFC does not have any centrally assigned addresses.
>>
>> I didn't actually follow the discussion in the IETF about this
>> document, so I don't know why the centrally assigned version was
>> removed.
>
>
> The IETF history of this document was that an original proposal was for
> two pools of ULA addresses - one a "self-draw" and one "centrally assigned".
> The draft was split into two drafts, and the draft describing the "self-draw"
> pool
> was published as RFC4193 while the IPv6 working group abandoned work on
> the centrally assigned address pool
>
>
>
>> It's not actually clear to me what the policy proposal is. Does it
>> intend for the RIPE NCC to act as a central registry for all local
>> IPv6 addresses? Does it intend for a special membership category be
>> set up for this?
>
> I posted the following comments and question to the Afrinic policy mailing
> list in response to this proposal - I suspect that these questions and
> comments are relevant here as well.
>
> 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.
I guess this document was feed into the IPv6 WG. It will be interesting to
know the answers provided by the IETF process then.
>
> The evaluation report included the following considerations:
>
> -----------------------------------------------------------------
>
> - the 'nature' of the distribution function for this part of the
> IPv6 address appears to be an allocation to be undertaken in
> perpetuity. It is possible to interpret this allocation in terms
> comparable to some form of 'freehold property' given that the
> self-allocation via the central registry gives the entity
> exclusive unqualified right of access without any form of
> expiration or renewal of the original allocation.
>
> Current RIR allocations of unicast public address space are
> undertaken under conditions that are broadly consistent with a non-
> assignable lease.
I think we do that with other special addresses, such as multicast, etc.,
via direct allocation from IANA. What is the difference ?
>
> It may be that this issue of assignments performed in perpetuity
> vs fixed period renewable assignments should be a matter of choice
> by the client as the time of assignment, and that pricing for this
> address assignment reflect the different cost structure of secure
> maintenance of assignment records for a fixed period vs costs for
> this record maintenance to be undertaken in perpetuity.
I don't think the policy proposal precludes doing so. We may need to decide
if this should be so clearly defined by the policy or trust the board. I
will think the last one, as they policies don't define fees.
>
> - 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. It is the case that such RIR-held information is
> discoverable by others using legal means under certain
> circumstances. Open questions include:
>
> Would anyone be able to ask whether a specific prefix was
> allocated or not?
I don't think we can define an absolute "privacy". Lawful interception is
always something under the relevant authority control, so definitively they
should be able to ask if prefix "x" belongs to somebody and in that case,
whom.
>
> Would a holder be able to 'recover' their prefix from the
> registry?
I don't see why it can't be feasible. I will say that those are good ideas
for the staff implementing it.
>
> Could a holder request the registry to expose their holding to a
> specific third party?
Same answer as the previous one.
>
> Could the privacy requirement be changed at a later date?
By whom ? Any specific example of why you think this may be required ?
>
> Would any future changes to the privacy requirement (or any
> other characteristics of these addresses) be a policy matter to
> be determined within the addressing community, or would any
> changes to the characteristics of this space remain solely
> within the purview of the IETF?
I think we should follow the draft, or provide inputs to update it, and this
may be one of the issues, but probably an example of why you think this is
important could help.
>
> - Permanence of allocation. Should there be a capability for an
> assignee to voluntarily return an allocation? How can the assignee
I think this could be a nice to have feature, of course.
> and the returnee be matched? If the allocation is not public
> knowledge how can a return be effected? Should these allocations be
Implementing privacy doesn't necessary means that the RIR don't know who
owns a prefix, in fact this is required in order to execute the contract as
stated in the policy proposal.
> permanent or of some fixed term with a periodic renewal option?
I will not really care if the board decides to implement a periodic renewal
fee.
>
> - 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 don't see right now if this could be useful, but if you have a specific
example, I guess it could be considered then in the implementation.
>
> - 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. Or should such reverse DNS delegation be allowed?
> After all these global IDs are unique and in and of itself putting
> them in the public DNS is not going to harm the DNS. Of course the
> random nature of these assignments has the potential to, over time,
> create an extremely large flat DNS zone. This may have implications in
> terms of signing the zone with DNSSEC of course. Some guidance the
> preferred approach of populating the DNS reverse zones would be
> preferred, if reverse DNS is to be supported for these addresses. If
> this reverse DNS is to be allowed, does this compromise the private
> nature of the assignment? The proposal is also silent on WHOIS
> entries.
>
> It appears that there is an explicit privacy issue where that
> precludes any inclusion in the WHOIS databases, but an explicit
> statement to this effect in a final version of this document would be
> preferred. It is probable that inclusion in the public DNS, whois
> information and the privacy of these assignments are related matters.
I think the usage I'm perceiving for ULA-central could be made with
two-faced DNS, but I may be wrong.
>
> - Routability of these prefixes. The RIRs maintain that they take no
> position on the routeability of prefixes that they assign. It would
> appear that this position extends to this central registry managed
> site local prefix.
Yes, but that's doesn't preclude to have routability statements across many
policies. In this proposal we only state what is not the intend of this
prefix, and this could be tied in the future to resource certification in
the same way as the rest of the prefixes.
>
> - There is no doubt that there would be some effort expended on the part
> of the RIRs to implement this registry operation. Pricing for the
> service may need to be determined within the parameters of a cost
> recovery function for operation of the function distinct from the
> costs of other RIR functions, and within the parameters of the
> anticipated costs of secure maintenance of records in perpetuity.
Agree, as stated above, I don't really care about the price for the
registration and trust the staff to evaluate the cost and the board to
implement the relevant contracts and fees, as we do with the rest of the
policies.
>
>
> 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?
Why using global unicast for something which already has an allocated prefix
since it was designed for that by IETF ?
For sure there are alternative mechanisms, as usually there are many
solutions for doing everything :-), and that may require an alternative ID
if we can't achieve consensus on this one.
>
> 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.
>
I tried to make it clear in the proposal text. I think it can be summarized
as:
The issue is avoid wastefully using global unicast resources for
infrastructure microallocations if it can be done with a prefix from another
block which is already reserved for this type of functionalities.
>
>
>
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.
------ Fin del mensaje reenviado
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
More information about the RPD
mailing list