[email protected] 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?
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.)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 thesemechanisms when we add routing options in ipadm later?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 _______________________________________________ networking-discuss mailing list [email protected]
