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

Tue Apr 17 22:35:46 UTC 2007

Hi All,

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): 

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.

2- The eighth bit for *Central* is '0' and for *Local* is '1'.

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.

for point #2 you said in reply for Alain that :

{

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...

Geoff 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.

{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.

{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..

{ 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.

{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 :)

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

Agree.

Thanks,
Haitham..
________________________________

From: rpd-bounces at afrinic.net on behalf of Geoff Huston
Sent: Sun 4/1/2007 11:55 PM
To: jordi.palet at consulintel.es; AfriNIC Resource Policy Discussion List
Subject: Re: [AfriNIC-rpd] New policy proposal: IPv6 ULA-central

At 05:39 AM 2/04/2007, JORDI PALET MARTINEZ wrote:
>Hi all,
>
>This is a new policy proposal, just to make sure to avoid any confusion: It
>is NOT related with the IPv6 PI.
>
>As discussed with the NRO, I'm submitting this proposal to all the RIRs.
>
>Please, read the text and make sure to ask any questions that you may have.

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.

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.

       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.

     - 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?

         Would a holder be able to 'recover' their prefix from the
         registry?

         Could a holder request the registry to expose their holding to a
         specific third party?

         Could the privacy requirement be changed at a later date?

         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?

    - 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?

    - 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?

    - 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.

    - 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.

    - 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.

-----------------------------------------------------------------

regards,

   Geoff Huston
   APNIC

_______________________________________________
rpd mailing list
rpd at afrinic.net
https://lists.afrinic.net/mailman/listinfo.cgi/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20070418/f0dfba6d/attachment.html>