Date: Mon, 23 Sep 2002 14:09:40 -0400
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Let me quote another part of the addressing architecture:
| That is, a host is not required to know what part of an address is an
| interface identifier and what is not.
That's fine. Now we have two things in the doc, and hosts can do one
or the other. The "must be two interoperable implementations of every
feature" requirement in 2026 says that if everyone happens to choose one
of those, then the other has to be deleted from the spec before it goes
to DS. The other choice can reappear in a new PS spec, but it cannot
remain in the DS spec.
Thomas, there's nothing at all unclear about this in 2026...
| Thus, there is no requirement in
| addr-arch that implementations somehow test for the two components and
| verify that they satisfy particular properties.
No, and I am not complaining about any implementation that doesn't do
that. In fact, I would complain (to the authors of such a thing) if they
did attempt to do that - I certainly wouldn't use such an implementation.
But that's not what is important here. What matters is whether or not
there are two implementations (at least) of every feature of the spec.
Not whether any (or every) particular implementation conforms to the spec.
| Indeed, for a node
| that only understands addresses, you seem to be suggesting that such
| an implementation would also have to reject a request to set a
| specific address on an interface, and instead require that addresses
| be entered as a (prefix, IID) pair, so that properties of (say) the
| IID could be verified/enforced.
No, I would hate such a thing. What I am saying, is that according to
the address architecture doc, that is what is required, if hosts are to
implement that feature (whether or not they are required to implement
it is irrelevant here - 2026 applies to optional features just as much
as to mandatory ones).
If no-one is bothering to implement it, then it should be removed, correct?
If anyone is bothering to implement it, then that should be documented,
right?
| You seem to be saying that implementations must follow a extermely
| strict interpretation of a spec. Allow only that that is explcitely
| permitted by the text, and reject everything else, including a
| superset of the required feature.
No, nothing like that at all.
But consider a spec which says
Saucepans MUST NOT boil potatoes.
If some saucepan comes along and says, "I boil potatoes, I'm not violating
the spec, I'm just implementing a superset, because no-one is actually
required to boil potatoes using this implement", you'd laugh at them.
A superset cannot be such as to deliberately violate a condition of the
spec, it has to implement everything required, and then can implement more.
The requirement here is "m+n==64" - always (with only non-unicast, non-global,
and the 000 case as exceptions). That is, a host must implement that,
if it is to implement that particular feature. If you like, what the spec
is saying, is
Addresses MUST NOT have a IID that is any length other than 64.
And you seem to be saying, OK, as long as it is possible to have an IID
that is 64 bits long, that requirement is satisfied. Really?
Please don't mane me give a lesson in boolean algebra and De Morgan's
laws relating to the inverses of "All X" and such.
If you don't believe that is what the spec is saying, then at the very
least it is unclear, as that's certainly how I read it. It is also
an interpretation I have seen quoted by (several) other people in various
other contexts. So, if it is (commonly) being read as saying something
different than what it is actually supposed to mean, surely it should be
corrected so it is clear. By all means propose wording to make this
happen. If your wording for this is in accord with what you seem to be
saying here, and the WG accepts it, then I doubt I will have any problems.
That is, if your replacement wording makes it clear that it is OK for
implementations to allow IIDs that are shorter (or in fact, longer) than
64 bits if they desire, and that m+n is not actually required to be 64
after all.
| I.e., it's not enough to enter/check
| an the address, one must know what its internal components are
| (prefix, IID) and test both of those.
If the host is implementing that feature, then yes. But note that we're
not discussing the adequacy of host implementations here, we're discussing
the correct procedures for advancing the spec. That means that it is
irrelevant whether or not the feature in question is supposedly mandatory to
implement or not, all that matters is that it is in the doc, and there aren't
any documented implementations of it. Hence, it has to go (or documentation
of implementations must be provided).
| This goes too far, IMO. You are saying that implementations can't
| implement a superset of some feature in order for that feature to have
| been supported properly.
Once again, this is not a superset, it is a direct violation of the
wording. And once again, I am not complaining about any implementation.
The complaint is about the spec, and its ability to go unchanged to DS.
| The purpose of 2026 interoperability testing
| is to ensure that the words in the spec are sufficient to implement
| from and not result in any interoperabilty features.
Once again, that is only a part of it. It is also to get rid of
features that no-one is bothering to implement. That's why it says
that every feature must be documented. It isn't good enough to simply
say "these two implementations interoperate with each other".
| If someone implements a superset of feature X,
Supersets are irrelevant here. No-one has implemented a superset of
the feature in question. Remember, that what I'm asking to be
deleted, or for which interop reports need to be generated, is the
"all IIDs are required to be 64 bits long" language. The text in
the spec (that is of concern) is not "all implementations are required
to support 64 bit IIDs" - if it were, then yes, supporting 64 would
be enough, and if 70, 80, ... bit IIDs supported, that would be a
superset. But that's not what it says, it says, very clearly, and
in two different ways in two different sections, "*ALL* IIDs are
*required* to be 64 bits" (referring to global unicast addresses
that don't start with the first three bits being 000).
I am still waiting for you (or someone) to point to a single implementation
of this feature. Once we get one, we could start looking for two...
| And in the case of IIDs, it's clear from the
| implementation report that a number of implementations have
| implemented them.
Of course. No-one is suggesting that IIDs be deleted from the spec.
Nor EUI-64 for that matter.
All I am asking is for the language that mandates that IIDs be 64 bits
long, and that no other length is permitted, be removed (or the
implementations of it be documented). Are you somehow managing to miss
that particular text in the draft?
| Because there is no way to take an arbitrary address, and determine
| whether the IID is 64 bits or not, this is not something
| implementations can realistically check.
If this were true, and there was no way for an implementation to tell
whether a prefix is 64 bits long or not, then what would be the point of
including language in the architecture doc to mandate it. That would
make the requirement mere fluff.
But of course, that is utter nonsense. For any local address, the
implementation must know which part identifies the net (link) and which
part identifies nodes on the net (link). Otherwise it has no way to
tell which other nodes are "on link" and which are not. And even if
this is necessary only for a subset of links, it clearly is possible.
Of course, in practice, nodes are always told what the prefix length
is, for any address configured (not that they would need to be if the
addr arch spec was followed literally, as it would always be a constant 64).
| > inet6 3ffe:b80:53:1234:2222::1 prefixlen 112
| Correction: the address has been configured with a netmask of 112
| bits.
Which parts of "prefixlen" do you not understand? IPv6 doesn't
have netmasks...
| How the netmask is configured is independent of what IID is
| used.
Now this is an interesting argument, and truly clutching at straws
I believe.
Consider the wording from section 2.1 (Addressing Model) of the
draft ...
Currently IPv6 continues the IPv4 model that a subnet prefix is
associated with one link. Multiple subnet prefixes may be assigned
to the same link.
Also see section 2.5.1, where Interface Identifiers are defined...
Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link.
So, we have the subnet prefix, which identifies the link, and the IID
that identifies the nodes on the link, and the prefixlen which tells
the implementation where the boundary between the two is. Then we
have language in the doc which says that the IID must be 64 bits, and
other language that says that the combined global routing prefix, and
subnet ID (which together make the subnet prefix) must be 64 bits long.
How can the prefix length (or subnet mask if you insist on calling it that)
be anything other than 64, and actually be complying with the requirement
in the spec that m+n==64, or the one about the IID being 64 bits wide?
But if that's your interpretation of what the spec is actually saying
is required, then we certainly need different text to explain it, as
no-one else I know of has ever claimed that as a legitimate interpretation
before.
Rather, the addr arch doc is commonly quoted by people who claim (and
correctly as it is written, I believe - which is why it needs to be
changed) that it specifies that the prefixlen of any link is required
to be 64, and nothing else is permitted.
So, if that's not what it is actually saying, then the text clearly needs
corrections so it is understood the way you're claiming that it should be
understood.
| One can assign a 112 bit mask on an IID that is in EUI-64 format
| (which is what was done above).
Um, no, that's not what was done above. EUI-64 format also makes
statements about the 'u' bit, and if you look, you'll see that the
address that was configured has the 'u' bit set, but most certainly
wasn't formed from any kind of global identifier. And note this
was an ethernet (that's what fxp0 is on NetBSD) which means that its
tokens would be 48 bit MAC addresses, so a correctly formed (global) EUI-64
would have had the FFFE value in the middle of it. That's missing too.
| That, per se, is not an indication of a problem.
It looks like one of three cases is true here.
The spec really means something quite different from the way everyone
interprets it, in which case it should be corrected.
The spec doesn't really mean anything at all, in which case it should
be deleted.
The spec means exactly what it says, in which case either 2 implementations
of it need to be documented, or the spec has to be deleted (from this doc
for it to go to DS status).
You can pick one of those, but I can't see any other choices. In each of
the above "the spec" means the particular lines from the draft in question
that I quoted in my last message.
| > What's more, it works ...
| Right. The WG wants it to work this way...
In that case, why is the addr arch doc not actually saying what the
WG wants?
On the other hand, if what you are saying here is that the WG wants
to have this in the spec, and to have the spec advanced to DS, even
though there aren't 2 implementations of this feature, then I'm afraid
it is the IESG's job to say "no". 2026 leaves it no choice. It isn't
as if the IESG is usually shy about rejecting drafts that WG's have
agreed to, or ignoring specific "wants" from working groups. And that's
when there isn't even a specific requirement that requires the IESG
reject the request, which there is here.
| The requirement is that folks implement EUI-64s IIDs.
That is *a* requirement. That's not the one I am concerned about.
Hasn't that much become clear yet?
There is also this other requirement that every (global unicast, 000
case excepted) address have m+n == 64. In that m is the number of
bits in the global routing prefix, and n is the number of bits in the
subnet ID. Is it possible that you can't see that in the draft?
The language isn't obtuse - it isn't required that anyone read this
requirement out of a combination of other statements, or anything
complex like that, after all, what it says is ...
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.
Notice that "All [...] addresses". It leaves no room for there to be
a single address (other than the explicit exceptions) which isn't formatted
like this.
Look at the diagram above it (this is section 2.5.4). That shows what
m and n mean. Look at the definition of Interface ID, to see what that
means. And you can just believe me that in the implementation I showed
(the one you claimed earlier didn't exist, though I think it is what
everyone does), when an address has a prefixlen of 112, it means that
m+n == 112. The implementation doesn't actually care how much of that
is m, and how much is n, that is someone else's business - nor does the
addr arch doc care, all it currently requires is that m+n==64: m=63 n=1,
or m=64 n=0, or m=3 n=61 would all satisfy it, but m+n==112 does not.
That one is the one in question.
And once more, I am not complaining about this implementation, I like it
a lot, it does exactly what I think it should do. But it isn't one of
the ones which could possibly be used to claim that the feature in
question is implemented (and nor are any others I have seen - but of
course, that isn't all that exist, so it is possible that there are the
needed 2 implementations somewhere, just not documented).
| It is not that
| implementations check for and reject any address or IID that isn't
| guaranteed to follow the format.
If nothing is supposed to check/reject addresses of IIDs that aren't
64 bits long, why is the text in the doc? If it is just that
implementations are allowed to reject that, then that's an optional
feature right? And 2026 requires that there be at least two
implementations of each optional feature, or the feature must be
removed.
| > 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.
|
| Understood.
It doesn't seem to be, because you keep referring to implementations
implementing IIDs, which has nothing to do with this at all. The "nothing
else" above was meant to refer to "nothing other than 64 bits", not that
I am objecting to no other parts of the spec (because there's also the 'u'
bit of course, that is pending the outcome of this discussion).
| But I disagree with the requirements you believe that
| implementations need to satisfy in order for addr-arch to go to Draft
| Standard.
2026 really is quite clear.
| That bar is too high, as it basically requires that
| implementations check for lots and lots of things that are not
| explicitely allowed prevent them from being used.
No, that would not be the case at all, we're not talking about undocumented
cases here, or things just left open and undefined, or unspecified.
Let's look at another couple of cases for a minute, which aren't in this
area of dispute, so might make things just a bit clearer.
2.5.3 The Loopback Address
[...]
The loopback address must not be used as the source address in IPv6
packets that are sent outside of a single node.
Now, if an implementation was sending packets with 0::1 as the source
address, it clearly wouldn't be complying with the spec, right? That
wouldn't just be a "superset" implementation, would it? So, for link
locals to pass into the DS draft, we need at least two implementations
that don't send ::1 as a source address. I doubt that is any kind of
problem. Note, it is not important if there are buggy implementations as
well, which do use ::1 as a source addr, unless they're caused by a lack of
clarity in the spec (which would not be likely here), but there must be
at least two implementations which do implement the spec. Agreed?
On the other hand:
2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
[...]
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+
Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
must be a globally-unique IPv4 unicast address.
[...]
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+
In that section, nothing at all is said about (IPv6) addresses which
start with or 0::FFFF:0:0/96 but which don't contain an IPv4 address
in the low 32 bits. Nor is anything said about addresses that start
with 0::/80 but which don't have 0000 or FFFF in the next 16 bits.
Implementations which supported any of that would be supersets of the
spec. Clearly there is no requirement in the spec for such things to
be rejected.
But when an IPv4 address is used in a 0::/96 address, then it is
required to be a globally unique one. If no-one implements that,
then that requirement would have to be deleted (but I believe that
actually is tested for in at least some implementations).
So, here, as long as there are two implementations of this, with or
without optional extensions, this part is also just fine to advance to DS.
This needs to be done for every feature in every spec that the IESG
considers advancing to DS. Note I'm not about to require that the
IESG do all this all by itself, we have the rest of the IETF community
along to help. First, the WG is supposed to document it all in the
implementation report. And then, we have the rest of the community
(like me in this case) who should be examining all of this, and making
known any problems that we can see.
But once the IESG are made aware of a feature in a spec, for which there
aren't two documented implementations, it has no choice, according to
2026, other than to request the missing documentation, or reject the
doc's advancement to DS, or to require that the unimplemented features
be removed from the doc, after which what is left can advance to DS.
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]
--------------------------------------------------------------------
