Le 17/04/2019 à 22:40, 神明達哉 a écrit :
At Wed, 17 Apr 2019 16:08:22 +0200, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>>
wrote:
"SHOULD be of a length specified in other documents" wihtout any
reference to what the other documents are or how to find them
seems
like
a recipe for implementor error. Can we be somewhat more
specific?
One could be more specific about which document. There is some
individual work item (not a WG item) in 6man that one could point
to. A reference to a non WG item will not delay this document?
Or, rather, should I propose a new formulation above which just
keeps:
NEW:
A randomized Interface ID has the same characteristics of a
randomized MAC address.
In the context of the "Privacy Considerations" section, that's
probably good enough. After all, the privacy implication of the IID
length doesn't seem to be specific to IPv6-over-COB.
But, in the context of stateless address configuration, the length
must be unambiguously specified since RFC4862 assumes it's specified
in each IPv6-over-foo specification, and without knowing this exact
length it's nearly impossible to develop an interoperable
implementation regarding SLAAC for that IPv6-over-COB.
To this end I've checked Section 4.4 (of rev 42) and found it not
very clear. The most relevant text seems to be this one:
The Interface Identifier for an 802.11-OCB interface is formed using
the same rules as the Interface Identifier for an Ethernet
interface;
but it's not clear if it means the same IID length as that for
Ethernet, i.e., 64 bits, especially because the draft previously
mentioned 118 bits of IID (for link-local addresses) and now (rev
42) leaves the length to "other documents".
While stateless address autoconfiguration (RFC4862) specifies
link-specific IPv6-over-foo docs as the primary source of this
information, it's also based on the assumption that it's consistent
with the address architecture:
interface identifier - [...] The exact length of an interface
identifier and the way it is created is defined in a separate
link-type specific document that covers issues related to the
transmission of IP over a particular link type (e.g., [RFC2464]).
Note that the address architecture [RFC4291] also defines the length
of the interface identifiers for some set of addresses, but the two
sets of definitions must be consistent.
so, as of today, it cannot be other value than 64 bits unless this
document makes an exception for IPv6-over-OCB by formally updating
RFC4291 so that IPv6-over-OCB and the (updated) address architecture
will still be consistent.
Now, from the discussion so far, I'm feeling the sense of a desire
for IPv6-over-OCB to use other values of IID length than 64 bits.
The desire comes from my deployment of linux on 3 single-link subnets
needing fe80:1::1 (linux has no zone id, but supports fe80::/32).
I am not sure about the others.
Perhaps that's one background reason why this is left not so
explicit. But since the value of IIDs is so important for the
interoperability of SLAAC, I don't think we can leave it obscure.
Whether it's in this document or "other documents", it must be
explicitly specified. And if it's in "other documents", it must
already exist or must have been published no later than this
document. And, if it's something other than the status quo (i.e. 64
bits), it must formally update RFC4291 (and, needless to say, this
will be extremely challenging - recall how rfc4291bis is half-dead in
limbo due to this exact debate).
I have two distinct LL addresses on an interface: one that is
complicated (fe80::IID/64) and one that is easy to remember and type
(fe80:1::/32).
"The other documents" is something that could be done in 6MAN WG. If
they agree. That is a big IF.
I want this IP-over-OCB document to progress and to reflect reality as
much as possible.
If IPv6-over-OCB can live with the status quo at least for now, that
will be the easiest and fastest way forward. If IPv6-over-OCB
people don't like to make another precedent of the use of the
constant value of 64, it might explicitly note that the appropriate
length of IIDs has been subject to hot debates and may become more
flexible in future.
May it?
To be clear: I'm not making any opinion on whether the hard fixed
value of 64 is good or bad. I'm just pointing out procedural
constraints.
Ok.
Alex
-- JINMEI, Tatuya
