Re: <draft-ietf-6man-rfc4291bis-09.txt>

[神明達哉 <[e-mail]>]

At Thu, 20 Jul 2017 03:36:21 +0000,
"Manfredi, Albert E" <[e-mail]> wrote:

> >> why ask the question?
> >
> > a) Because of the several subtly different meanings of 'prefix' in IPv6.
>
> Some prefixes can be on-link, while others are not. Okay, but this
> is a question of address architecture, and whatever prefix bits
> exist in that 128-bit address, the remaining bits are by definition
> IID.

I suspect Brian tried to explain that some people interpret prefixes
for on-link determination are a different kind of prefix than the
"subnet prefix" as defined in Section 2.5 of RFC4291.  For those
people it's not obvious whether the remaining bits that follow the
on-link prefix are "by definition IID".  Before saying "those people
are simply wrong because section X of RFC Y says this...", please see
below.

>
>    |          n bits               |           128-n bits            |
>    +-------------------------------+---------------------------------+
>    |       subnet prefix           |           interface ID          |
>    +-------------------------------+---------------------------------+
>
> > b) Because some people seem to be limiting their use of 'IID' to the SLAAC
> > meaning of 'prefix'.
>
> I see only a small ambiguity in this regard. From RFC 4862:
>
>    interface identifier -  a link-dependent identifier for an interface
[...]
> This definition does not limit the IID to 64 bits either, giving RFC
> 2464 only as an example, and saying only that "in many cases," the
> IID is derived from the link layer address. Without specifying how
> long that might be. And it refers back to RFC 4291, which does not
> limit IID to 64 bits.

I don't see how this can be a counter-argument to what Brian said,
which was not about the length of IID.  The original question was
whether the "remaining bits" in the above context are considered to be
IID.  In that context, 'b' should be interpreted as:

- some people seem to be limiting their use of 'IID' to SLAAC meaning
  of 'prefix', i.e, a prefix advertised via RA PIO with A flag being 1.
- if a prefix for on-link determination (a prefix advertised via PIO
  with L flag being 1 and A flag maybe being 0) is different from this
 'SLAAC meaning of prefix' (either in the bit pattern or in the prefix
 length), this means the "remaining bits" are not IID "by definition"
 for those people since in their definition "IID" is used only for
 remaining bits that follow an SLAAC meaning of prefix.

Whether the IID in those people's definition is fixed at 64 bits is
irrelevant in this context.

Here, I'm not trying to convince you that their view is correct.  To
me, however, those "some people" and people like you or Brian have
both some valid points, and it's not that one of the views is definitely
correct and the other is completely wrong.  The difference of the
views comes from the fact that RFC4291 or its bis is not super crystal
clear and there is some possible inconsistency between it and other
IPv6 RFCs, leaving questions like this one to one's interpretation.
It seems that people believing one particular view tend to refer to
some specific part of those RFCs or drafts or existing implementations
that are convenient to reach their favorite interpretation, but the
reality is that other interpretations can be quite possible.  I don't
expect either group with a strong opinion to agree with the other, but
at least unless they recognize both groups have some reason to believe
a particular view, we will never be able to escape from this gridlock,
at least in the scope of rfc4291bis.

--
JINMEI, Tatuya