I see that the local use address draft has been revised and published as a WG
document.
In section 3.2.2 of the draft, it notes that, in reference to Locally
Assigned Global IDs that "the likelihood of conflict is small. "
I had noted in draft-huston-ipv6-local-use-comments-00.txt that the
likel
Hi Geoff,
Geoff Huston wrote:
I see that the local use address draft has been revised and published
as a WG
document.
In section 3.2.2 of the draft, it notes that, in reference to Locally
Assigned Global IDs that "the likelihood of conflict is small. "
I had noted in draft-huston-ipv6-local-u
But don't "conflicts" matter only for separate sites that later decide to
connect to each other using these addresses?
In that context 1 out of 1.24 million seems small. That does not mean we
should not include that math, just that the conclusion is valid, especially
for an address type that i
You are correct in that the "conflicts" matters at the point that the two sites
want to interact in such a fashion that the expose their local use addresses
to each other, now or at any time in the future.
Now if you have a random selection algorithm that truly has 2**40 bits
of entropy the chances
Thanks for your response Brian,
You note two objections to my comments regarding the random self-selection
method as described in the local use address draft.
Firstly: "That is, the P above needs to take into account the probability that
two networks trying to use the same prefix are connected."
I
On Thu, 28 Aug 2003, Geoff Huston wrote:
[...]
> The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd
> contend that this is definitely not "small" as described in the draft.
I consider this a bug. Actually, the number of draws should be smaller,
e.g. 1000, to avoid having l
Of course one could take this approach to its logical conclusion and
specify a single global ID to use in such a context. That will reduce
the minimum number of draws to generate a collision to 2. Is that what
you are after?
thanks,
Geoff
At 08:33 AM 29/08/2003 +0300, Pekka Savola wrote:
On
Geoff,
Now I understand your argument, I don't think it holds water.
The fact that there is a 50% chance of a conflict somewhere inside
a set of a million enterprises doesn't bother me in the least.
If an enterprise has direct interconnection to 2**8 other enterprises,
in a space of 2**40 random
Pekka:
I am distressed. Please see inline for specifics.
AEB
On Fri, 29 Aug 2003, Pekka Savola wrote:
> On Thu, 28 Aug 2003, Geoff Huston wrote:
> [...]
> > The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd
> > contend that this is definitely not "small" as described in
I am still not sure I agree with the conclusion. If I execute an address
draw, and then decide to connect to 5 other networks, what is the
probability of a conflict? It greater than 1/(2**40), but much, much
smaller than 0.5; the "0.5" problem arises only if someone wants to connect
1.24 mill
Geoff's initial comment included the classic birthday paradox formula,
which would indeed apply if we were to use the randomly generated
addresses as global site identifiers valid across the Internet. The
practical consequence is that we should be extremely clear about the
usage limitation: rando
"Alan E. Beard" <[EMAIL PROTECTED]> wrote:
[...]
|Additionally, such a suggestion, if implemented, would effectively
|prohibit one of the chief *legitimate* uses of GUPI address address
|allocations: routing between private networks on private (or VPN) links
|under bilateral agreements between the
Dan:
If it were up to me alone, I would do exactly what your suggestions below
imply, and proceed on the assumption that administrators of site boundary
routers (and, probably, administrators of rich-configuration interior
routers) are competent to perform the tasks entailed thereby. However,
ther
> However, we might be able to make the suggested restrictions a bit
less
> burdensome, provided that we can satisfy the never-route-private-addrs
> zealots that the revised scheme can still be effective in limiting
> unintended propagation of non-globally-routable prefixes. See below
for
> specif
"Alan E. Beard" <[EMAIL PROTECTED]> wrote:
|If it were up to me alone, I would do exactly what your suggestions below
|imply, and proceed on the assumption that administrators of site boundary
|routers (and, probably, administrators of rich-configuration interior
|routers) are competent to perform
Christian:
A couple of questions concerning the operational specifics of the black
hole implied by your statement below.
BTW, the policy statement is clear, concise, and utterly reasonable. This
is not in the least surprising when I consider who wrote it. :-)
On Fri, 29 Aug 2003, Christian Huit
> Additionally, let us postulate that all three entities have a small
> population of hosts which must be accessible from the public networks,
and
> that those hosts must also be reachable from the local private
network.
The plan of record is that these publicly reachable hosts will have both
a lo
"Alan E. Beard" <[EMAIL PROTECTED]> wrote:
|As I understand the above text, routers are intended to discard traffic
|(as distinguished from routing protocol prefix propagation) with
|destination addresses in the range of FC00::/7 unless there exists in the
|routing table a prefix of the form FC00:
On Fri, 29 Aug 2003, Dan Lanciani wrote:
> "Alan E. Beard" <[EMAIL PROTECTED]> wrote:
>
> |If it were up to me alone, I would do exactly what your suggestions below
> |imply, [...]
>
> That's all well and good, but there are lots of other ways that a router
> administrator can screw up. It isn't
Christian:
Thanks for the clarification. Please see inline for a few comments
On Fri, 29 Aug 2003, Christian Huitema wrote:
> > Additionally, let us postulate that all three entities have a small
> > population of hosts which must be accessible from the public networks,
> and
> > that those host
"Alan E. Beard" <[EMAIL PROTECTED]> wrote:
|> |in the case you propose above, even if the black hole is
|> |universally implemented, two 'permit' statements, each for a /8 block
|> |(assuming we use the Hinden proposed address space block) would solve this
|> |problem.
|>
|> This is inconsistent w
> The usage that is actually envisaged is more limited: an identifier that
> provides disambiguation in a limited environment, normally a single
> site, possibly a small number of sites directly linked by VPN-like
> relations. In that scenario, the collisions that matter are those that
> occur with
Dan Lanciani wrote:
> There is a huge difference between requiring a /48 and allowing anything
> greater than /8. The former ...
> while the latter means that you can bypass the black hole with 2 or 4
> route additions.
Of course you can bypass it. But remember that your bypass is only useful
i
Andrew White <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|> There is a huge difference between requiring a /48 and allowing anything
|> greater than /8. The former ...
|> while the latter means that you can bypass the black hole with 2 or 4
|> route additions.
|
|Of course you can bypass it
Dan Lanciani wrote:
>
> Andrew White <[EMAIL PROTECTED]> wrote:
>
> |Dan Lanciani wrote:
> |
> |> There is a huge difference between requiring a /48 and allowing anything
> |> greater than /8. The former ...
> |> while the latter means that you can bypass the black hole with 2 or 4
> |> route ad
Andrew White <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|>
|> Andrew White <[EMAIL PROTECTED]> wrote:
|>
|> |Dan Lanciani wrote:
|> |
|> |> There is a huge difference between requiring a /48 and allowing anything
|> |> greater than /8. The former ...
|> |> while the latter means that you c
> ``Router manufacturers MUST ensure that said black hole cannot be deconfigured,
> turned off, or otherwise overridden in toto;''
It's very simple. No sane router vendor would do this. There are lots
of real world cases where people need to route arbitrary address
blocks.
The MUST can only apply
below...
Chirayu Patel wrote:
>
> > The usage that is actually envisaged is more limited: an identifier that
> > provides disambiguation in a limited environment, normally a single
> > site, possibly a small number of sites directly linked by VPN-like
> > relations. In that scenario, the collisio
> >
> > Assuming that the pool size is "n", where n = 2^40.
> >
> > As per your formula the probability of choosing two unique numbers is (n-
> 1)/n,
> > and of three unique numbers is ((n-1)/n)*((n-1)/n).
> >
> > As per Geoff, the probability of choosing two unique numbers is (n-1)/n,
> and
> > o
Brian E Carpenter <[EMAIL PROTECTED]>
> ``Router manufacturers MUST ensure that said black hole cannot be deconfigured,
> turned off, or otherwise overridden in toto;''
|It's very simple. No sane router vendor would do this.
I pointed out in my original comments that most router vendors have lit
Chirayu Patel wrote:
>
> > >
> > > Assuming that the pool size is "n", where n = 2^40.
> > >
> > > As per your formula the probability of choosing two unique numbers is (n-
> > 1)/n,
> > > and of three unique numbers is ((n-1)/n)*((n-1)/n).
> > >
> > > As per Geoff, the probability of choosing two
Alan,
You raised very good points. Sorry for delay. I'll try to respond to a
few old threads I had to drop for a while due to other work..
On Fri, 29 Aug 2003, Alan E. Beard wrote:
> > On Thu, 28 Aug 2003, Geoff Huston wrote:
> > [...]
> > > The likelihood of conflict exceeds 0.5 after only 1.2
On Fri, 29 Aug 2003, Christian Huitema wrote:
> > Unless I have missed some essential clause in your description above,
> we
> > appear to have a failure mode, with a root cause of user neglect or
> user
> > error, in which the non-propagation requirement for unique-local
> prefixes
> > to the glob
Pekka,
There is no defence against misconfigured routers, except for well
configured routers elsewhere. I bet there are routers today capable
of announcing FEC0::/10 in BGP4+ if a user tells them to do so.
Whatever we define, misconfiguration (at the factory or by the user)
will occur. So I don't
On Mon, 8 Sep 2003, Brian E Carpenter wrote:
> There is no defence against misconfigured routers, except for well
> configured routers elsewhere.
Sure.. be sure to implement filtering at multiple levels, and by different
set of folks so the chance of mistakes is minimized.
For example, for some
The discussion about draft-ietf-ipv6-unique-local-addr-00.txt bothers
me.
First of all, what are we talking about here? I see two needs:
a) the need for stable addresses
b) the need for private addresses
Let's first discuss a). The draft says that unique local addresses
(ULAs) must not show up
>> Brian E Carpenter wrote:
>> There is no defence against misconfigured routers, except
>> for well configured routers elsewhere.
> Pekka Savola wrote:
> For example, for some services I maintain, I have:
> - TCP wrappers configuration in the host/service itself,
> using /etc/hosts.allow
> - T
> Pekka Savola wrote:
> For example, for some services I maintain, I have:
> - TCP wrappers configuration in the host/service itself,
> using /etc/hosts.allow
> - The local host firewall settings, doing similar
> restrictions as above
> - Missing default route on the host, only some selected
>
combining the two messages..
On Wed, 10 Sep 2003, Michel Py wrote:
> >> Brian E Carpenter wrote:
> >> There is no defence against misconfigured routers, except
> >> for well configured routers elsewhere.
>
> > Pekka Savola wrote:
> > For example, for some services I maintain, I have:
> > - TCP w
> Pekka Savola wrote:
> Incorrect. Have you even used hosts.allow? What makes you
> think it's easily hackable, instantly abusable by a vaguely
> clued low-level thief?
Gee, even I could use vi. As soon as you have root access, what is your
problem? I can vi the hosts.allow file, I don't know ho
On Thu, 11 Sep 2003, Michel Py wrote:
> > Pekka Savola wrote:
> > Incorrect. Have you even used hosts.allow? What makes you
> > think it's easily hackable, instantly abusable by a vaguely
> > clued low-level thief?
>
> Gee, even I could use vi. As soon as you have root access, what is your
> pro
> Pekka Savola wrote:
> Then you have to first compromise the system concerned, going
> through all the other protections.
> Before you hack the box to circumvent the hosts.allow you still have
> to ... well, hack the box! An interesting chicken and egg problem, no?
Never heard of a joe-job from t
On Thu, 11 Sep 2003, Michel Py wrote:
> > Pekka Savola wrote:
> > Then you have to first compromise the system concerned, going
> > through all the other protections.
> > Before you hack the box to circumvent the hosts.allow you still have
> > to ... well, hack the box! An interesting chicken and e
Comments below the two excerpts:
--On Monday, September 08, 2003 23:42 +0200 Iljitsch van Beijnum
<[EMAIL PROTECTED]> wrote:
Let's first discuss a). The draft says that unique local addresses (ULAs)
must not show up the global/public DNS so two-faced DNS must be used for
these addresses. But how
Iljitsch van Beijnum wrote:
>
> The discussion about draft-ietf-ipv6-unique-local-addr-00.txt bothers
> me.
>
> First of all, what are we talking about here? I see two needs:
>
> a) the need for stable addresses
> b) the need for private addresses
>
> Let's first discuss a). The draft says that
On woensdag, sep 10, 2003, at 14:29 Europe/Amsterdam, Brian E Carpenter
wrote:
Consider the
situation where two organizations with their own ULA space merge.
Hosts
continue to have ULAs as before, but now there is a second range of
ULA
space that is reachable. But how does the DNS for organizat
46 matches
Mail list logo
