On (04/10/09 16:44), James Carlson wrote: > > Erik Nordmark writes: > > [email protected] wrote: > > > 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. > > In the current DHCP implementation, we use the ifIndex number as the > IAID for the base interface when possible, but we keep stable storage > so that we never use the same interface name with a different IAID, > and we use an arbitrary number when it's a non-zero logical interface. > > The DUID is LLT if possible, otherwise we use the UUID library to > generate an arbitrary one. > > The bottom line is that the existing implementation allows you to set > these values if you really, really want to (see the DHCPv6 PSARC case > for details on how to do that), but you almost never really want to do > that. > > > That ends up being quite > > long. > > Interface name should work fine. That's what we use for IAID storage.
from libipadm's point of view, it would be better if we didn't make any assumptions about what the IAID is (so that we don't constrain how this could be extended in the future). Besides, we already have a back-end process (dhcpagent, in.ndpd) that actually brokers with the dhcpserver, and knows about the various options supported by the prototcol. So how about the following ipadm create-dhc4 <dhcpv4 options> <binding> ipadm create-dhc6 <dhcpv6 options> <binding> where the options would contain things like -l <interface>, -i <iaid> -d <duid> etc. relevant to each protocol, and <binding> can be an ascii string that dhcpagent maps to the unique set of parameters identifying the dhcp address-object. > > 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. > > The current system doesn't require you to specify any of that, just > the interface name. In that model, the only accepted dhcp option would be -i <interface name> Is that a good (and extensible) start? --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
