At Tue, 9 Apr 2019 22:13:30 +0200,
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote:
> > 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.
>
> Thank you for the suggestion.
>
> I would like to ask you whether I can ask you to propose a formulation
> of using fe80::/10 without violating RFC4291 2.5.6?
>
> Maybe: "The OCB interface MAY use IPv6 link-local addresses with prefix
> length 10 without violating RFC4291 2.5.6, provided such address is
> allowed by IANA".
>
> Would this text be ok?
This is still ambiguous to me, but if its intent is to allow
fe80:1::1 without violating RFC4291 2.5.6, I don't think it's okay.
The RFC is super clear that the intermediate 54 bits are all 0:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
Declaring the 10 bits as "(link-local) prefix" can't change this fact.
> Or do you rather think we should not allow LLs on OCB with any other
> prefix than fe80::/64?
(Again, it's more about the value of intermediate 54 bits than /10 vs
/64, but anyway) not necessarily; it may be possible that the
ipwave-ipv6-over-80211ocb spec has a convincing reason for making an
exception to RFC4291 (right now I don't have sufficient understanding
of ipv6-over-80211ocb to judge that point).
> Can I dare to read you suggestion as implying that we should add an
> "Updates: 4291" text on the first page of the draft?
Yes, if this specification needs the intermediate 54 bits to have a
non-0 value. In that case I'd suggest making it clear which part of
RFC4291 this spec updates in which way, i.e, updating Section 2.5.6 of
RFC4291 to allow a non-0 value for the intermediate of 54 bits of an
address matching fe80::/10, and use it as an IPv6 link-local address.
This will inevitably require quite a high bar to pass IESG evaluations
and an IETF last call, but you'll probably find it worth the hassle if
this point is critical for the spec.
On the other hand, if this is something this spec can live without,
not proposing that update will certainly help it move forward faster
and with less controversy. In that case, some part of the wording
about the "prefix length" will have to be revised, so that it won't be
incorrectly interpreted as allowing fe80:1::1.
I have no suggestion about which option to take; it's up to you.
Whether I support the update in the evaluation/last call phase if and
when this update is proposed, is a totally different question.
--
JINMEI, Tatuya
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote:
> > 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.
>
> Thank you for the suggestion.
>
> I would like to ask you whether I can ask you to propose a formulation
> of using fe80::/10 without violating RFC4291 2.5.6?
>
> Maybe: "The OCB interface MAY use IPv6 link-local addresses with prefix
> length 10 without violating RFC4291 2.5.6, provided such address is
> allowed by IANA".
>
> Would this text be ok?
This is still ambiguous to me, but if its intent is to allow
fe80:1::1 without violating RFC4291 2.5.6, I don't think it's okay.
The RFC is super clear that the intermediate 54 bits are all 0:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
Declaring the 10 bits as "(link-local) prefix" can't change this fact.
> Or do you rather think we should not allow LLs on OCB with any other
> prefix than fe80::/64?
(Again, it's more about the value of intermediate 54 bits than /10 vs
/64, but anyway) not necessarily; it may be possible that the
ipwave-ipv6-over-80211ocb spec has a convincing reason for making an
exception to RFC4291 (right now I don't have sufficient understanding
of ipv6-over-80211ocb to judge that point).
> Can I dare to read you suggestion as implying that we should add an
> "Updates: 4291" text on the first page of the draft?
Yes, if this specification needs the intermediate 54 bits to have a
non-0 value. In that case I'd suggest making it clear which part of
RFC4291 this spec updates in which way, i.e, updating Section 2.5.6 of
RFC4291 to allow a non-0 value for the intermediate of 54 bits of an
address matching fe80::/10, and use it as an IPv6 link-local address.
This will inevitably require quite a high bar to pass IESG evaluations
and an IETF last call, but you'll probably find it worth the hassle if
this point is critical for the spec.
On the other hand, if this is something this spec can live without,
not proposing that update will certainly help it move forward faster
and with less controversy. In that case, some part of the wording
about the "prefix length" will have to be revised, so that it won't be
incorrectly interpreted as allowing fe80:1::1.
I have no suggestion about which option to take; it's up to you.
Whether I support the update in the evaluation/last call phase if and
when this update is proposed, is a totally different question.
--
JINMEI, Tatuya
