Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt

From: "Michel Py" <[email-masked]>
Date: Tue, 13 Aug 2002 08:38:15 -0700

kre,

| Tim Hartrick wrote:
| Aside: When the GSE discussion was going on N years ago, I was fore
| square against the /64 boundary for all the reasons that others
| have brought up in this latest thread.  That is, the dubious basis
| for assuming that a globally unique identifier is possible, the
| address space waste. etc.  I lost the argument.  I can live with it.
| It sure would be nice if decisions made in this WG had a half-life
| of longer than four years.

> kre wrote:
> I'd tend to agree with you - but we've just had Thomas claim that
> the reason all this remains is so GSE can be revived, sometime in
> the future...

I don't think that's what Thomas said. Since I probably am the one in
the best position to talk about this, the current status is:

- If GSE was the only way out for multihoming, I have no doubt that it
would be back on the scene, despite the documented shortcomings. GSE was
dismissed years ago when the collective dream that a much better
multihoming solution was still there. We have since then come closer to
reality.

- GSE will likely not be pursued (we have talked about the possibility
of reviving it three months ago and decided that we had a better mouse
trap).

- The perfect multihoming solution does not exist yet, and there is a
general feeling that GSE is possibly unfinished, problem is that nobody
has found the required breakthrough.

- There is currently no use made of the 'u' bit for any current or
future multihoming protocol I know of.

As we have seen here in the past and more recently with support for
Thomas' postings and other people contributing similar arguments, my
analysis of this issue is as follows:

- The 'u' bit is not a blocking reason why prefixes longer than /64 are
not allowed. Regardless of the existence of the 'u' bit, there are
reasons and support to keep the /64 boundary, which in turns means that
there is no consensus to remove it from [addrarch].

- In the context of the /64 boundary, the existence of the 'u' bit does
not bother anybody, I think.

- Given the likely strong support for a "son of GSE" should it be
written, it seems reasonable to leave this door open keep the 'u' bit
for the time being.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Wed, 14 Aug 2002 14:32:01 +0700

Date:        Tue, 13 Aug 2002 08:38:15 -0700
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | - There is currently no use made of the 'u' bit for any current or
  | future multihoming protocol I know of.

So you have no problem if the text that tells about its "global scope"
gets yanked from the doc?

  | - The 'u' bit is not a blocking reason why prefixes longer than /64 are
  | not allowed.

It is the only one I can see.   It is also the only one I care about.
That is, if you remove this 'u' stuff from the doc, the rest of the /64
becomes totally meaningless, because there's no longer any way for you
to tell from outside if I am using /64 or not.  Some remote node relying
on the 'u' bit set, and doing things to just the IID because of that, is
the only one that matters.

What are these other reasons for keeping /64 (mandatory for every link)?
The nonsense about /48 assignments certainly isn't it, nor is so autoconfig
will work - that only needs /64 on the links where autoconfig is used.

  | Regardless of the existence of the 'u' bit, there are
  | reasons and support to keep the /64 boundary, which in turns means that
  | there is no consensus to remove it from [addrarch].

Again, what reasons?

But I don't care too much, as if 'u' were to go, you can keep the pretense
about /64 in the doc, and lots of us will just go on ignoring it.  That
will do you no harm, will do us no harm, and everyone will be happy, right?

  | - In the context of the /64 boundary, the existence of the 'u' bit does
  | not bother anybody, I think.

It bothers me because it is an unnecessary wart on the spec.   It is
meaningless, useless (outside its use during autoconfig itself) and
a blight on the spec.  There's no point keeping it.   If the issue was
that we didn't want to revise the spec, having published it already,
and there not being other changes to make - then OK, just perhaps if
everyone understood that this was just a useless blemish, making a new
doc to fix it might not be justified.   But we're revising the doc, and
making more substantial changes anyway.   The trivial changes to address
this aren't (or shouldn't) cause problems.

  | - Given the likely strong support for a "son of GSE" should it be
  | written, it seems reasonable to leave this door open keep the 'u' bit
  | for the time being.

No, it doesn't, because no matter what kind of support and GSE
descendent might receive, the 'u' bit still remains useless.   If I
set (or don't) the bit, then I mighht be able to trust it, but no-one
else, anywhere, ever, can ever assign any meaning to it, because they
can't know that they're not dealing with a bastard like me who is
deliberately setting that bit to an arbitrary value.   It will always be
unsafe to attribute any meaning to the bit - unless you're sending
extra knowledge via some other channel than the address.  if you're
doing that, you'd do better to send "The IID in this address is globally
unique" than "You can trust the 'u' bit in this address to tell you
it is globally unique", the latter is just a meaningless extra indirection.

This bit simply can *never* be useful for the purposes people keep hoping
that they're going to use it.   It won't work.   Let's just get rid of it.

kre