We (Brussels team and some of the design reviewers) have been having
some detailed offline discussions about how to formulate the *addr set
of functions, and I thought it might be good to summarize some of these
discussions.. we want all of the following:
- the interface is intuitive and not encumbered with implementation
details (like the fact that we have separate kernel data structures
for ipv4 and ipv6 interfaces),
- *addr interfaces have the address itself as the target of the command
- allows value-add features such as the tuning of dhcp parameters of
addresses acquired by dhcp where multiple dhcp addresses can live on the
same physical interface.
All this has to be done without requiring immediate rehaul of the kernel
data-structures themselves.
Some day in the future we may change the naming scheme for "logical
interfaces" or IP addresses. If we do this, then we want minimum/no
impact to the CLI.
During address creation, we have enough context that we can hide
the implementation details such as V4/V6 interface structures inside libipadm.
However, once an address is created, we don't want the API for commands
that set address properties (such as source address selection flags)
to be cluttered with 3 specifications necessary to uniquely identify an
interface-address: IP version, interface, and logicaly interface number.
In most cases, an address can be uniquely identified by specifying
the (<interface>,<address>) tuple. e.g., (net0, 10.1.2.3). Having an
(interface, address) tuple as the target of a command like create-addr
is also more intuitive to an administrator.
The cases that prove problematic today are
1. duplicate addresses: today Solaris has a "feature" whereby, if I
add A.B.C.D to link0, and A.B.C.D is already up and configured on
link1, then the the duplicate address (on link0) is configured,
but not marked UP, and the ifconfig command itself returns
"Address not available". This is arguably a bug. If the attempt
to add the address fails, the state of link0 should be left unchanged,
including *not* adding an address at all. (See CR 6777155)
2. Dynamic addresses like dhcp/ND: in the case of dhcp, the "<address>" is
not a constant, and is dynamically determined by dhcp. In fact, in
the case of dhcp, one does not add an address itself, but rather
adds an address slot (called "binding" in IOS/JunOS).
Problem #1 can be fixed by fixing the buggy behavior itself. If there
are no duplicate addresses, then (intf,addr) should uniquely identify
static addresses.
Problem #2: dynamic addresses such as those configured by ND and dhcpv6
are handled (along with the rest of the stateless/stateful addrconf specs)
as part of ndpd.conf today. For IPv4 dhcp, the "create-address"
command is inappropriate, and does not fit. A better approach
would be something like
# ipadm create-dhcpc-binding -i link4 <..> <binding>
where <binding> could be a specification like bge0:1 (or, in the future,
bge0:dhcp1). Then one could target dhcp operations on the binding by
using commands like
# ipadm modify-dhcpc-binding -wait=<wait time> <binding>
and view dhcp status thus
# ipadm show-dhcpc-binding <binding>
Note that JunOS has an interesting 'show dhcp binding' command in
http://tinyurl.com/d6kass. Both IOS and Linux's 'dhcclient' seem
pretty constrained on what they support on the client-side, so the above
proposal is at least as powerful as these other administrative models.
Thoughts?
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
