At Wed, 17 Apr 2019 16:08:22 +0200,
Alexandre Petrescu <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. 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).
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.
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.
--
JINMEI, Tatuya
Alexandre Petrescu <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. 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).
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.
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.
--
JINMEI, Tatuya
