To summarize,
the model being proposed is
- ipadm create-interface will only create a "virtual object" with
no underlying plumbing done at the time..
- ipadm add-address will plumb as needed.
There are some aspects to consider here.
- Persistent property retrieval: in the existing design, this was
intended to be done after plumbing, as part of create-interface.
But if we move plumbing into "add-address", then the property
retrieval has to move to that piece either.
Possibly not a major issue, but something to keep in mind.
- IPv6: turnin gon ADDRCONF (and/or dhcpv6) Jim Carlson, Ken Powell and
I were just having a hallway conversation about various solutions
possible for this.. one interesting point that Jim brought up is
that the target of "add-address" should be the "address" and not the
interface (just as the target of 'dladm create-secobj' is the secobj).
If we go with that concept, then the last item on the *-address
sub-commands should be the address itself, with the link being
either an argument (e.g., -l), or embedded into the address argument.
Some examples that Jim and I discussed are desdribed below. Here the
"address" is identified as <interface>:<numeric tag>, so the interface
is embedded in the address. Eventually each of these commands should
support an alpha-numeric tag, but a starting point would be numeric tags..
# ipadm add-address -o ipv6-addrconf[,ipv6-intf-id = foo] link0
-> turn on ipv6 addrconf on the address link0:0 (i.e., the
0'th logical address on the link), with optional intf id foo
# ipadm modify-address -o no-ipv6-addrconf link0
-> turn off ipv6 addrconf on the default address link0:0
# ipadm modify-address -o dhcpv6 link0:1
turn on dhcpv6 on the address "link0:1"
IPv6 allows interesting possibilities like:
# ipadm modify-address -o flags=UP fe80::1%link0
Would it be worthwhile to extrapolate this for ipv4 as well? For example,
# ipadm modify-address -o flags=UP 10.20.30.40%link0
thoughts?
--Sowmini
