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

[Alexandre Petrescu <[e-mail]>]

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