Bonjour Alexandre,
On 10-Apr-19 02:11, Alexandre Petrescu wrote:
>
>
> 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?
To me there is nothing in the actual text to tell me that "at least"
qualifies the "/10". I think you could rephrase as
"This subnet's prefix MUST lie within the link-local prefix fe80::/10 ..."
However, see Jinmei's messages about conformance with RFC 4291.
I think there might be unexpected side effects from using an
address like fe80:1::1. What if some code uses matching with
fe80::/64 to test if an address is link-local? I agree that
would be faulty code, but you would be the first to discover it.
Regards
Brian
>>> 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
>>>
>>>
>>
>>
> .
>
