Jordi, my point is that technically, this is trivial, if
the community concludes it's a good idea. There is running
code. So no need for an administrative solution since a robot
can do it cheaper and better. But it isn't the IETF that
should decide who the operational community will trust
to run the robot.
The only real question is whether the 40 pseudo-random bits
are a feature or a bug. If they're a bug, stick to PI.
Brian
On 2007-06-15 17:24, JORDI PALET MARTINEZ wrote:
They need a trusted entity running the tool to void any clash chance, that's
one good reason for making it different than ULA.
Regards,
Jordi
De: Brian E Carpenter <[EMAIL PROTECTED]>
Responder a: <[EMAIL PROTECTED]>
Fecha: Thu, 14 Jun 2007 11:42:20 +0200
Para: <[EMAIL PROTECTED]>
CC: <ipv6@ietf.org>
Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: [***SPAM*** Score/Req: 10.4/4.5]
Re: Revising Centrally Assigned ULA draft
On 2007-06-14 11:30, 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.
Since there is no practical difference between ULA and ULA-C, they
need to explain...
The argument about private addresses at the end of
http://www.arin.net/policy/proposals/2006_2.html
makes no sense. ULA and ULA-C are both private addresses.
Brian
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
--------------------------------------------------------------------
--------------------------------------------------------------------
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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
