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

[Lorenzo Colitti <[e-mail]>]

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.