[ipv6-wg] Re: [ppml] PI addressing in IPv6 advances in ARIN

JORDI PALET MARTINEZ wrote:
> Hi all,
>
> My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE
> and the rest of the regions, trying to get a consensus for a "global" policy
> on this, 
As as slight formality: I would strongly advice against using the term
Global Policy in any other meaning than the definition set forth in the
ASO MoU:

http://www.aso.icann.org/docs/aso-mou2004.html

Global policies are defined within the scope of this agreement as
Internet number resource policies that have the agreement of all RIRs
according to their policy development processes and ICANN, and require
specific actions or outcomes on the part of IANA or any other external
ICANN-related body in order to be implemented.

Global policies will be developed in the context of this agreement,
according to the processes defined by attachment A to this MoU.

Under this agreement the ICANN Board will ratify proposed global
policies in accordance with the Global Policy Development Process, using
review procedures as determined by ICANN. ICANN will publish these
procedures no later than ninety (90) days from the date of the signature
of this agreement by all parties.


Hans Petter Holen
Address Policy WG chair / ICANN Address Council Member.



> but as this thread is being followed up in several mail exploders,
> to avoid a long cross-posting, I think it will be better to start some
> discussion already in a mailing list which is global, and actually I think
> we have the right one ... global-v6 at lists.apnic.net
>
> So, if you aren't subscribed in the global-v6 at lists.apnic.net, and you're
> interested in this thread, please subscribe at
> http://mailman.apnic.net/mailman/listinfo/global-v6
>
> If you're late because the Eastern, the archives are also available at
> http://www.apnic.net/mailing-lists/global-v6/
>
> Regards,
> Jordi
>
>
>
>
>   
>> De: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
>> Responder a: <jordi.palet at consulintel.es>
>> Fecha: Fri, 14 Apr 2006 13:39:07 +0200
>> Para: "v6ops at ops.ietf.org" <v6ops at ops.ietf.org>, "ppml at arin.net"
>> <ppml at arin.net>, "shim6 at psg.com" <shim6 at psg.com>
>> Conversación: [ppml] PI addressing in IPv6 advances in ARIN
>> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
>>
>> Hi Owen,
>>
>> You said it: If somebody find the good solution, it will be attractive to
>> the people to go for it. Otherwise, you always have the chance to become an
>> LIR. My proposal actually is already considering this point and a way to
>> avoid a need for renumbering if that happens.
>>
>> I just want to make sure that we have a way-out if it becomes necessary, but
>> avoid a showstopper now. I think is it possible.
>>
>> I don't have a technical solution yet (and agree with your views on this in
>> the email below in general), but I'm confident we will have. If it will take
>> 4 years from now, or just 2, who knows, so my proposal is ensuring that we
>> have those 4 years+3 for allowing the people either to return the block, or
>> become an LIR and avoid renumbering an any changes in their network.
>>
>> By the way, it may happen, and I'm hoping so, that the technical solution
>> don't make necessary to return the PI block anymore, and in that case, we
>> will be even able to remove at that time the "temporarily" point in the
>> policy (if it becomes accepted).
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>     
>>> De: Owen DeLong <owen at delong.com>
>>> Responder a: <owen at delong.com>
>>> Fecha: Fri, 14 Apr 2006 03:48:34 -0700
>>> Para: <jordi.palet at consulintel.es>, "v6ops at ops.ietf.org"
>>> <v6ops at ops.ietf.org>,
>>> "ppml at arin.net" <ppml at arin.net>, "shim6 at psg.com" <shim6 at psg.com>
>>> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN
>>>
>>>
>>>
>>> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ
>>> <jordi.palet at consulintel.es> wrote:
>>>
>>> [snip]
>>>       
>>>> However, I want to balance this with the medium-long term implications
>>>> created in the routing table and with the time needed to build and deploy
>>>> a better technical solution (or several) which is accepted by the
>>>> community.
>>>>
>>>>         
>>> I think we first need to define what we consider a solution... See below.
>>>
>>>       
>>>> So my proposal basically is about having PI now everywhere (once ARIN
>>>> adopt it, is unfair not having it in other regions), but those PI
>>>> allocations for multihoming should be temporary and those address blocks
>>>> returned to the RIRs some time (lets say 3 years) after the new technical
>>>> solution is declared as a valid one.
>>>>
>>>>         
>>> I would not actually support this idea.  The whole point of having PI
>>> space is to have the addresses for a long-term.  Having a timeframe for
>>> return would simply restore the same barrier to entry that existed
>>> prior to passing the policy.
>>>
>>> Other RIRs are free to implement whatever v6 PI policy they feel is
>>> appropriate for their region.  I would support a globally standardized
>>> v6 PI policy along the lines of ARIN 2005-1.
>>>
>>> However, I would like to argue that if the new technical solution will
>>> benefit from the return of this address space, it is most likely not
>>> truly a solution, but, instead, another clever hack piled on top of
>>> the existing set of hacks.
>>>
>>> I suppose if someone found the magic bullet to make geotopological
>>> addressing really work, that might qualify.  However, I have very low
>>> expectations in that area.
>>>
>>> Absent that, any true solution will involve making the size of the routing
>>> table independent of the number of PI (or even PA) blocks issued by
>>> the RIRs or will make the size of the routing table practically
>>> irrelevant.
>>>
>>> I know this isn't the easy solution, but, we need to look long and
>>> hard at the way we do things.  I think that solving these problems
>>> is going to require a significant paradigm shift.  Assuming that we
>>> can use IP addresses for both end system identification and for
>>> routing topology indicators is how we created this problem.  I don't
>>> see solving it without breaking that assumption, at least at the
>>> interdomain level.
>>>
>>>
>>>       
>>>> At this way, on the long-run, we will not have routing table implications,
>>>> but we allow now the people that want to move ahead only if they have a
>>>> multihoming solution doing so.
>>>>
>>>>         
>>> If you think there is a possible solution (a real solution, not just
>>> a hack that postpones the inevitable at the expense of usability
>>> like CIDR did), then I'd like to hear what you are thinking.
>>>
>>>       
>>>> This 3-years time for getting a multihoming network back to the new
>>>> technical solution (once adopted) is enough time, I think (it could be
>>>> changed to 5 years if needed, or whatever), so nobody today see the
>>>> temporarily of the proposal as a showstopper to go for it now.
>>>>
>>>>         
>>> I think you underestimate the momentum and requirements of the modern
>>> enterprise if you believe that to be true.  Any capability available
>>> in v4 that is not available on at least equal or better terms in v6
>>> is a deterrent to v6 deployment.
>>>
>>> The ability to get permanent addresses which do not have to be returned
>>> when you switch providers or renumbered on a schedule determined by
>>> some external organization is a major example of such a capability.
>>>
>>> Owen
>>>
>>>
>>> -- 
>>> If it wasn't crypto-signed, it probably didn't come from me.
>>>       
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>>
>> 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
>>
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>>
>> 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
>
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
>
> 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.
>
>
>
>