On (04/08/09 15:42), Erik Nordmark wrote: >> 2. Dynamic addresses like dhcp/ND: in the case of dhcp, the "<address>" is >> not a constant, and is dynamically determined by dhcp. In fact, in >> the case of dhcp, one does not add an address itself, but rather >> adds an address slot (called "binding" in IOS/JunOS). > > There is also problem 2.5 which is that for IPv6 dynamic address > allocation (whether stateless, DHCPv6, or both combined) the RAs and > DHCP responses can give the host multiple addresses. > > Trying to associate those with a name (like bge0:1) isn't helpful and > would be harmful.
true. >> Problem #1 can be fixed by fixing the buggy behavior itself. If there >> are no duplicate addresses, then (intf,addr) should uniquely identify >> static addresses. : > Of course, using ifconfig one could still add an address without setting > IFF_UP, so having the kernel do something more sane than today would be > useful. yes, we were planning on sanitizing the kernel behavior itself, so that you would minimally not be allowed to add duplicate (but not UP) addresses on the same physical interface. >> Problem #2: dynamic addresses such as those configured by ND and dhcpv6 >> are handled (along with the rest of the stateless/stateful addrconf specs) >> as part of ndpd.conf today. For IPv4 dhcp, the "create-address" >> command is inappropriate, and does not fit. A better approach would be >> something like >> # ipadm create-dhcpc-binding -i link4 <..> <binding> where >> <binding> could be a specification like bge0:1 (or, in the future, >> bge0:dhcp1). Then one could target dhcp operations on the binding by >> using commands like # ipadm modify-dhcpc-binding -wait=<wait time> >> <binding> >> >> and view dhcp status thus >> # ipadm show-dhcpc-binding <binding> >> Note that JunOS has an interesting 'show dhcp binding' command in >> http://tinyurl.com/d6kass. Both IOS and Linux's 'dhcclient' seem >> pretty constrained on what they support on the client-side, so the above >> proposal is at least as powerful as these other administrative models. > > Is <binding> above a character string name or something else? I was thinking of it as a logical interface, but as you point out, that won't work for dhcpv6. > 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? > 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? 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? --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
