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. > 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. > 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? 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. >> 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. --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
