Date: Tue, 13 Aug 2002 08:38:15 -0700
From: "Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| - 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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
