Bug 1749358

Hi, we discussed this in the NM meeting and come up with these ideas:

1) add a new property to the ipv6 setting to specify a IAID, accepting
a keyword like 'mac' to use the hardware address. However, every new
property requires a lot of code and documentation, and appears in the
output of 'nmcli connection show' which is becoming increasingly
bloated; especially because nmstate will probably be the only user of
this feature;

2) change the internal client to build the IAID from the MAC as
dhclient does; but this causes a change of IAID (and so, potentially a
different IP from DHCP) when the NIC is changed. And also, we can't
easily change this behavior now because it would break things on
upgrade;

3) if NM could read and write the IAID from a lease on disk, nmstate
or what is above it could copy the lease file for the NIC (containing
the IAID) to a new bridge lease file, so that the IAID is
reused. However this bypasses NM and doesn't use D-Bus, so seems not
suitable for nmstate.

But honestly all the proposals above look ugly to do in NM.

Gris, Edward, what do you think? Is there anything else that can be
done outside of NM to solve this problem?

(In reply to Beniamino Galvani from comment #1)
> 
> 1) add a new property to the ipv6 setting to specify a IAID, accepting
> ...
> 
> 2) change the internal client to build the IAID from the MAC as
> ...
>
> 3) if NM could read and write the IAID from a lease on disk, nmstate
> ...

I don't think changing behaviour (2) is acceptable.

3) is also not acceptable, because we should rely on lease files as little as possible. In particular, the configuration must come top down (from the connection profile or NetworkManager state). The lease file is something that comes back from the lower layers, we should not use that as input again (except where really sensible, like for the last address). Also, the lease files are internal API of NM. nmstate is certainly not supposed to care about these files.

I don't see a problem with 1). Yes, DHCP possibly has a gazillion of options. There is no way around that, you either say, the option is not configurable (and close this bug as WONTFIX), or you make it configurable.

btw, as we have the DUID configurable, it seems sensible that the IAID is configurable too...

The only acceptable way seems 1), so we could add new ipv4.dhcp-iaid
and ipv6.dhcp-iaid properties accepting the following values:

 - (empty) means that the global default is used, which is 'ifname'
   unless overridden by user. This preserves the current behavior,
   except for dhclient with IPv6 that currently uses the MAC. But note
   that 'dhclient -6' doesn't allow passing a IAID and so we should
   document that the property has no effect with dhclient/IPv6.

 - 'ifname' derives the IAID from an hash of interface name (like we
   do at the moment);

 - 'mac','perm-mac' build the IAID from the current or permanent MAC
   (copy of last bytes of the address, not hashed).

 - any other value containing only digits is treated as a 32-bit
   number and used as IAID.

Opinions?

> Opinions?

sounds good, but:

- why are the options "mac"/"perm-mac" useful?

- why do the options "mac"/"perm-mac" use the last bytes of the address, and not
  hash the value. Arguably, the IAID is only 32 bits, so regardless whether you hash
  or use the last bytes, it seems bound to have a danger of conflicts. That the IAID
  is limited to 32 bits is a problem for all manners of generating the value (aside
  letting the user explicitly configure a value).

- there should also be a "stable" mode, that hashes the stable-id. The stable-id
  is essentially the identity of the profile, which is particularly interresting with
  ${BOOT} to generate new values on each boot.
  I guess, when you hash the stable-id, then this should also include the interface-name.
  Note that ipv4.dhcp-client-id=stable does *not* hash the interface-name, but
  ipv6.addr-gen-mode=stable-privacy does hash the interface-name. Whether a stable generation
  includes the interface-name (or any other per-interface part) depends on the use, and for
  the IAID, it seems prodent to include it.
  On the other hand, connection.stable-id also supports specifiers like ${DEVICE} and ${MAC},
  so theoretically, the user could also generate per-device identifiers, if the IAID would not
  already include a per-device part.

- what does rfc7844 (privacy/anonymity profiles) say about the IAID?

- would accepting "ifindex" make sense? The advantage is that it's unique per-device, and
  it never generates duplicates for the 32bits. This is the only mode that is suggested so
  far that would guarantee that different interfaces get different IAIDs.

