Re: Iotdir telechat review of draft-ietf-6man-rfc4941bis-11

[Fernando Gont <[e-mail]>]

On 21/10/20 18:59, Dave Thaler wrote:
> Fernando Gont <[e-mail]>  wrote:
>>>>> Section 4:
>>>>> With the change to use a separate IID per prefix, I believe the 2nd
>>>>> paragraph should be augmented to point out that simply upgrading an
>>>>> RFC 4941-compliant node to an implementation of this draft can
>>>>> exacerbate the problem mentioned in this paragraph.
>>>>
>>>> For all practical scenarios, this will actually be the other way around:
>>>> Since this document reduces the Valid Lifetime, then, for the case where
>>>> the local network employs say, one GUA prefix and one ULA prefix, nodes
>>>> would end up using 4 concurrent temporary addresses, as opposed to the
>>>> 14 temporary addresses they might end up employing with RFC4941.
>>>
>>> That depends on whether a non-default Valid Lifetime is configured.
>>> My meta-point is that this paragraph would benefit from a discussion about
>>> the upgrade effects, like we're now discussing here.
>>
>> Fair enough. Would it be okay to address this in the Security
>> Considerations Section, as opposed to Section 4?
> 
> My opinion is that this point is different from security considerations
> (which is a separate point), it's more "upgrade considerations" since the
> point here is that simply upgrading might cause a battery drain if you
> have things configured in a particular way.  No attacker is involved.
> Security considerations are for things that are about attacks or mitigations.

Oops! Looks like I misunderstood you. -- I thought you were portraying 
this issue as a security issue (rather than an upgrade issue). So let me 
proposed the following text instead:

---- cut here ----
RFC4941 employed a randomized temporary Interface Identifier for 
generating temporary addresses, such that a set of temporary addresses 
configured at a given time (for multiple SLAAC prefixes) would employ 
the same Interface Identifier.  Sharing the same IID among multiple 
address allowed host to join only one solicited-node multicast group 
pero temporary address set.

This revision requires that temporary addresses configured for different 
SLAAC prefixes employ interface identifiers that are statistically 
different from each other. This means that when a network employs 
multiple prefixes, each temporary address of the set will result in a 
different solicited-node multicast address, and thus the number of 
multicast groups that a host should join becomes a function of the 
number of SLAAC prefixes employed for generating temporary addresses).

Thus, a network that employs multiple prefixes may require hosts to join 
more multicast groups than in the RFC4941 case. If the number of 
multicast groups is large enough, a node may need to resort to setting 
the network interface card to promiscuous mode. This would cause the 
node to process more packets than strictly necessary, and might have a 
negative impact on battery-life, and on system performance in general.

We note that since this document reduces the default TEMP_VALID_LIFETIME 
from 7 days (in [RFC4941]) to 2 days, the number of concurrent temporary 
addresses per SLAAC prefix will be smaller than for RFC4941 
implementations, and thus the number of multicast groups for a network 
that employs, say, between 1 and threee prefixes will be similar than 
for RFC4941 implementations.

Implementations concerned with the maximum number of multicast groups 
that would be required to join as a result of configured addresses, or 
the overall number of configured addresses, should consider enforcing 
implementation-specific limits on e.g. the maximum number of configured 
addresses, the maximum number of SLAAC prefixes that are employed for 
auto-configuration, and/or the maximum ratio for 
TEMP_VALID_LIFETIME/TEMP_PREFERRED_LIFETIME (that ultimately controls 
the number of concurrent temporary addresses per SLAAC prefix). Many of 
these configuration limits are readily available in SLAAC and RFC4941 
implementations. We note that these configurable limits are meant to 
prevent pathological behaviors (as opposed to simply limiting the usage 
of IPv6 addresses), since IPv6 implementations are expected to leverage 
the usage of multiple addresses [RFC7934].
---- cut here ----

?

BTW, should this be incorporated into Section 4, or elsewhere?

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492