Re: [Int-dir] 118

[Alexandre Petrescu <[e-mail]>]

Le 17/04/2019 à 22:40, 神明達哉 a écrit :
> At Wed, 17 Apr 2019 16:08:22 +0200, Alexandre Petrescu
> <[e-mail] <mailto:[e-mail]>>
> 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