Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses"

From: Geoff Huston <[email-masked]>
Date: Mon, 10 Nov 2003 21:36:29 +1100

At 12:51 PM 9/11/2003 +0000, Tim Chown wrote:
>On Sun, Nov 09, 2003 at 08:49:40PM +0900, Jun-ichiro itojun Hagino wrote:
> >
> >       - it is not expected to be routable, however, it will be treated
> >         as if it is a global address.  therefore it is likely to be 
> leak out.
> >         1.0 asserts that "even if it leaks out there's no conflict", but
> >         "no conflict" is not enough - we do need to be 100% sure there's no
> >         leak out, otherwise it is unacceptable.
>
>I don't think we'd ever get 100% confidence of zero leakage, but that 
>shouldn't
>deter us from having a site-local addressing scheme that at least cures the
>other major problem of ambiguity in the addresses.  I think the Hinden draft
>can only fix the ambiguity problem.   But if people use Hinden-draft the
>leakage is more readily traced.

As I've pointed out a number of times the Hinden draft does not remove 
ambiguity
completely, given its specification of a local use algorithm. It is not 
completely
clear to me that the algorithm presented in the draft is a robust way to assess
the probability of collision - the analysis I undertook and documented
indicated that any 'perfectly' random selection algorithm, where one global
id was as likely as any other to be generated each time the algorithm
was run, would have a probability greater than 0.5 that at least 2
outcomes were identical once 1.24 million selection outcomes were
drawn from such a 'perfectly' random algorithm.

