James Carlson wrote:
Erik Nordmark writes:
[email protected] wrote:
Another thought that occurred to me is that what we really want
for both IPv4 and IPv6 is a generalization of the ipv6 IAID- if we
call this a "binding" (it could be the 4 byte IAID of dhcpv6, or
the "logical interface name" of ipv4 or some mix of the client-id and
ascii strings), then dhcpagent or in.ndpd could track the mapping
between a set of dynamically managed addresses and the "binding name".
The ipadm/libipadm interface would use the binding name as the
interface to adddress this object.
I went and looked RFC3315 because I though the DUID would be sufficient
for DHCPv6, but it seems like the full name would have to be <DUID,
IA-type, IAID> plus the IP interface name.
In the current DHCP implementation, we use the ifIndex number as the
IAID for the base interface when possible, but we keep stable storage
so that we never use the same interface name with a different IAID,
and we use an arbitrary number when it's a non-zero logical interface.
The DUID is LLT if possible, otherwise we use the UUID library to
generate an arbitrary one.
The bottom line is that the existing implementation allows you to set
these values if you really, really want to (see the DHCPv6 PSARC case
for details on how to do that), but you almost never really want to do
that.
That ends up being quite
long.
Interface name should work fine. That's what we use for IAID storage.
Yes, that is the normal form.
Just like DHCPv4 normally uses the MAC address.
But I think we should architect it so that the approach can apply when
one wants to use more than identity per IP interface (be it multiple
IIDs for stateless, multiple client-IDs for DHCPv4, and multiple
DUID/IAIDs for DHCPv6). In those cases one would explicitly need to name
the identity, which will be some long name.
We currently do support DHCPv4 getting multiple leases (through editing
some config file) thus the above direction would mean one could do that
as part of the ipadm syntax. (I doubt it will be used much, except when
there is some failover of DHCP-created addresses between systems.)
But if that can be unified with DHCPv4 client-IDs then at least
we'd have the full generality of a name space that can refer to the
identity. As long as the default (the DUID for DHCPv6, the IID for IPv6
stateless, and the DHCPv4 use of the MAC address as an ID) doesn't
require explicitly naming the object we could still have good CLI
usability and generality.
The current system doesn't require you to specify any of that, just
the interface name.
And my suggestion doesn't require that either. The default is a single,
implicitly named IID/IAID/DHCPv4 identity per IP interface.
But it allows specifying it, so that the naming of the identities is
complete and in one place. If we don't allow specifying it in ipadm then
one ends up with some complexity in the semantics of operations like:
- ipadm is used to create an IP address using the default DHCPv4 identity
- The admin also uses the dhcpagent config file to get an additional
DHCP lease for a separate client-ID
- The admin then uses ipadm to destroy the default one
Question: would that effect the additional lease?
If both the default and the additional are managed through ipadm it is
clear that they are different objects which can be created and destroyed
independently.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
