Re: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

[Fernando Gont <[e-mail]>]

Hello, Eric,

Thanks a lot for your comments! In-line....

On 20/10/20 10:49, Éric Vyncke via Datatracker wrote:
[....]
> 
> Thank you for the work put into this document. It is an important topic and it
> had stimulated a lot of hot discussions on the 6MAN list ;-)
> 
> I also appreciate the new section 3.7 where an admin can disable the mechanism.
> Is there a reason why this document does not briefly compare its addresses with
> RFC 7217 (stable address) ? It could be helpful for the reader.

Such topic has been discussed at length in RFC7721.  That's why we've 
referenced such document instead of trying to rehash the discussion.


> Please find below a couple of non-blocking COMMENT points and nits.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> Should link-local address generation also be considered here ? While the text
> is clear about 'global', there is no clear indication that this document does
> not apply to link-local addresses.

The idea of this document was to revise RFC4941, addressing shortcomings 
in said RFC. That's why the document remains the same wrt link-locals.

That said, link-locals are a different problem space. e.g., there's not 
much of a point in doing temporary addresses for link-locals if you 
don't randomize link-layer addresses. For some technologies, randomizing 
link layer addresses might force a network disconnect, etc.



> 
> -- Section 1 --
> First sentence, should "or by static configuration" be added ?
> 
> Should a reference to DHCPv6 be added ?

We should probably add a ref to DHCPv6, yes. And the other bit wouldn't 
hurt, either. So, how about:

OLD:
    Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an
    IPv6 node generates addresses without the need for a Dynamic Host
    Configuration Protocol for IPv6 (DHCPv6) server.

NEW:

    Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an
    IPv6 node generates addresses without the need for a Dynamic Host
    Configuration Protocol for IPv6 (DHCPv6) server [RFC8415] or manual
    configuration.

?


> -- Section 1.2 --
> Should IPPIX collectors also be mentioned in the first bullet list ?

WOuldn't that be somewhat included in bullet #1?



> On path attacker (really close to the node though !) can also do the
> correlation based on the layer-2 address. Should this be added to the 2nd list ?

I wouldn't add it, since this two-bullet list is mostly a non-exhaustive 
list of where correlation might happen based on the IPv6 addresses (note 
that the bulleted list also doesn't mention higher-layer IDs).



> -- Section 2.2 --
> I find the focus on DNS as 'rendez-vous' a little limiting. Why not mentioning
> DNS-SD or SIP proxy or ... Perhaps, prefixing the explanation with "When DNS is
> used" rather than using "machine would need a DNS name" (and BTW, it is also
> limiting to refer to a 'machine' as per container IPv6 address could be used)

Good points!

So, how about s/machines/nodes/. and also

s/In such cases, the machine would need a DNS name for its use as a 
server/In such cases, the node might need..."

?



> -- Section 3.1 --
> Point 5) the 2nd and 3rd sentences are really repeating themselves and not
> bringing a lot of value. Let's keep only one of the 2 or even none as the last
> sentence is really clear.

How about:

OLD:
    5.  By default, one address is generated for each prefix advertised
        by stateless address autoconfiguration.  The resulting Interface
        Identifiers must be statistically different when addresses are
        configured for different prefixes.  That is, when temporary
        addresses are generated for different autoconfiguration prefixes
        for the same network interface, the resulting Interface
        Identifiers must be statistically different.  This means that,
        given two addresses that employ different prefixes, it must be
        difficult for an outside entity to tell whether the addresses
        correspond to the same network interface or even whether they
        have been generated by the same host.

NEW:
    5.  By default, one address is generated for each prefix advertised
        by stateless address autoconfiguration.  The resulting Interface
        Identifiers must be statistically different when addresses are
        configured for different prefixes or different network
        interfaces. This means that, given two addresses that employ
        different prefixes, it must be difficult for an outside entity to
        tell whether the addresses correspond to the same network
        interface or even whether they have been generated by the same
        host.



> -- Section 3.4 --
> Should the text be clear on whether optimistic DAD may be used?

I'd believe the use of optimistic DAD is more of a general SLAAC thing 
than something related to temporary addresses. So I'd personally leave 
such discussion out.



> -- Section 3.6 --
> Last paragraph "when an interface connects to a new (different) link, a new set
> of temporary addresses MUST be generated immediately" seems to imply more than
> 1 temporary address with the use of 'set' and the plural form. Unsure whether
> it is the right behavior (esp if no RA-PIO are received yet).

How about

OLD:
    Finally, when an interface connects to a new (different) link, a new
    set of temporary addresses MUST be generated immediately for use on
    the new link.  If a device moves from one link to another, generating
    a new set of temporary addresses ensures that the device uses
    different randomized interface identifiers for the temporary
    addresses associated with the two links, making it more difficult to
    correlate addresses from the two different links as being from the
    same node.

NEW:
    Finally, when an interface connects to a new (different) link,
    temporary addresses MUST be generated immediately for use on
    the new link.  If a device moves from one link to another, generating
    a new set of temporary addresses ensures that the device uses
    different randomized interface identifiers for the temporary
    addresses associated with the two links, making it more difficult to
    correlate addresses from the two different links as being from the
    same node.

Xor, one might be more specific as in:

NEW:
    Finally, when an interface connects to a new (different) link,
    existing temporary addresses for that interface MUST be
    eliminated, and new temporary addresses MUST be generated immediately
    for use on the new link, according to the algorithm in Section 3.4.
    If a device moves from one link to another, this will ensure that the
    device uses different randomized interface identifiers for the
    temporary addresses associated with the two links, making it more
    difficult to correlate addresses from the two different links as
    being from the same node.


Thoughts?



> -- Section 6 --
> If only this was not 'future work' but I agree, this is not up to this document
> to specify such kernel API/implementation.

Double-checking: No changes suggested here, right?



> -- Section 9 --
> Should the ingress filtering be also part of the section 4 (implications) ?

How about, in Section 4:

OLD:
    Network deployments are currently recommended to provide multiple
    IPv6 addresses from each prefix to general-purpose hosts [RFC7934].
    However, in some scenarios, use of a large number of IPv6 addresses
    may have negative implications on network devices that need to
    maintain entries for each IPv6 address in some data structures (e.g.,
    [RFC7039]).  Additionally, concurrent active use of multiple IPv6
    addresses will increase neighbour discovery traffic if Neighbour
    Caches in network devices are not large enough to store all addresses
    on the link.  This can impact performance and energy efficiency on
    networks on which multicast is expensive (e.g.
    [I-D.ietf-mboned-ieee802-mcast-problems]).

NEW:
    Network deployments are currently recommended to provide multiple
    IPv6 addresses from each prefix to general-purpose hosts [RFC7934].
    However, in some scenarios, use of a large number of IPv6 addresses
    may have negative implications on network devices that need to
    maintain entries for each IPv6 address in some data structures (e.g.,
    [RFC7039]).  For example, concurrent active use of multiple IPv6
    addresses will increase neighbour discovery traffic if Neighbour
    Caches in network devices are not large enough to store all addresses
    on the link.  This can impact performance and energy efficiency on
    networks on which multicast is expensive (e.g.
    [I-D.ietf-mboned-ieee802-mcast-problems]). Additionally, some network
    security devices might incorrectly infer IPv6 address forging if
    temporary addresses are regenerated at a high rate.

Thoughts?



> -- Section 11.2 --
> I am afraid that RFC 7721 should be normative (introducing a downref though) as
> it is used in section 1.1 (terminology).

One possible alternative would be to copy the definitions of such terms 
to Section 1.1, and note that they have been borrowed from RFC7721.

Thoughts?

Thanks!

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