'no conflict' as an absolute assertion, as distinct form a prediction based
on probabilities and the degree of randomness of a random draw
algorithm that may or may not be used by end sites for global id selection
("after all its local use - so maybe I'll just save a bit of time and use 
an id
of '1' in my local config" :-( ) is not what the local use part of this 
draft is
actually providing here.

If you wanted to have an absolute assurance that no collisions occur in
this space then it is necessary to drop the local draw section of the proposal
and manage the entire space using the central registry draw mechanism.

So I think the "cures the other major problem of ambiguity" is not an entirely
technically accurate statement - "mitigates" or even "provides some increased
level of assurance" is a more precise phrase here.

And maybe that's adequate, or maybe not.

After thinking about this and looking at the evident need to make some progress
here I'd like to believe that this level of resolution of potential ambiguity
is adequate, given that there is always the option to use a central 
registry draw to
obtain a global id that is assuredly unique.

My other issues with the current rev of the draft are still on the table, 
and of course
I'd be happy to work with the authors to come up with some revised words 
that may find
some reasonable (rough) wg consensus, and still remain within the overall 
spirit
and intent of this proposal.

Geoff

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Mon, 10 Nov 2003 10:43:02 -0800

Geoff,

>and intent of this proposal.

Thanks.  That would be very helpful.  I will contact you off list and see 
if we can get together to come with some wording that could be presented to 
the w.g. during the Thursday session.

Bob

---

From: Alain Durand <[email-masked]>
Date: Mon, 10 Nov 2003 11:36:10 -0800

I think that if you were to drop entirely the randomly self generated 
addresses
and do not say anything about the fee scruture except it has to
be low cost, it would be a much more swallable pill.

    - Alain.

Bob Hinden wrote:

>> My other issues with the current rev of the draft are still on the 
>> table, and of course
>> I'd be happy to work with the authors to come up with some revised 
>> words that may find
>> some reasonable (rough) wg consensus, and still remain within the 
>> overall spirit
> Thanks.  That would be very helpful.  I will contact you off list and 
> see if we can get together to come with some wording that could be 
> presented to the w.g. during the Thursday session.
>
> Bob
>
>

---

From: Fred Templin <[email-masked]>
Date: Mon, 10 Nov 2003 11:52:04 -0800 (PST)

How about this - what if we let individual users randomly self
generate an address which they then take to the registration
authority. If no one else has previously registered the address,
the registration authority grants the assignment and records
it in the registration database. If the address was already taken,
the user repeats the random self generation process and asks
again to have the registration recorded. The process should
converge after relatively few iterations given a reasonable
random self-generation scheme - especially if the pool of
addresses is large.

Any thoughts on this idea?
 
Fred
[email-masked]

Alain Durand <[email-masked]> wrote:
I think that if you were to drop entirely the randomly self generated 
addresses
and do not say anything about the fee scruture except it has to
be low cost, it would be a much more swallable pill.

- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Nov 2003 21:15:11 +0100

Fred and Alain,

I am simply not as scared of unregistered prefixes as Alain, because
I believe there will always be rogue prefixes. At least you can
tell these are rogues simply by looking at the prefix, unlike the case
of rogues that are stolen PA prefixes. So I don't accept the thesis
that they need registering. Also, registration is not free of cost,
so it won't be free of charge, so I don't see the advantage
of post facto registration.

Anyway, let's see what Bob and Geoff propose.

   Brian

---

From: Hans Kruse <[email-masked]>
Date: Mon, 10 Nov 2003 16:09:07 -0500

I would oppose dropping the self-generated portion.  I think we have been 
pretty clear about the fact that anyone expecting to use locals for long 
periods of time with some chance of merging later should get the registered 
kind.  There is real value in the self-generated version, and I simply 
can't see the dire consequences predicted here...

--On Monday, November 10, 2003 11:36 -0800 Alain Durand 
<[email-masked]> wrote:

> addresses and do not say anything about the fee scruture except it has to

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Tim Chown <[email-masked]>
Date: Fri, 14 Nov 2003 16:01:59 +0000

> obtain a global id that is assuredly unique.

I think we will see a lot of people using fd00::/48 or fd00::/64 for
their sites/links purely becuase it's less effort to type. 

Ideally if deployments were as plug and play as they might be, then this
would not be as likely.   

We thus need simple methods by which networks can be deployed and easily 
use a pseudo-random local prefix generated under fd00::/8.   I could
foresee a "generate pseudo-random prefix" button on my home DSL router's
web config screen, but the more important case is more likely the larger
hierarchically routed enterprise?   Presumably an admin would use parallel
subnet numbering for their globally unique 2001:xxxx:xxxx::/48 prefix and
fd00::/48 prefix, if they chose to have site-local addressing for stable
internal communications.

Tim

---

From: Alain Durand <[email-masked]>
Date: Fri, 14 Nov 2003 10:06:42 -0800

>their sites/links purely becuase it's less effort to type. 
If this is the case, what will we have gained from fec0::/48?
One year of extremely heated discussion, appeal, gazillions
of email, just to replace the prefix fec0 by fd00 ?

    - Alain.

---

From: Fred Templin <[email-masked]>
Date: Fri, 14 Nov 2003 11:01:28 -0800

> of email, just to replace the prefix fec0 by fd00 ?

I believe we have gained community realization of what is needed.
Whether this took one e-mail or one gazillion will be seen as a minor
detail many years down the road from now.

Fred
[email-masked]

---

From: Zefram <[email-masked]>
Date: Fri, 14 Nov 2003 19:43:23 +0000

>If this is the case, what will we have gained from fec0::/48?

The opportunity to avoid this numbering clash.  Idiots who use fd00::/48
will clash with each other, but the rest of us avoid clashes with each
other and with the idiots.

-zefram

---

From: Alain Durand <[email-masked]>
Date: Fri, 14 Nov 2003 11:56:22 -0800

>other and with the idiots.
If you look at RFC3513, site locals were defined as fec0::/10 (and not 
fec0::/48)
so you could have done exactly what you describe. There is nothing new.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2003 14:42:11 +0100

> so you could have done exactly what you describe. There is nothing new.

There is something new: we will have given people a way to get a unique
or effectively unique /48. I think Tim's implementation suggestion (the
"make me a prefix" button) is a good idea, but of course it's outside
IETF scope.

   Brian