On (04/10/09 20:38), Erik Nordmark wrote:
>> 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
in both cases, you would have to specify the binding explicitly
(without getting too pedantic, the current convention, as Jim and
Meem frequently remind me, is that the verb-object syntax is supposed
to have the "object" as the target. In this case, the object would be a
binding name). If we wanted to destroy all dhcp bindings on the
interface, we could have support for a "-all" flag
> 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.
So I would propose
ipadm create-dhcpv[4,6] [..] <binding>
ipadm destroy-dhcpv[4,6] [..] <-all | <binding>>
thus the object is the binding (with -all as a shortcut for all bindings).
> 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.
Ok.
> 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?
To recap, since this discussion has gone to many places/threads,
I think we currently have (listed with examples for readability)
For both ipv4/ipv6
ipadm set-addrprop [-p [addr params like src addr selection]] link0/fe80::1
ipadm get-addrprop [-p ..] link0/10.1.2.3
ipadm set-intfprop [-p .. ] link0 # ndd props and alsothings like ip mtu etc.
ipadm get-intfprop [-p ..] link0
For IPv4:
ipadm create-addr link0/10.1.2.3
ipadm delete-addr link0/10.1.2.3
ipadm create-dhcp4 -i link0 [other dhcpv4 options] mydhcgrp4
ipadm delete-dhcp4 [-all | mydhcgrp4]
libipadm`ipadm_create_interface() to plumb the interface with 0.0.0.0
For IPv6
ipadm create-dhcp6 -i link0 [other dhcpv6 options] mydhcgrp6
ipadm delete-dhcp6 [-all | mydhcgrp6]
(Should we just have one create-dhcp that takes a -f?)
Static/autoconf IPv6 addresses are still under discussion. In theory,
the *-addr commands above should continue to just be usable for static IPv6.
(The context of the address would tell us if ipv4 or ipv6 was implied,
except when dns was invoked, e.g., ipadm create-addr link0/myhost.com,
for which case we can have a -f flag, or some clearly defined
defaults).
Autoconf: we could have a new command, as Erik suggested in another
thread. Or try to squeeze it into the create-addr commands.
Here's a somewhat radical thought for v6-autoconf: it's not supposed to
need configuration (or, at least, it needs minimal configuration). So
why not treat it as interface property:
ipadm set-intfprop -p ip6_token=<..> link0
ipadm set-intfprop -p enable-ipv6=true link0
Does that have potential/appeal?
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
