[email protected] wrote:
from libipadm's point of view, it would be better if we didn't make
any assumptions about what the IAID is (so that we don't constrain
how this could be extended in the future). Besides, we already have a
back-end process (dhcpagent, in.ndpd) that actually brokers
with the dhcpserver, and knows about the various options supported
by the prototcol. So how about the following
ipadm create-dhc4 <dhcpv4 options> <binding>
ipadm create-dhc6 <dhcpv6 options> <binding>
where the options would contain things like -l <interface>,
-i <iaid> -d <duid> etc. relevant to each protocol, and <binding>
can be an ascii string that dhcpagent maps to the unique set of
parameters identifying the dhcp address-object.
That doesn't make it clear what is the name of the object.
For instance, if I do
ipadm create-dhcpv4 -l bge0 -d foo
will that be affected or not by
ipadm destroy-dhcpv4 -l bge0
Does the answer change if I have
ipadm create-dhcpv4 -l bge0 -d foo
ipadm create-dhcpv4 -l bge0 -d bar
and then do
ipadm destroy-dhcpv4 -l bge0
??
I think making it clear what identifies the object so that what one
names in a destroy (or modify) is crystal clear.
FWIW create-dhcpv6 doesn't make sense as a name if stateless and DHCPv6
are welded together as they are in the RFCs. create-ipv6 makes more
sense as a name for all the dynamic IPv6 addresses that the network
provides. But perhaps this means that it would be more clear if
create-address was renamed create-static, since create-address just
manipulates statically configured addresses?
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.
In that model, the only accepted dhcp option would be -i <interface name>
Is that a good (and extensible) start?
I think that is good for a start as long as we set the direction by
documenting that that manipulates the default dynamic address object for
that interface, and that there will/might be options down the road that
allows one to specify multiple/alternate dynamic address objects on an
interface.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
