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@unfix.org> Organización: Unfix Responder a: <ipv6-bounces@ietf.org> Fecha: Thu, 14 Jun 2007 11:00:11 +0100 Para: <jordi.palet@consulintel.es> CC: ARIN People Posting Mailing List <ppml@arin.net>, <ipv6@ietf.org>, "address-policy-wg@ripe.net" <address-policy-wg@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@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.