Skip to main content

Appeal Against moving draft-ietf-ipngwg-addr-arch-v3 to Draft Standard (Robert Elz; 2002-11-05) - 2002-11-05
Response - 2002-12-27

From: Harald Tveit Alvestrand <>
To: Robert Elz <kre@munnari.OZ.AU>
Subject: IESG response to appeal against moving

The IESG has reviewed the appeal by Robert Elz of the IESG decision to
approve for publication the Internet Draft
draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft Standard.

The appeal consists of two parts:

A/ Draft-ietf-ipngwg-addr-arch-v3-11.txt says:
"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."

In Robert's opinion, this text means that IPv6 implementations must enforce
the requirement that Interface IDs only be 64-bits long. RFC 2026 requires
multiple interoperable implementations of a technology, including all
options, must be shown to exist before a document can progress to Draft
Standard status. Robert takes this to mean that two or more
implementations have to be shown to restrict the ability of the user to set
an Interface ID to a length other than 64-bits in order for the technology
to be approved as a Draft Standard.

B/ Robert says "The requirement that where the 'u' bit (the inverted L bit
from the MAC address) is set, the IID is globally unique."

In Robert's opinion, this means that hosts must ensure that the Interface
ID is globally unique in this case. As above, Robert takes to also mean
that two or more implementations have to be shown to ensure that the
Interface ID is globally unique in order for the technology to be approved
as a Draft Standard.

The IESG notes that there is no wording in
draft-ietf-ipngwg-addr-arch-v3-11.txt requiring that IIDs be globally
unique. On this point, the document says:

Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link. They are required to be unique within a subnet

With regards to the 'u' bit, the requirement is simply:

Modified EUI-64 format interface identifiers are formed by inverting
the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
forming the interface identifier from IEEE EUI-64 identifiers. In
the resulting Modified EUI-64 format the "u" bit is set to one (1) to
indicate global scope, and it is set to zero (0) to indicate local

That is, the setting of the 'u' bit indicates whether the IID is
derived from an EUI-64 identifier (in which case it is likely to be
globally unique), but is not a guarantee that the IID is globally

When considering this appeal, it is clear from the interoperability
reports that there are implementations that generate the interface ID
from the EUI-64 identifier, which makes it be 64 bits long. It is
also clear that the uniqueness properties of EUI-64 based identifiers
will be the same as the EUI-64 identifiers from which they are derived
(which is slightly weaker than a requirement for global uniqueness).

So for at least some implementations, they are capable of acting as
specified in the document being challenged.

The IESG notes that the existing practice when advancing documents on
the standards track has not involved having implementation reports
include detailed verification that implementations enforce every
statement as is implied above, in the absence of explicit text
requiring that an implementation make such checks.

We traditionally require that things interoperate when configured
correctly, not that they interoperate when configured incorrectly, or that
it be impossible to configure them incorrectly.

Implementation reports are used to verify that independent implementations
can succesfully interoperate. This is a quality check on the clarity of the
Requiring explicit verification on all statements would be a change to
existing practice and one that would likely increase the difficulty in
advancing documents on the standards track.

There are many places in IETF standards where a field is stated to be
a specific length or a value to be within a range. Requiring that the
limits be enforced in software for all of these cases would put a
significant extra burden on the implementers and the documenters of
the implementations for questionable benefit.

If the IETF community believes such a change to our procedures is
beneficial, this should be taken as an explicit decision after due
deliberation by the IETF community.

Thus the IESG rejects the appeal.