Re: SLAAC vs DHCPv6 (II)

[Michael Richardson <[e-mail]>]

Fernando Gont <[e-mail]> wrote:
    >> IIRC that was tried a few years ago and did not go anywhere (I think Suresh
    >> has more details). >
    >> We could try again, though - if it's true that the main reason that
    >> operators want DHCPv6 is tracking, then it could be a good middle ground
    >> between devices that want SLAAC's ability to form addresses without
    >> permission and networks that want DHCPv6's tracking abilities.

    > I don't believe the motivation is tracking, but some sort of control,
    > including:
    > * logging

I think that the key activity they want is auditing.
(Sorry to be pendantic here, but I think it might matter to future direction)

The log provides that, but if you can come up with a different mechanism then
that would be fine too.  DHCPv6 provides the audit through a log.

But for instance, if SEND were used, such that the address could be linked
to a public key/certificate which was in a certificate used for 802.1X
(perhaps enrolled autonomically), then that would satisfy the audit needs
without necessarily resulting in a new source of data with a vulnerability to
exfiltratration.

    >> If we do this it's important that the semantics only support tracking
    >> existing addresses and not requesting addresses. Otherwise there will be a
    >> conflict with the recommendations in RFC 7934 section 8 - and it would
    >> basically be identical to IA_NA which is already a standard.

    > Well, the whole thread entitled "RFC4941bis: consequences of many addresses
    > for the network" seem to be in conflict with RFC7934. -- i.e., folks have
    > concerns about nodes configuring an arbitrary number of addresses at will.

Yes.
I think that the thing that we are realizing is that 4941 doesn't give us
that much privacy for residential (or 3G/LTE!) situations.

Stable private addresses which are not manufacturer assigned EUI-48/64
derived are probably almost as good.  Per-provider-domain randomized L2 MAC
addresses with EUI-derived IIDs are possibly equivalent, except that we don't
have a direct DAD mechanism for that layer. (The IPv6 LL DAD is good here, as
much as it is rather a layer violation)

On the other hand, the places where 4941 works, it works because the
anonymity set is large.   In those situations, where it works, we need to make
sure that we do not wind up with hard-to-diagnose failure cases due to
policies (or implementation bugs) on routers with respect to number of NCE.

There are interactions that we should be aware of with L2 bridging and
Proxy-ND such that the IPv6-address:L2-address ratios could legitimately
vary a *lot*.

So, I'm not entirely sure what the motivation for 4941bis is (Internet
Standard?), but it seems to me that we are not solving the right problem
here.

I actually think that there is an entire WG worth of effort here.

    >> Note that 6man is working another way of getting this information to the
    >> network, see the "multicast NA to ff02::2 whenever an address is
    >> configured" proposal in draft-linkova-6man-grand.

    > I don't think that's registration in the same sense. For Jen's proposal, it's
    > "best effort" registration. For logging, you need to implement a reliability
    > mechanism. As we keep putting more state into SLAAC, it becomes more of AAC
    > than SLAAC. And IPv6 automatic configuration as a whole becomes harder and
    > harder to explain to newcomers, so to speak.

Agreed, because AFAIK, the router can't send a NAK.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-