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 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 Regards, Jordi > De: Brian E Carpenter <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Thu, 14 Jun 2007 11:21:04 +0200 > Para: Roger Jorgensen <[EMAIL PROTECTED]> > CC: IETF IPv6 Mailing List <ipv6@ietf.org> > Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA > draft > > On 2007-06-12 22:19, Roger Jorgensen wrote: >> On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >> <snip> >>> >>> Is this a little like the RH0 thread? When it was a choice of disabling >>> by default or removing entirely? My vote is, don't forward ULA-Cs by >>> default, but let us use them as we used RFC 1918. It was also my vote >>> when we were discussing site-local. >> >> Why are we even talking about ULA-C now? What you want is nicely covered >> by ULA... not ULA-C but regular plain stright forward ULA. > > Exactly. If you want some private address space that no ISP will route, > but which you may care to use in your own network or with your > business partners via VPNs, get yourself a ULA, which is self-service. > And do what you need to do in your internal DNS; it will never appear > in the global DNS. (And don't rely on reverse DNS for your internal > operations, but that's a really silly thing to do anyway.) > > The *only* possible argument for centrally allocated ULAs is for those > who believe that the birthday paradox in a 2^40 address space causes > a real danger of colliding with another business partner's ULA prefix. > As I've said, we can easily have a robot to take care of that (in fact, > the prototype is up and running, thanks Jeroen). > > There seems to be a lot of confusion in part of this discussion. If > a ULA prefix does escape from its intended scope, it will be *exactly* > like any other non-aggregatable prefix that escapes. ULAs don't add to, or > remove from, the difficulties of dealing with non-aggregatable prefixes. > > As for what is a site for ULA purposes: it's whatever network(s) decide > to use and route a given ULA prefix. Its boundary is a set of routers > that don't route that prefix further outwards. > > Brian > > > -------------------------------------------------------------------- > 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
