This document really wants to be a BCP that makes deployment and strategy
recommendations. But for some reason it has been disguised as a standards
track document (i.e., as a protocol specification), and the result is that
RFC 2119 language is being used in a very peculiar way. I think this is
what is responsible for the impression that the document is "bizarre".
Some examples:
a best effort SHOULD be made to update existing hardware and software
to enable IPv6 support.
RFC 2119 language is used to distinguish optional from mandatory features in
an implementation. But "a best effort ... to update existing hardware and
software" does not seem to be a feature of an implementation. I just don't
understand what this statement requires, or how one would tell if a given
implementation is compliant with it or not.
Current IP implementations SHOULD support IPv6.
Presumably, "current" implementations support whatever they support, I don't
really understand what is being required here.
New IP implementations MUST support IPv6.
Is there some objective difference between a "new" implementation and a
"current" implementation? How many lines of code have to change before a
"current" implementation becomes a "new" one?
But I don't really see why "new" vs. "current" is even relevant. If there
were a lot of folks writing IP implementations from scratch, using only the
RFCs for guidance, it would be really important to make sure they know about
IPv6. Does anyone think that that's a real problem?
It may be a problem that new products continue to come out without IPv6
support, but in general, those new products use current implementations. So
again, there doesn't actually seem to be a useful requirement expressed.
IPv6 support MUST be equivalent or better in quality and
functionality when compared to IPv4 support in an IP
implementation.
So if the v6 support has more bugs than the v4 support (and hence lesser
quality), the implementation would be out of compliance with standards? I
don't think IETF standards set quality metrics on implementations.
As for functionality, consider the following bit of functionality: the
ability to communicate with an IPv4-only host. This is a piece of
functionality that v4 support has but v6 support doesn't. So I guess no
implementation could ever meet the "requirements" of this document.
Finally:
MUST NOT require IPv4 for proper and complete function.
Suppose the "proper and complete" function of a box requires the downloading
of updates from a server the box cannot necessarily reach using IPv6. Then
IPv4 would be required for proper and complete function of the box. Or
perhaps the box is a network monitoring appliance of some sort, and has to
use both IPv4 and IPv6 to do its job. In this case too, v4 is required for
"proper and complete" function, but that shouldn't lead anyone to say that
the box is non-compliant with IETF standards.
This document just does not say what it means. The RFC 2119 language is not
being used in the usual manner, it's really being used for its rhetorical
value. This is not appropriate.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf