Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64

[Brian E Carpenter <[e-mail]>]

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
>>>
>>>
>>
>>
> .
>