sowmini.varadhan at sun.com wrote:
> On (04/10/09 10:00), Erik Nordmark wrote:
>> 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.)
>
> Another thought that occurred to me is that what we really want
> for both IPv4 and IPv6 is a generalization of the ipv6 IAID- if we
> call this a "binding" (it could be the 4 byte IAID of dhcpv6, or
> the "logical interface name" of ipv4 or some mix of the client-id and
> ascii strings), then dhcpagent or in.ndpd could track the mapping
> between a set of dynamically managed addresses and the "binding name".
> The ipadm/libipadm interface would use the binding name as the
> interface to adddress this object.
I went and looked RFC3315 because I though the DUID would be sufficient
for DHCPv6, but it seems like the full name would have to be <DUID,
IA-type, IAID> plus the IP interface name. That ends up being quite
long. But if that can be unified with DHCPv4 client-IDs then at least
we'd have the full generality of a name space that can refer to the
identity. As long as the default (the DUID for DHCPv6, the IID for IPv6
stateless, and the DHCPv4 use of the MAC address as an ID) doesn't
require explicitly naming the object we could still have good CLI
usability and generality.
FWIW I think we should try really really hard to keep the logical
interface names out of the ipadm/libipadm APIs; they are unique to
solaris i.e. unfamiliar but also they don't seem to add much value if any.
>> create-ipv6 falls in the address management part of the interface.
>>
>> create-interface is the thing that sets up the phyint/ill, right?
>
> right, and sets up the autoconfigured link-local on it.
I thought you wanted interface management be separate from address
management, and if that is the goal it probably doesn't make sense to
even do link-locals as part of the interface management. Requires some
careful though at least.
>> Any other issues with making create-interface implicit in creating the
>> first address on the interface?
>
> We had a long discussion around this earlier.. one problem is that
> the plumb/unplumb logic is duplicated in several modules, not all
> of which are in Sun's control. So providing a "create-interface"
> that consolidates all this plumb/unplumb logic was the lesser evil
> here. The nwam case is another instance of these.
I don't have a problem with a libipadm create-interface to get those
benefits, but perhaps ipadm can do it implicitly? Why should the admin
doing things manually have to do N steps when the system can figure it
out that
ipadm create-address 1.2.3.4/24 bge0
means that the user wants bge0 to exist?
>>> 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 ;-)
>
> Ok, as long as we don't want to start pulling in rdisc as we sneak
> in pieces of ND and router-discovery.
Ah - I think I understand your point.
The fact that we start in.ndpd for IPv6 address management also has an
effect in routing since it also configures IPv6 (default) routes.
I think one could consider that a bug; we might want static IPv6
addresses and yet use in.ndpd for routing. So let's strive to make
routing and address management even more separate than they are today.
(We've talked about DHCPv4 adding a default route as another case where
one happens as a side-effect of enabling the other, and it makes sense
to strive to decouple that as well.)
So architecturally we want to keep/make address management separate from
routing.
Erik
