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

[Brian E Carpenter <[e-mail]>]

On 14/06/2017 04:39, 神明達哉 wrote:
> 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?  

No, that was not my intention. I'm sorry if it seemed otherwise.
We have always had this rather strange feature that the address
architecture describes a flexible boundary and then fixes it.

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

I largely agree with you. Making the boundary truly flexible is much 
more complex than some people think. All I personally want to see is
a version of 4291 that leaves some flexibility for further discussion,
and doesn't appear to forbid a number of existing operational practices.

I agree with you about the phrase "subnet prefix" in 4291. But I also
believe that making the unicast IID length "recommended" instead of
"required", although it seems like a small point, removes a lot
of the objections we heard during IETF Last Call.

    Brian