don't we also need a ipv4.dhcp-iaid?

With RFC4361, the main point is that IPv4 and IPv6 can identify itself in the same way.
So, you can configure ipv4.dhcp-client-id=duid, but don't we need the flexibility for the
IAID too?

(In reply to Thomas Haller from comment #6)
> sounds good, but:

> - why are the options "mac"/"perm-mac" useful?

Because with "mac" it becomes possible to move the MAC to a different
interface and obtain the same IPv4/IPv6 addresses as before without
configuring additional properties. For the same reason, perhaps
"perm-mac" is not so useful, I only added it for consistency with
ipv4.dhcp-client-id; I think it's better to skip it for now.

> - why do the options "mac"/"perm-mac" use the last bytes of the address, and not
>   hash the value. Arguably, the IAID is only 32 bits, so regardless whether you hash
>   or use the last bytes, it seems bound to have a danger of conflicts. That the IAID
>   is limited to 32 bits is a problem for all manners of generating the value (aside
>   letting the user explicitly configure a value).

As you said, mapping 6 bytes to 4 will cause collisions anyway, so
taking the last 4 bytes seems the simplest solution; since also
dhclient does this it becomes possible to keep the same IAID when
switching between clients. Ok, this is not a strong reason, using the
hash would also be fine in my opinion.

> - there should also be a "stable" mode, that hashes the stable-id. The stable-id
>   is essentially the identity of the profile, which is particularly interresting with
>   ${BOOT} to generate new values on each boot.
>   I guess, when you hash the stable-id, then this should also include the interface-name.
>   Note that ipv4.dhcp-client-id=stable does *not* hash the interface-name, but
>   ipv6.addr-gen-mode=stable-privacy does hash the interface-name. Whether a stable generation
>   includes the interface-name (or any other per-interface part) depends on the use, and for
>   the IAID, it seems prodent to include it.
>   On the other hand, connection.stable-id also supports specifiers like ${DEVICE} and ${MAC},
>   so theoretically, the user could also generate per-device identifiers, if the IAID would not
>   already include a per-device part.

> - what does rfc7844 (privacy/anonymity profiles) say about the IAID?

  "The IA_NA option includes an IAID parameter that identifies a unique
   IA for the interface for which the address is requested.  Clients
   interested in protecting their privacy MUST ensure that the IAID does
   not enable client identification.  They also need to conform to the
   requirement of [RFC3315] that the IAID for that IA MUST be consistent
   across restarts of the DHCPv6 client.  We interpret that as requiring
   that the IAID MUST be constant for the association, as long as the
   link-layer address remains constant."

The important part is "Clients interested in protecting their privacy
MUST ensure that the IAID does not enable client identification". I'm
not sure what that means, but the last sentence seems to imply that
ipv6.dhcp-iaid=mac would satisfy the requirement (provided that the
user changed the cloned-mac-address).

The RFC also says:

  "Clients MAY meet the privacy, uniqueness, and stability requirements
   of the IAID by constructing it as the combination of 1 octet encoding
   the interface number in the system, and the first 3 octets of the
   link-layer address."

but I would prefer if we just implemented very few modes initially,
and add later what users actually need.

> - would accepting "ifindex" make sense? The advantage is that it's unique per-device, and
>   it never generates duplicates for the 32bits. This is the only mode that is suggested so
>   far that would guarantee that different interfaces get different IAIDs.

The ifindex can change after a reboot, which seems a big disadvantage.

> don't we also need a ipv4.dhcp-iaid?

Yes, my comment mentions both properties.

(In reply to Beniamino Galvani from comment #8)
> (In reply to Thomas Haller from comment #6)
> > sounds good, but:
> 
> > - why are the options "mac"/"perm-mac" useful?
> 
> Because with "mac" it becomes possible to move the MAC to a different
> interface and obtain the same IPv4/IPv6 addresses as before without
> configuring additional properties. For the same reason, perhaps
> "perm-mac" is not so useful, I only added it for consistency with
> ipv4.dhcp-client-id; I think it's better to skip it for now.

Makes sense.

> 
> > - why do the options "mac"/"perm-mac" use the last bytes of the address, and not
> >   hash the value. Arguably, the IAID is only 32 bits, so regardless whether you hash
> >   or use the last bytes, it seems bound to have a danger of conflicts. That the IAID
> >   is limited to 32 bits is a problem for all manners of generating the value (aside
> >   letting the user explicitly configure a value).
> 
> As you said, mapping 6 bytes to 4 will cause collisions anyway, so
> taking the last 4 bytes seems the simplest solution; since also
> dhclient does this it becomes possible to keep the same IAID when
> switching between clients. Ok, this is not a strong reason, using the
> hash would also be fine in my opinion.

Actually, if a data center contains only network cars from the same manufacturer
(so the the first to bytes of the OUI are all equal), then this method guarantees
that the IAID is unique. Well, at least with "mac-perm", which makes a very good case
for including this mode. With "mac" you might loose that uniqueness guarantee if the
MAC gets generated itself, but you get what you said before (about moving the profile to
a bridge).

So, both modes make sense to me and I'd keep them both.


> > - there should also be a "stable" mode, that hashes the stable-id. The stable-id
> >   is essentially the identity of the profile, which is particularly interresting with
> >   ${BOOT} to generate new values on each boot.
> >   I guess, when you hash the stable-id, then this should also include the interface-name.
> >   Note that ipv4.dhcp-client-id=stable does *not* hash the interface-name, but
> >   ipv6.addr-gen-mode=stable-privacy does hash the interface-name. Whether a stable generation
> >   includes the interface-name (or any other per-interface part) depends on the use, and for
> >   the IAID, it seems prodent to include it.
> >   On the other hand, connection.stable-id also supports specifiers like ${DEVICE} and ${MAC},
> >   so theoretically, the user could also generate per-device identifiers, if the IAID would not
> >   already include a per-device part.
> 
> > - what does rfc7844 (privacy/anonymity profiles) say about the IAID?
> 
>   "The IA_NA option includes an IAID parameter that identifies a unique
>    IA for the interface for which the address is requested.  Clients
>    interested in protecting their privacy MUST ensure that the IAID does
>    not enable client identification.  They also need to conform to the
>    requirement of [RFC3315] that the IAID for that IA MUST be consistent
>    across restarts of the DHCPv6 client.  We interpret that as requiring
>    that the IAID MUST be constant for the association, as long as the
>    link-layer address remains constant."
> 
> The important part is "Clients interested in protecting their privacy
> MUST ensure that the IAID does not enable client identification". I'm
> not sure what that means, but the last sentence seems to imply that
> ipv6.dhcp-iaid=mac would satisfy the requirement (provided that the
> user changed the cloned-mac-address).

Agree


> The RFC also says:
> 
>   "Clients MAY meet the privacy, uniqueness, and stability requirements
>    of the IAID by constructing it as the combination of 1 octet encoding
>    the interface number in the system, and the first 3 octets of the
>    link-layer address."
> 
> but I would prefer if we just implemented very few modes initially,
> and add later what users actually need.

Agree. The only reason to do this, is if others do it (to blend into the crowed).


> > - would accepting "ifindex" make sense? The advantage is that it's unique per-device, and
> >   it never generates duplicates for the 32bits. This is the only mode that is suggested so
> >   far that would guarantee that different interfaces get different IAIDs.
> 
> The ifindex can change after a reboot, which seems a big disadvantage.

True. But that may be fine. There is also "connection.stable-id=${BOOT}", sometimes
you are fine with non-stable things. But ok, let's omit this for now, especially because
the main advantage (no conflicts) may be achievable with "mac" (in practice).


> > don't we also need a ipv4.dhcp-iaid?
> 
> Yes, my comment mentions both properties.

Ack.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/315

Hi Beniamino,

I am OK with the `ipv4.dhcp-iaid` and `ipv6.dhcp-iaid` properties.

Thanks.

Merged upstream:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/3165fd8e8eb5ccbc2647b6104ab475f1c5e14178

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1847