I though I saw some email saying we should do a global replace of "intf"
with "if", which is a good idea.
> Note that
> applying a persistent change that relies on the result of a temporary command
> may fail with an error.
If we figure out how to handle missing objects, then we can remove that may.
For instance, if I do
dladm create-if -t bge0
dladm create-addr -i bge0 10.1.2.3/24
and then reboot it isn't much different than if bge0 goes missing (there
is a difference between the datalink bge0 being missing and the IP
interface being missing, but otherwise the same).
With today's kernel there will be a difference with -f inet/inet6 for
create-if, because we implicitly end up creating an ipif when we create
the ill.
But a future kernel might not do that. Hence the -f switch for *-if is
something we probably want to remove down the road.
Section 3.2 says that about delete-if that
All addresses configured on that interface will be torn down.
That sounds counter-intuitive given the "missing" handling.
Instead I think it makes sense to have delete-if return EBUSY if there
are addresses. (Later we can have a -F which forces the interface to go
missing even though there might be addresses that refer to it.)
I don't think the EBUSY changes usability, because I expect the manual
usage of ipadm would be around creating and deleting address objects.
Section 3.4:
Note that lo0 has different MTU for IPv4 and IPv6 today (so that 8k of
payload fits with the different IP+TCP header sizes.) I think we should
have the kernel move away from that, and until then ipadm somehow has to
paper over that difference.
Section 4.1. As I mentioned elsewhere, is the CIDR mask part of the name
of the object or not?
Thus can I do
ipadm create-addr -i bge0 10.1.2.3/24
followed by
ipadm delete-addr -i bge0 10.1.2.3
or do I need to specify /24 in the delete?
[We have a separate thread on hostnames for create-addr and friends.]
Section 4.4. I separately suggested show-addr output where the status
doesn't have the admin up/down flag, but instead shows the RFC 4293
address status.
If the current kernel doesn't have IFF_UP set on an address, then
representing that as the RFC 4293 notion of "invalid" would make sense.
Section 5.1:
I'd suggested s/*-v6addrs/*-ipv6addrs/ globally.
We need to decide whether the label is globally unique or unique per
interface, since that affects the set-addrprop and delete-ipv6addrs.
How will things work with the current kernel where I don't see to be
able to change the token and have that change the link-local address? Is
that a kernel CR that you will fix?
Section 6 talks about a set of addresses for DHCPv4, but AFAIK for any
given client-id/MAC address the server can only assign one address.
Section 6.2: Will show-addresss display all the address objects, or do I
have to do show-address, show-dhcp, show-ipv6addrs?
Section 7.
Instead of a "nolocal" property I suggest we name it "invalid". Or
perhaps not - read on ...
There is some overloading of IFF_ flags; ideally we'd like the kernel to
be able to have a separate notion of the status of an address and the
related onlink prefix. For instance, a duplicate address doesn't affect
the validity of the onlink prefix. But the prefix (in ND) can go invalid.
I don't know how far to take that separation. In its most extreme form
there would be a separate <verb>-prefix, but that seems like overkill in
the CLI. Note however that in.ndpd creates prefixes without associated
addresses, in which case they have IFF_NOLOCAL set and a zero address.
Thus it might make sense to have libipadm have <verb>-prefix functions
for ndpd to use.
In terms of show-addr things are a bit odd in that it pretends to show
addresses, but when NOLOCAL is set it is really an address-less prefix.
How do such things get reported by ifconfig in BSD?
How about including an "auto" in stateful = {true, false}. auto would
mean to do what the RA says, and would be the default. true would mean
to do in independently of what the RA says.
For symmetry having a stateless = {true, false} makes sense; if set as
false no addresses are configured from RAs (but DHCPv6 would run
independently.)
Section 8:
AFAICT an under interface can be added to a group in two ways:
ipadm add-ipmp -i under0 ipmp0
and
ipadm set-ifprop -p groupname=foo under0
Do those have identical semantics? For instance, what about the case
when under0 is already part of a group? (Do I get EBUSY, or do they
remove it from the existing group and then try to add to the specified
group?)
Note that doing a remove+add makes the failure semantics tricky. The
remove might succeed, and then the add could fail. Wouldn't you want to
add it back to the original group in that case? But that could also fail...
Thus EBUSY sounds like better semantics.
And perhaps we don't need to allow set-ifprop on the under.
Section 9.4. Let's not try to come up with arbitrary acronyms like
frag_to and fragment; too short names are necessarily helpful.
In section 9 I don't see how per-interface things like ip_forwarding is
set. Will that be done with ipadm set-ifprop?
It would be good to separate out non-interfaces (from an ACR
perspective). I believe section 9.3 falls in that category.
Section 11.2 talks about merging /etc/hostname* with ipadm peristent
configuration, and I frankly don't know what that means.
(It could be something complex e.g., detecting when /etc/hostname.bge0
changes from 10.1.2.3 to 10.9.9.9 and moving that change into ipadm, or
it could be something simpler.)
From looking at docs.sun.com with Renee a while back it seems like the
main (only?) documented use of /etc/hostname.<ifname> is various driver
docs which suggests adding an IP address to that file.
Things can potentially be added with an editor, or with
echo 10.1.2.3 >>/etc/hostname.bge0
If that is all we need to do we can do a few things:
1. If /etc/hostname*<ifname> doesn't exist or only contains comments, do
nothing (leave it in place).
2. If /etc/hostname*<ifname> contains something other than comments,
then take the non-comment stuff and propagate it to ipadm. (An issue is
what we do if this fails due to ipadm not supporting something like
modinsert.) Then replace the removed test with a comment that reads
something like
# This file has been obsoleted and its comments migrated to ipadm(1m)
Can we realistically do this migration now, or do we need to wait until
more of ifconfig is supported in dladm? (We'll always have things like
modinsert which isn't likely to be carried into ipadm.)
Erik
