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