Le 09/04/2019 à 00:37, Brian E Carpenter a écrit :
On 08-Apr-19 21:18, Alexandre Petrescu wrote:
Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
Reviewer: Pascal Thubert Review result: Not Ready
[...]
"
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.
What do you mean by 'conforming IPv6'?
The above phrase is a clarification of existing IPv6 specs.
The spec in question is RFC 2464. I consider that to be what we
need to conform to. That spec says 'fe80::/64'. But that 64 is
wrong.
No it isn't. It specifies the LL prefix used over Ethernet. Since it
is within fe80::/10, it's valid.
YEs, it is valid.
I also don't understand the meaning of "at least" in this sentence.
"At least" means that at least the link-local prefix must be present on
the interface. More than LL prefix, there could be a global prefix or
an ULA prefix or several of them.
"At least" does not mean "the value should be at least 10" in that phrase.
Do you think we should say otherwise?
Hence the clarification.
If you specify the prefix as /10, you have to define how the other
118 bits are constructed. Specifying how the final 64 bits are
constructed is insufficient.
I agree. I could add text that suggests the use of 0s between position
64 and the position ending the prefix. Would this be ok with you?
Also, it seems to me that you should cite RFC8064 everywhere that you
cite RFC2464, since the EUI-64 mechanism is now considered obsolete.
It is considered obsolete ok, but are you sure?
There are enourmous deployments of embedded computers with kernels 2.x
that do that EUI-64 mechanism. It will take long to disappear.
An IPv6-over-OCB document today that does not do EUI-64 risks to not be
implemented.
I also think the citation of draft-hinden-6man-rfc2464bis is
confusing, since it seems to be comatose.
Ah no! Resurrect that, otherwise I remove the ref :-)
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?
(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)
Alex
Brian
the IANA starts at 10, and probably other reasons; there is a
recent I-D about this LL prefix length:
draft-petrescu-6man-ll-prefix-len-07).
Alex
