On Fri, 2009-04-10 at 13:26 -0700, Erik Nordmark wrote: > Sebastien Roy wrote: > > > My take on this is that create-interface is sufficient for all > > autoconfigured IPv6 address management. By default, when an IP > > interface is created, a link-local IPv6 address is implicitly created on > > that interface and autoconfigured IPv6 addresses are managed by in.ndpd > > automatically when that link-local address is brought up. With "IPv6 on > > by default" (which naturally falls out of this design), there should be > > no need to explicitly do anything to "enable" the autoconfiguration of > > any IPv6 addresses. There should, however, be a way to turn it off, > > perhaps using an interface property. > > First of all I think that the model must be uniform across IPv4 and > IPv6, so the above would only make sense if DHCPv4 was implicit and > always there.
Okay, that's fine. Uniformity is a valid goal. > If we think there is utility in separating interface management from > address management (Do we? Your question implies that we might not want > to keep them separate) then having the ability to ask libipadm to create > an interface without any addresses would make sense. Yes, there is utility in this. My statement was meant to suggest that some aspects of address management could potentially occur without explicit configuration. If that doesn't fit the model we're going for, then that's fine. > Note that the CLI can still do implicit interface creation so that > ipadm create-ipv6 bge0 > is all that is needed to get interface created (if it didn't already > exist) and the link locals, SLAAC, and DHCPv6 addresses in place. > > But if the CLI and/or library is unable to create an interface without > creating IP address(es) on that interface then I think the abstraction > is incomplete, and we might find that an obstacle as the system evolves. Okay. > > If the user wants to do things like use a non-default interface-ID, then > > I think that should also be an interface property. > > While it might be expedient to shuffle all the unusual things into a > property, I think it would be a mistake in this case. What is key to any > system is how the objects are named, so that we can have operations on > those objects. And I don't think it makes sense having different part of > the name live in properties, nor do I think we should carry the logical > interface name forward since it can't handle multiple (IPv6) addresses > being associated with a single address object. For static IP addresses > the tuple <IP interface, IP address> is sufficient to name the address > object. For dynamic ones we need something different. Good points. Note that I agree that "logical interface" as an administrative object should not be carried forward. Also, once an address has been created by whatever means, I don't see why <IP interface, IP address> wouldn't be sufficient to identify it (even dynamically created ones). -Seb _______________________________________________ networking-discuss mailing list [email protected]
