Re: draft-bourbaki-6man-classless-ipv6-00

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

At Tue, 13 Jun 2017 13:26:59 +1200,
Brian E Carpenter <[e-mail]> wrote:

> > Router advertised Prefix/N (where N is nowadays hardcoded to be "64",
> > but need not). Host eploys RFC7217, and grabs 128-N random bits from F()
> > to generate the IID/address.
> >
> > Why does N need to be set on a per-link-type basis?
>
> It doesn't *need* to be. But SLAAC by design assumes that it is
> set per link-type; that is architectural flexibility which is
> removed by RFC4291, which IMHO is a bad message to send to the future.

I don't get the "which is removed by RFC4291" part.  Are you saying
that the "architectural flexibility" existed with RFC3513 but was
removed with RFC4291?  RFC3513 already had this text:

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Even RFC2373 had this:

      (2) The format prefixes 001 through 111, except for Multicast
          Addresses (1111 1111), are all required to have to have 64-bit
          interface identifiers in EUI-64 format.  See section 2.5.1 for
          definitions.

If I understand the "architectural flexibility" correctly, that
flexibility was already removed by RFC2373.  We were aware that the
constraint in the addressing architecture can cause nasty issues in
terms of the assumption of SLAAC (IID length is defined by link-type
doc) at the time of rfc2462bis discussions but intentionally left it
that way.  Of course, we can still revisit the decision at that time,
but I don't think it wise to do so in the context of rfc4291bis (see
also below).

In any case,

> I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis
> back to us, and the main reason I signed on to draft-bourbaki-6man-classless-ipv6

I don't think it's the reason why rfc4291bis was sent back.  As far as
I can see it was largely due to disagreement based on
misunderstanding:

- some people conflated on-link prefixes and subnet prefixes (where
  the latter is the prefix that is followed by IID in the addressing
  architecture) and objected to keeping the length of the latter to be
  64 bits for most unicast addresses, while what they really wanted is
  variable-length on-link prefixes and they already have them.
- some other people wanted to keep the length of subnet prefixes to be
  64 bits.  but perhaps those people interpreted the objection from
  the first group as an objection to keeping the subnet prefix length,
  and fired back at it.

If the main goal for draft-bourbaki-6man-classless-ipv6 is to resolve
this gridlock so we can move forward with rfc4291bis, the resolution
is IMO quite simple: just to clarify the main misunderstanding.  No
architectural or protocol change is necessary:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27679.html

Now, we are seeing a third group:

- yet some other people do not think keeping the subnet prefix length
  to be 64 bits (for most unicast addresses) does not make sense at
  all and argue for loosening it.

There are some variations of this group.  Reintroducing the
"architectural flexibility" (by making the subnet prefix/IID length
only dependent on link-type specs) could be considered one of them.
Some other people even suggest making it independent from the
link-type and leaving it to host/operator's choice.

We can discuss this proposal, but IMO this should be deferred as
post-rfc4291bis fodder.  I expect this will be a very controversial
discussion that will take quite long time (at least the second group
of people will fiercely fight against it), and there are currently
very few (if not no) implementations of the most flexible behavior
(i.e., making IID length fully variable) so it won't be compatible
with the scope of rfc4291bis.

--
JINMEI, Tatuya