Date: Thu, 19 Sep 2002 13:49:55 -0700
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Note: I have updated the version of the draft in the subject line - the
-10 draft appeared just after I sent my previous message (which WG members
wouldn't have seen as it was sent only to the IESG)
| But if this is your argument, I disagree with it. It is not possible
| (nor does it make sense) that when a spec says X, the implementation
| report somehow needs to show that no implementations do *not* do
| X.
Of course. I am going to avoid doing a line by line reply to your message,
as you seem to be (for whatever reason) ignoring or misconstruing the
thrust of my request.
I'm going to assume that was because I wasn't clear enough. I thought
the issue was fairly obvious, and would be understood by anyone. But
it appears not, so this time I will be more blunt. That might make this
message seem patronising - that isn't the intent, I'm just not aware of
any other way to make the issues clear enough...
For now I will ignore the 'u' bit, we can come back to that later, if
necessary, and confine myself just to 64 bit IIDs for the rest of this
message (which will be long enough without more added on).
What draft-ietf-ipngwg-addr-arch-v3-10.txt requires, at the bottom of
page 8 (section 2.5.1) is ...
For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
Read that carefully (and I'll ignore the 000 case here, that's irrelevant).
Interface IDs are required to be 64 bits long
no exceptions (ignoring 000), no alternatives, interface identifiers
are required to be 64 bits long.
Then again, at the bottom of page 10, and onto the top of page 11, in
section 2.5.4, the same thing is restated ...
All global unicast addresses other than those that start with binary
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
described in section 2.5.1. Global unicast addresses that start with
binary 000 have no such constraint on the size or structure of the
interface ID field.
That comes after this ascii art showing a global unicast address...
The general format for IPv6 global unicast addresses is as follows:
| n bits | m bits | 128-n-m bits |
+------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+
(which itself is just fine).
Again, read what that says ...
All global unicast addresses [...] have a 64-bit interface ID
field (i.e., n + m = 64)
Again, no ambiguity, no alternatives.
What my message to the IESG requested, was that either that text be
deleted (there may be one or two other references as well - in a
message to the WG list a while ago I listed all the changes that should
be made, they're all simple deletes), or that the implementation reports
show at least 2 implementations of this requirement/feature.
Note: to implement this feature, the implementation would have to
prohibit any global unicast address (000 excepted...) from having
an interface id that was anything other than 64 bits long. Or, from
having m+n in the above diagram being any different from 64 (which, of
course, is the same thing).
There's no other way to implement this feature.
Note, this has nothing at all to do with whether an implementation
allows the IID to be 64 bits long - there is quite likely other wording
in the doc, that I have no problem with at all, that requires implementations
to allow IIDs to be 64 bits, so that autoconfig can work. That's all
just fine.
And so, I did mean "use" not "implement", as if I can use an address
that does not have a 64 bit IID (that is, if I can make m+n > 64) then
clearly the implementation is not implementing the above feature.
That is, the implementation is not requiring that m+n==64, or in other
words is not requiring that the IID be 64 bits long exactly.
All that is needed to show that the implementation does not implement
this particular feature, is to (attempt to) configure an address that
has something other than a 64 bit IID. If it works, then the implementation
doesn't implement the two paragraphs I quoted, and cannot count as one
of the two that do, which is required for this feature to remain in the
doc when it advances to DS.
As for ...
| What is your evidence that *implementors* are widely ignoring these
| requirements? I am aware of none.
jade# ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet 10baseT
status: active
[link locals and irrelevant cruft deleted]
inet6 3ffe:b80:53:1234:2222::1 prefixlen 112
There's one. There, right before your eyes, is a global IPv6
address. that starts with something other than 000, and in which m+n=112
(which is bigger than 64). That is, the IID in this global address
is 16 bits, not 64.
What's more, it works ...
delta$ ping6 -n 3ffe:b80:53:1234:2222::1
PING6(56=40+8+8 bytes) 3ffe:b80:53:181:206:5bff:feda:45ad --> 3ffe:b80:53:1234:2222::1
16 bytes from 3ffe:b80:53:1234:2222::1, icmp_seq=0 hlim=64 time=0.744 ms
16 bytes from 3ffe:b80:53:1234:2222::1, icmp_seq=1 hlim=64 time=0.272 ms
Go ahead, try it if you like (but no guaranntees that it will remain
configured for very long, as you can guess, this one I just installed
as I was typing this message, to demonstrate that it can be done).
Hence, this particular implementation has ignored the requirement that
all IIDs are "required to be 64 bits long" - hasn't it?
What's more, every implementation I have seen also ignores this requirement.
Can you point to even one, that doesn't?
But, it is not up to me to prove that the feature is widely ignored. What
2026 requires is (from rfc2026 section 4.1.2):
The Working Group chair is responsible for documenting the specific
implementations which qualify the specification for Draft or Internet
Standard status along with documentation about testing of the
interoperation of these implementations.
That is, the IESG cannot advance a specification to DS, unless the WG
chair (using the WG to assist, one would normally assume) has documented
at least 2 implementations of every feature (interoperable ones, but that
part isn't likely to be an issue here).
2026 is very clear about that. And while one of the reasons for this
is to make sure that the language in the doc is clear enough to implement
in an interoperable fashion, another reason is to make sure that "fluff"
doesn't remain in the specification, that no-one is actually bothering to
implement.
The two paragraphs I quoted above are quite clearly that kind of fluff.
And to be 100% clear, the feature / requirement that I am objecting to,
is the one that *requires* every IID to be 64 bits, and nothing else.
Not to the (related but different) one that requires implementations to
support 64 bit IIDs, which is just fine, and which the interop testing
does document (and I have no reason at all to doubt is widely implemented).
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]
--------------------------------------------------------------------
