First, thanks for clarifying the issue you have. I apparently didin't fully understand your concern the first time around.
Robert Elz <[EMAIL PROTECTED]> writes: > 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. I still do not believe either of your requests needs to be made. Let me quote another part of the addressing architecture: IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays (for instance, host versus router). At a minimum, a node may consider that unicast addresses (including its own) have no internal structure: | 128 bits | +-----------------------------------------------------------------+ | node address | +-----------------------------------------------------------------+ That is, a host is not required to know what part of an address is an interface identifier and what is not. Thus, there is no requirement in addr-arch that implementations somehow test for the two components and verify that they satisfy particular properties. 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. > 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). 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. 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. There is no such requirement in the spec that I can see. And no such requirement in 2026 either. > 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. 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. 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. If someone implements a superset of feature X, and that implementation interoperates just fine with other implementations of X, that is not inherently a problem. And in the case of IIDs, it's clear from the implementation report that a number of implementations have implemented them. > 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. 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 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. Disagree, per above. > 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. Correction: the address has been configured with a netmask of 112 bits. How the netmask is configured is independent of what IID is used. One can assign a 112 bit mask on an IID that is in EUI-64 format (which is what was done above). That, per se, is not an indication of a problem. > What's more, it works ... Right. The WG wants it to work this way... > 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). The requirement is that folks implement EUI-64s IIDs. It is not that implementations check for and reject any address or IID that isn't guaranteed to follow the format. > 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. But I disagree with the requirements you believe that implementations need to satisfy in order for addr-arch to go to Draft Standard. 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. Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
