Tatuya,
Thank you for the message.
Le 09/04/2019 à 19:14, 神明達哉 a écrit :
At Tue, 9 Apr 2019 16:11:33 +0200, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>>
wrote:
"
This subnet MUST use at least the link-local prefix fe80::/10
and the interfaces MUST be assigned IPv6 addresses of type
link-local. " If this is conforming IPv6 then the MUST is
not needed.
[...]
Do you disagree with it?
(the reasons why I put there /10 and not /64 are the following:
LLs work in linux with any length between 10 and 64, the ND
spec does not restrict to 64,
No, but IPv6-over-foo documents usually do apply that
restriction, rather than define 118-bit IIDs.
It is good to know about practice in IPv6-over-foo documents.
What should I do in the IP-over-OCB document: continue that
restriction? or define 118bit IID with filling in 0s between 64 and
position of last bit of prefix?
I don't have a strong opinion about specifically what this doc
should say, but "MUST use at least the link-local prefix fe80::/10"
shouldn't be interpreted as if we could use fe80:1::1 as a valid
IPv6 link-local address without violating the current addressing
architecture (RFC4291, Section 2.5.6). If this text can be
interpreted that way, we should definitely revise it.
Thank you for the suggestion.
I would like to ask you whether I can ask you to propose a formulation
of using fe80::/10 without violating RFC4291 2.5.6?
Maybe: "The OCB interface MAY use IPv6 link-local addresses with prefix
length 10 without violating RFC4291 2.5.6, provided such address is
allowed by IANA".
Would this text be ok?
Or do you rather think we should not allow LLs on OCB with any other
prefix than fe80::/64?
(in implementation I already did fe80:1::1/32 as a link-local
address on OCB at 5.9GHz; the prefix is fe80:1::/32 and the IID is
::1 of length 96 with 32 leading 0 bits; it works between cars)
It's a violation of the current addressing architecture.
But it does not violate IANA allocation, right?
Anyone can do whatever they want in their pet implementations, but
unless/until this document updates RFC4291 so that it explicitly
allows a non-0 value in the intermediate 54 bits, it has nothing to
do with this current discussion. Non-compliant implementations can
work as their author intends, especially if they don't care about
interoperability. But that doesn't make it magically standard
compliant.
Thank you for the suggestion.
Can I dare to read you suggestion as implying that we should add an
"Updates: 4291" text on the first page of the draft?
Or should I interpret it as a suggestion to not even try to update RFC4291?
About the doubting of authors interoperability worries: the authors do
care extensively about interoperability. The interoperability of LLs,
at this time, is being checked against linux versions, and some BSD flavor.
Alex
-- JINMEI, Tatuya
