sowmini.varadhan at sun.com 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
