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

[David Farmer <[e-mail]>]

On Mon, Jul 10, 2017 at 8:24 PM, Lorenzo Colitti <[e-mail]> wrote:

> On Tue, Jul 4, 2017 at 2:36 AM, Bob Hinden <[e-mail]> wrote:
>
>> I published a new 6man w.g. version (-09) of the RFC4291bis draft.  See
>> links below.
>>
>
> Actually, after lots of thought, I object to this document in its current
> form, specifically due to the text "or by exceptions defined in standards
> track documents". I feel that this text is a net negative in terms of the
> functionality provided by the protocol to its users.
>
> Allowing IIDs shorter than 64 bits has no value that I can see that is not
> already covered by the exception for manual configuration. Pretty much the
> only thing we can do with it is support SLAAC with shorter IIDs, and
> *nobody* has yet answered the question of how that would be beneficial in
> the long therm.
>
> In the short term we might tell ourselves that shorter IIDs will allow
> users to extend the network at the edges. But the reality is that in the
> long term we'll just see some networks provide the minimum allocation that
> is accepted by hosts. (There are examples of this today, in the case of
> cable networks that only provide a single /64 to the home.) Because hosts
> adapt to the lowest-common denominator network, over time the only effect
> is to move the commonly-used subnet boundary between subnet prefix and IID
> from 64 towards 128. This will be accelerated by networks whose policies
> include limiting the number of devices allowed on a particular connection.
> (Again, there are examples today: enterprise networks that want one GUA per
> host, mobile carriers have a requirement to allow only x devices to tether
> behind a smartphone, etc.) I don't think that's a use case.
>
> So, what are the other use cases? If there are no use cases, we should not
> make this change.
>
> I understand Brian and David's position that this is just a parameter and
> that the architecture is inconsistent, but better an inconsistent network
> architecture than a degradation of function.
>

I've begun to think there are two real problems here;

1.  RFC4291 categorically says architecturally IIDs are 64bits, and seems
to imply this is the case for all components of IPv6. While it is the case
for several components of IPv6, it is not the case for other important
components. Neighbor Discovery, DHCPv6, and Routing, etc... are not
architecturally based on 64bit IIDs at all, in fact they are clearly based
on IIDs of any length.

2. The fact that some components of IPv6 are architecturally based on 64bit
IIDs doesn't mean that operationally IIDs are always required to be 64
bits. Rather than implying that operationally IID are required to be
64bits, how about simply stating that operationally 64 bit IIDs are
recommended. This eliminates the need to enumerate all the exceptions,
which probably isn't something an architectural document should be doing.

So, I would propose the following for RFC4291bis;

Several components of IPv6 are architecturally based on a requirement that
Interface Identifiers are 64 bit long except if the first three bits of the
address are 000. The rationale for using 64 bit Interface Identifiers can
be found in [RFC7421]. However, other components of IPv6 are
architecturally based
on Interface Identifiers of any length, most importantly Neighbor Discovery
[RFC4861]. Neither of these two architectures override or invalidate the
other. Accordingly, 64 bit Interface Identifiers are recommended for
operational use.

Thanks.




-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================