At Tue, 9 Apr 2019 16:11:33 +0200,
Alexandre Petrescu <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.
> (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. 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.
--
JINMEI, Tatuya
Alexandre Petrescu <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.
> (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. 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.
--
JINMEI, Tatuya
