<HTML dir=ltr><HEAD><TITLE>Re: [AfriNIC-rpd] New policy proposal: IPv6 ULA-central</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16414" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText7973 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000>Hi All,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>Jordi, I've read RFC4193 , <draft-ietf-ipv6-unique-local-addr-08.txt> , and <draft-ietf-ipv6-ula-central-01.txt> and find that the main two differences between the drafts for unique *local* and *central* IPv6 unicast addresses are (correct me if i'm wrong): </FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>1- for *Central* allocation will be public through Single allocation organization so that no probabilities of conflict ip's & for unique *Local* it'll privacy through the same Single allocation organization.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>2- The eighth bit for *Central* is '0' and for *Local* is '1'.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>So, for point #1; Both local and central addresses are not routable .. i.e. no fear from security problems .. I mean why to make Local addresses unpublished !!? it's better to make it public to avoid the very very low probability of conflict when organization want to merge for example.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>for point #2 you said in reply for Alain that :</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>{</FONT></DIV>
<DIV dir=ltr><FONT face=Arial><FONT size=2></FONT></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial><EM><FONT color=#0000ff><FONT size=2>To make it short:<BR><BR>1) The draft introduces the concept and one way to manage this, however, in<BR>section 7.0, IANA considerations, is already indicated "... If deemed<BR>appropriate, the authority may also consist of multiple organizations<BR>performing the allocation authority duties".</FONT><BR></FONT><BR></EM>}</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>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... </FONT></DIV>
<DIV dir=ltr><FONT face=Arial>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...</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>Geoff Hi, </FONT></DIV>
<DIV dir=ltr><FONT size=2>{<EM><FONT color=#0000ff>the 'nature' of the distribution function for this part of the<BR> IPv6 address appears to be an allocation to be undertaken in<BR> perpetuity....</FONT></EM>}<BR></FONT><FONT face=Arial size=3>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr>{<FONT size=2><FONT color=#0000ff><EM>it is unclear whether the privacy of the assignee is intended to<BR> absolute or under what circumstances the central registry operator<BR> would divulge this information and to whom. It was noted that all<BR> information held by the RIR is not covered by any binding<BR> privilege....</EM></FONT>.</FONT>}</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT face=Arial>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>{<FONT face="Times New Roman" color=#0000ff size=2><EM>Permanence of allocation. Should there be a capability for an<BR> assignee to voluntarily return an allocation? How can the assignee<BR> and the returnee be matched? If the allocation is not public<BR> knowledge how can a return be effected? Should these allocations be<BR> permanent or of some fixed term with a periodic renewal option?</EM></FONT><BR>}</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>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..</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>{ </FONT><FONT face=Arial><FONT color=#0000ff><FONT size=2>Distribution functions. Should there be some form of 'wholesale'<BR> form of bulk access to this registry, to allow, for example, a<BR> manufacturer to place pre-paid prefixes into manufactured devices?<BR> If not, could this form of use of the central registry services be<BR> supported using mechanisms described in the current proposal?</FONT><BR></FONT>}</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>I suggest to allocate different block by IANA dedicated for manufactured devices.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>{</FONT><FONT face="Times New Roman" color=#0000ff size=2>Associated information and pointers. The proposal is silent on reverse<BR> DNS for these prefixes. Perhaps the final version of this document<BR> could explicitly say that this requires private DNS (two- faced DNS)<BR> deployment and that placing these prefixes in the ip6.arpa zone is not<BR> to be supported.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>}</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT face=Arial>I think so :)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>{ <FONT color=#0000ff size=2>...</FONT></FONT><FONT face="Times New Roman" color=#0000ff size=2>Pricing for the<BR> service may need to be determined within the parameters ...</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>}</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>Agree.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>Thanks,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>Haitham..</FONT></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV></DIV>
<DIV dir=ltr>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> rpd-bounces@afrinic.net on behalf of Geoff Huston<BR><B>Sent:</B> Sun 4/1/2007 11:55 PM<BR><B>To:</B> jordi.palet@consulintel.es; AfriNIC Resource Policy Discussion List<BR><B>Subject:</B> Re: [AfriNIC-rpd] New policy proposal: IPv6 ULA-central<BR></FONT><BR></DIV></DIV>
<DIV>
<P><FONT size=2>At 05:39 AM 2/04/2007, JORDI PALET MARTINEZ wrote:<BR>>Hi all,<BR>><BR>>This is a new policy proposal, just to make sure to avoid any confusion: It<BR>>is NOT related with the IPv6 PI.<BR>><BR>>As discussed with the NRO, I'm submitting this proposal to all the RIRs.<BR>><BR>>Please, read the text and make sure to ask any questions that you may have.<BR><BR><BR>When this was under consideration within the IETF some years back I performed<BR>an evaluation of the draft from the perspective of the RIRs as a<BR>potential operator<BR>of this service. In reading through this proposal these considerations appear<BR>to remain relevant today, and it may be useful to consider these issues when<BR>considering the operational aspects of provision of such a registry service.<BR><BR>The evaluation report included the following considerations:<BR><BR>-----------------------------------------------------------------<BR><BR> - the 'nature' of the distribution function for this part of the<BR> IPv6 address appears to be an allocation to be undertaken in<BR> perpetuity. It is possible to interpret this allocation in terms<BR> comparable to some form of 'freehold property' given that the<BR> self-allocation via the central registry gives the entity<BR> exclusive unqualified right of access without any form of<BR> expiration or renewal of the original allocation.<BR><BR> Current RIR allocations of unicast public address space are<BR> undertaken under conditions that are broadly consistent with a non-<BR> assignable lease.<BR><BR> It may be that this issue of assignments performed in perpetuity<BR> vs fixed period renewable assignments should be a matter of choice<BR> by the client as the time of assignment, and that pricing for this<BR> address assignment reflect the different cost structure of secure<BR> maintenance of assignment records for a fixed period vs costs for<BR> this record maintenance to be undertaken in perpetuity.<BR><BR> - it is unclear whether the privacy of the assignee is intended to<BR> absolute or under what circumstances the central registry operator<BR> would divulge this information and to whom. It was noted that all<BR> information held by the RIR is not covered by any binding<BR> privilege. It is the case that such RIR-held information is<BR> discoverable by others using legal means under certain<BR> circumstances. Open questions include:<BR><BR> Would anyone be able to ask whether a specific prefix was<BR> allocated or not?<BR><BR> Would a holder be able to 'recover' their prefix from the<BR> registry?<BR><BR> Could a holder request the registry to expose their holding to a<BR> specific third party?<BR><BR> Could the privacy requirement be changed at a later date?<BR><BR> Would any future changes to the privacy requirement (or any<BR> other characteristics of these addresses) be a policy matter to<BR> be determined within the addressing community, or would any<BR> changes to the characteristics of this space remain solely<BR> within the purview of the IETF?<BR><BR> - Permanence of allocation. Should there be a capability for an<BR> assignee to voluntarily return an allocation? How can the assignee<BR> and the returnee be matched? If the allocation is not public<BR> knowledge how can a return be effected? Should these allocations be<BR> permanent or of some fixed term with a periodic renewal option?<BR><BR> - Distribution functions. Should there be some form of 'wholesale'<BR> form of bulk access to this registry, to allow, for example, a<BR> manufacturer to place pre-paid prefixes into manufactured devices?<BR> If not, could this form of use of the central registry services be<BR> supported using mechanisms described in the current proposal?<BR><BR> - Associated information and pointers. The proposal is silent on reverse<BR> DNS for these prefixes. Perhaps the final version of this document<BR> could explicitly say that this requires private DNS (two- faced DNS)<BR> deployment and that placing these prefixes in the ip6.arpa zone is not<BR> to be supported. Or should such reverse DNS delegation be allowed?<BR> After all these global IDs are unique and in and of itself putting<BR> them in the public DNS is not going to harm the DNS. Of course the<BR> random nature of these assignments has the potential to, over time,<BR> create an extremely large flat DNS zone. This may have implications in<BR> terms of signing the zone with DNSSEC of course. Some guidance the<BR> preferred approach of populating the DNS reverse zones would be<BR> preferred, if reverse DNS is to be supported for these addresses. If<BR> this reverse DNS is to be allowed, does this compromise the private<BR> nature of the assignment? The proposal is also silent on WHOIS entries.<BR> It appears that there is an explicit privacy issue where that<BR> precludes any inclusion in the WHOIS databases, but an explicit<BR> statement to this effect in a final version of this document would be<BR> preferred. It is probable that inclusion in the public DNS, whois<BR> information and the privacy of these assignments are related matters.<BR><BR> - Routability of these prefixes. The RIRs maintain that they take no<BR> position on the routeability of prefixes that they assign. It would<BR> appear that this position extends to this central registry managed<BR> site local prefix.<BR><BR> - There is no doubt that there would be some effort expended on the part<BR> of the RIRs to implement this registry operation. Pricing for the<BR> service may need to be determined within the parameters of a cost<BR> recovery function for operation of the function distinct from the<BR> costs of other RIR functions, and within the parameters of the<BR> anticipated costs of secure maintenance of records in perpetuity.<BR><BR>-----------------------------------------------------------------<BR><BR>regards,<BR><BR> Geoff Huston<BR> APNIC<BR><BR>_______________________________________________<BR>rpd mailing list<BR>rpd@afrinic.net<BR><A href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</A><BR></FONT></P></DIV></BODY></HTML>