[ppml] Revising Centrally Assigned ULA draft

[JORDI PALET MARTINEZ]

If you doubt about folks stating anything, then you should read *before*
minutes of meetings. I'm now off-line in a plane, so can't point you to a
specific URL, but this has been said at least in one ARIN meeting.

It has been clear across all this discussion in several exploders, that
there are both opinions, people that want ULA-C and people that don't. What
you need to be smart here is to realize that those than don't want ULA-C
have no any objective reason to oppose to it, because implementing ULA-C has
no negative impact in others. While opposing to it has negative impact to
all: Folks will use global space (PA or PI) for doing the function of ULA-C
an this is a waste, yes a small waste but a waste.

It seems to me irresponsible and unbalanced to do or try things like
changing the HD-ratio or the default assignment size to end-sites because it
is a waste, and then oppose to those that want to have ULA-C, not impacting
in others and avoiding one further small saving in global unicast space.

I'm not trying to convince anyone about supporting ULA-C, because it seems
an impossible mission at least for a few, but at least, don't object to it
if having it doesn't force you in any further implications, which is the
case.

Regards,
Jordi




> De: Jeroen Massar <jeroen at unfix.org>
> Organización: Unfix
> Responder a: <ipv6-bounces at ietf.org>
> Fecha: Thu, 14 Jun 2007 11:00:11 +0100
> Para: <jordi.palet at consulintel.es>
> CC: ARIN People Posting Mailing List <ppml at arin.net>, <ipv6 at ietf.org>,
> "address-policy-wg at ripe.net" <address-policy-wg at ripe.net>
> Asunto: Re: Revising Centrally Assigned ULA draft
> 
> [cc'ing RIPE address policy + ARIN PPML where the discussion on this
> happened, I have not seen any 'operators' who have said the below, if
> there are they are there and can thus raise their voices because they
> will see this message; removed the silly spam scoring subject...]
> 
> JORDI PALET MARTINEZ wrote:
>> Operators have said that they will not be able to use ULA, but they could
>> use ULA-C, for example for thinks like microallocations for internal
>> infrastructure's.
> 
> I really wonder where you got that idea, as I know of no such operator
> who would ever say that. If there are any, let them bring up their
> argumentation, please don't come up with "somebody said that" it does
> not work that way.
> 
> Real network operators, especially involved in the RIPE or other RIR's,
> have more than enough address space from their PA allocations that they
> can easily receive and they very well know how to use a /48 from that
> for internal infrastructure as everybody does this. The IPv6 PA policies
> even describe that a /48 can be used per POP of the owner of the PA block.
> 
> Also in the ARIN region any organization can get a /48 PI block for
> about $100/year, as such these organizations won't be needing this
> address space either as they can easily take a /64 out of that for those
> needs. Firewalling is the key here.
> 
> 
>> I think the policy proposal that I sent to several regions includes text and
>> links to other documents that can clarify this perspective.
>> 
>> For example in RIPE NCC:
>> http://www.ripe.net/ripe/policies/proposals/2007-05.html
> 
> That is your proposal indeed. No "Operator" has stood behind this and
> various people from various organizations have clearly asked you and the
> RIPE NCC to *freeze* this proposal till at least the IETF has worked out.
> 
> Anybody needing a "globally unique" block can get either PA or PI space.
> ULA-C as such is useless.
> 
> Greets,
>  Jeroen
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------




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