Date: Wed, 02 Oct 2002 10:33:56 -0400
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I believe we are just going to disagree on the issue you have.
That may be, but I would hope that there is at least one member of
the IESG who understands that 2026 is not just there to be disregarded
when it is inconvenient.
| You seem to be saying that the addr arch document (in order to go to
| Draft) requires that there exist at least 2 implementations that
| enforce the requirement that IIDs are exactly 64 bits.
Either that, or the text that is in doc that requires that needs to be
removed. Yes, that's what 2026 requires.
| That is, they
| MUST NOT allow IIDs of length other than 64 to be used/configured.
Yes. The text quite clearly states that IIDs are required to be 64 bits.
Why exactly is it that you can't find the two implementations of this
that would make my argument here irrelevant? I suspect that you have
tried. That would be a simple answer. It doesn't matter much what
the answer is, whether the requirement is unimplementable (which I doubt,
a "if (prefixlen != 64) return (EINVAL);" would be pretty easy to add...)
or whether it is just that in practice, everyone believes that this is
a nonsense requirement, but in any case, it is not being implemented, and
hence cannot be in a DS.
| The actual requirement that IIDs be 64 bits is not an implementation
| requirement (in the addressing architecture document).
Hmm - that's another interesting argument. But go read it again.
The doc doesn't say that other specs must not define IIDs to be any
other length (to which I would object, I think, or not because of the
requirement itself but because I don't believe that docs should
ever specify what other docs are allowed to define - it is a dumb
thing to attempt in any case). What it says, quite clearly, is that
the IID must always be exactly 64 bits. No restrictions upon in what
contexts (just the couple of well known assumptions).
If the doc wanted to set out reasons why people should only ever use
64 bit IIDs, without actually making that a requirement, that would be
fine, but that is not what it is doing. It doesn't even attempt to
justify the requirement, there's no rationale at all, it is simply
stated.
| The last part of Section 2.5.1 says:
|
| The details of forming interface identifiers are defined in the
| appropriate "IPv6 over <link>" specification such as "IPv6 over
| Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
Yes, but that's how the IID is to be created, not now big it is to be.
And in any case, that sentence is fine.
| I also remain unconvinced that the wording:
|
| 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.
|
| translates into a requirement that there exist implementations that
| disallow IIDs of length other than 64.
I can't see how you can avoid "are required to be 64 bits long".
| Following this logic, I suspect
| one could effectively prevent just about any document from being
| advanced to Draft.
Only ones that shouldn't be advanced. And note, all that is required to
allow it to advance, is for the unimplemented feature to be removed.
| Documents typically have a number of principles
| that are not testable or enforceable,
The ones in question here are both testable and enforceable. So,
that isn't relevant. But if the WG wanted to rewrite this one as
a general guideline or something, it would probably cause less problems.
That is get rid of the "are required to be" language etc.
| or where no one would bother to actually enforce something
| because the actual cost is too high.
This is exactly (one of) the case(s) where 2026 should apply. If a
doc is requiring something that cannot be implemented (reasonably) then
the requirement should be removed.
If that isn't done, then someone who later takes the doc, knows it is
a DS (or more), and hence knows that it has been fully implemented, gets
the thing, and then says "OK, all of this is proved implementable, I
have to implement it all", not knowing that everyone who went before
knows this is a joke, and that no-one actually bothered implementing
some particular part, because it is too hard, or just plain wrong, or
just unwanted (not useful) in practice.
This is exactly why 2026 requires at least 2 implementations of *everything*.
| Consider:
|
| > 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.
|
| What implementations prevent a non-globally unique IPv4 address from
| being used here? By your logic, this requirement would need to be
| stricken from the document.
Yes. I had noticed that one. And yes, it should go as well. This
one happens not to concern me greatly, so it isn't one I had commented on
yet.
Note in this case, a correct (and entirely adequate) solution would be
just to reword the doc a little, to make it clear that using something
other than a globally unique IPv4 address will result in undefined behaviour.
That is, rather than forbidding it, just undefine it.
| Or:
|
| > All interfaces are required to have at least one link-local unicast
| > address (see section 2.8 for additional required addresses).
|
| By your logic, we have to show that there are implementations that
| actually enforce that.
Yes, absolutely. I had assumed that had been done. I know of
implementations that automatically assign a LL address whenever IPv6
is enabled on an interface, precisely because of that. There is no
way to get an IPv6 interface without a LL address on it. I'd assume
there are at least 2 such implementations, and that that was tested
in the interop report. I wasn't part of the testing, so I don't know
for sure. Certainly I'd hope that *all* implementations enforce this,
and that none permit an IPv6 interface to exist without a LL address.
That's one of the basic IPv6 requirements, I would have thought, but
for DS we only need two of them.
| I.e, it's not enough that implementations in
| practice assign a LL address to an interface, we need to show that
| there are implementations that prevent the possibility of the
| interface ever operating without a LL address. This is unreasonable.
No, it isn't, it is exactly what is required. What would be the use of
having the requirement there, if you couldn't count on it being implemented?
If this were merely more fluff in the spec, then yes, it too should be
removed. This one however, isn't.
| As a more general case, consider a protocol that specifies behavior
| X. For example, protocol X must rate limit messages of type Y. Well,
| anyone can come along and implement protocol X over raw sockets and
| have it flood the network with messages of type Y violating the
| required rate limitingf behavior. By your reasoning, an
| implementation of a protocol that doesn't also prevent another
| implementation running over raw sockets from violoating the spec would
| not be compliant. In general, no implementation can ensure that the
| spec is not violated when viewed in this light.
Huh? What kind of logic is that? There have to be (for DS) at least
two implementations of the protocol which implement the feature. How
many others (for DS) exist that don't, is irrelevant (it becomes relevant
when the spec is due for full std status). Here you seem to be confusing
the implementation, with the system that runs the implementation. That
a system can run both a conforming implementation, and a non-conforming
one is interesting, but not relevant, the conforming one counts as one of
the implementations that is required.
If the only implementation of the protocol on the system in question was
the one on raw sockets, with no rate limiting, then that couldn't count
as one of the required two implementations, obviously. If there weren't
two other implementations that actually implemented the rate limiting, then
that would have to be removed.
Note that 2026 does not require that no implementations get it wrong.
For DS it just requires that (at least) 2 (independent) implementations
get it right.
| Popping up a level, the arguments being used are fairly legalistic (on
| both mine and your side).
They revolve around what 2026 requires. Yes. If that's "legalistic"
then so be it.
But there are very good reasons for 2026 requiring what it requires.
If you want to change that, then go create yet another son of poisson
WG, and we can look at a revision of it. (It would be kind of neat
to have a poisson2 group (in the tradition of poised95...) created
this year...)
| Based on some of your earlier mail messages to the WG, it would seem
| that your real goal here is to do away with the requirement that all
| IIDs be 64 bits long and in particular you would like to remove the
| 'u' bit from the IID.
Yes. I do want to do away with both of those. Partly because
they're both such nonsense requirements that no-one is implementing
them, and people are configuring interfaces using IIDs that aren't
64 bits long (remember the thread, on some other list, ngtrans, or
v6ops, or something I suspect) about why operators do this?
| But this was discussed explicitly within the WG and there appeared
| to be little support for your position.
Actually no. If you go back and look at the record, I think you'll see
that there was much more support for a change than for no change. Just
re-read the messages and see. The best the chairs could come up with
was "no consensus to change the doc". Nb: not "consensus against
changing the doc." As I recall it, just about the only real opposition
(actually stated on the list) to changing this came from you...
(I don't know, obviously, but it is possible that the chairs then
believed that they couldn't change the doc, because attempting to specify
something that an IESG member doesn't like, or not to specify something
that they do like, can cause a doc to get held at "discuss" in the IESG
forever...)
Even one of the WG chairs, in the message that started this discussion
(in its most recent go around anyway) said, on the list, on Aug 4 ...
Unfortunately, operators seem to be ignoring this restriction in
numbering point-to-point links between routers. I have spoken to
a few IPv6 operators, and it is common practice to use /125, /126
or even /127 prefixes for these links.
What does this mean for us? Well, in my opinion, we don't want
to standardize a restriction that we _know_ will be ignored by
the folks who are deploying the software.
Exactly correct. But even more than that, 2026 does not allow us to
advance documents that specify things that no-one uses.
But apart from that, once again, what the WG wants in this area is
irrelevant. 2026 places some mandatory requirements on docs advancing
through the process. If they're not met, then it wouldn't matter if the
doc had 100% overwhelming consensus of the whole IETF, it still could
not advance (except that most likely, no-one would point out the defect
and it could just be silently ignored).
| It is time to advance addr arch to Draft Standard and move on.
If the IESG can convince itself that this doc has actually met the
requirements for DS, as enumerated in 2026, then it can go ahead and
vote for that I guess.
I kind of hope that it is fairly obvious to just about anyone however
that the requirements in this case are not met. I suspect that it is
even obvious to you, you're just trying to find some kind of argument to
allow them to be side-stepped here.
Incidentally, I sent the first message on this thread to the IESG (only).
Since then, it has been between us, with cc's going to both the IESG
and the WG. But it has never been made clear whether in this small
exchange you've been speaking on behalf of the IESG, or just making
your own personal arguments. Which?
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]
--------------------------------------------------------------------
