[email protected] wrote:
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.
Agreed.
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).
There is also problem 2.5 which is that for IPv6 dynamic address
allocation (whether stateless, DHCPv6, or both combined) the RAs and
DHCP responses can give the host multiple addresses.
Trying to associate those with a name (like bge0:1) isn't helpful and
would be harmful.
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.
And as long as the duplicate down addresses are on different interfaces
it wouldn't be a problem at all.
Furthermore, when using ipadm I wouldn't expect to promulgate the old
sins of an address being up or down; if ipadm fails to add an address,
then this should result in no change to the set of addresses known to
the kernel.
Of course, using ifconfig one could still add an address without setting
IFF_UP, so having the kernel do something more sane than today would be
useful.
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.
Is <binding> above a character string name or something else?
I think what we'd want for dynamic address assignment is the ability to
manage the identities in ipadm, with the default identity being the MAC
address. Then in the future we can add the ability to specify different
DHCPv4 identities (client IDs?) on the command line, as well as multiple
IPv6 tokens and/or DUIDs for IPv6.
Thus the full fledged syntax might be something like
ipadm create-dhcpv4 -i link4 [-c clientID]
where the lack of a -c means that refers to the single identity which is
the MAC address on link4. So 'ipadm destroy-dhcpv4 -i link4' would
destroy that default one.
It isn't clear whether we want to treat stateless and DHCPv6 as separate
or a union; the protocols are coupled together, but stateless using a
token derived from the MAC address, and the DUID being quite different.
A separate one could be
ipadm create-dhcpv6 -i link6 [-c DUID]
ipadm create-slac -i link6 [-t token]
and a combined one could be of the form
ipadm create-ipv6 -i link6 [-c DUID] [-t token]
The name of these objects are of the form <link, id> the same way the
static address objects are of the form <link, address>. For instance, my
laptop would show a dhcpv4 name for <ath0, 0:21:5d:96:26:fa>.
If we think this is sensible, and we don't need to support bge0:17
DHCPv4 configuration using ipadm from day one, the initial support is
just for
ipadm create-dhcpv4 -i link
ipadm destroy-dhcpv4 -i link
ipadm create-ipv6 -i link
ipadm destroy-ipv6 -i link
thus we can add the options later.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
