sowmini.varadhan at sun.com wrote:
>> 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.
>
> Would the usage of client-ID as the "binding" cover all cases?
You need to handle the default case of no DHCPv4 client-ID and just the
MAC address as the ID. I suspect one can represent this as a single
thing which can be either a binary MAC address, or a client-ID (which
might be ASCII?)
Note that IPv6 and DHCPv6 use (at least) different terminology in that
the MAC address corresponds to an 64-bit IPv6 token (or interface-ID)
[which by default is derived from the MAC address], and the DHCPv4
client-ID conceptually corresponds to the DUID (but the DUID has a type
field and comes in different types; not just a sequence of bytes like
the client-ID.)
>> 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.
>
> I'm not sure I see what create-ipv6/destroy-ipv6 do, and how they
> would be differnt from what create-interface would do?
create-ipv6 falls in the address management part of the interface.
create-interface is the thing that sets up the phyint/ill, right?
You've specified those as different, and in that case, just like we need
create-dhcpv6 for address management we need create-<something> for
non-static IPv6 address management.
It might be that the interface can be simplified to remove the
create-interface all together, and having it be implicit in the first
address management on the link.
That would work well for the normal cases of configuring static or
dynamic addresses, but it might have issues with the NWAM-type usage
where one wants to plumb bge0 just to be able to see the state of
IFF_RUNNING (I'm guessing that is what NWAM does, but it could also use
DLPI to look for DL_NOTE_LINK_UP/DOWN.)
Any other issues with making create-interface implicit in creating the
first address on the interface?
> also, as you point out, stateless and dhcpv6 are coupled together,
> and in.ndpd is the configuration method here, much like in.routed
> manages rdisc today, so wouldn't it be better to deal with all these
> mechanisms when we add routing options in ipadm later?
I don't understand what IPv6 address management has to to with routing
(any more than IPv4 address management having something to do with routing.)
No, I don't think you can punt on IPv6 address management and just do
IPv4 if that was the question ;-)
Erik
