sowmini.varadhan at sun.com wrote:
> yes, and also some kernel rewhacking, because an
> "ifconfig link0 inet6 plumb" today will set up the link-local.
Yes. Perhaps it should come up as a zero address (but ill_token is set),
and if one does an IFF_UP then the token is taken to form the
link-local. (I think we have a bug today in that ifconfig token can
change the IID, but doesn't change the IID used by the link-local address.)
> That behavior makes sense if you consider that an ipv6 interface *must*
> have at least one link-local address, and the current assumption in
> the kernel is that the default link-local address is the one obtained
> by autoconfig.
But does that still hold if we want to allow multiple IPv6 identities in
the form of multiple IIDs on an interface?
In that case the admin would have to type something to the CLI to create
the second IID. Wouldn't it be odd that the first IID is implicitly
created and impossible to destroy?
>> 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?
>
> that would work, but the question remains: what does the function
> libipadm`ipadm_create_interface() do for the link-local. One choice
> is that we can make the default behavior to be that the link-local is
> the autoconfigured one, unless a static link-local is provided as the
> argument to ipadm_create_interface().
My choice would be nothing; the address is zero just as for IPv4.
ipadm_create_dynamic_address() for IPv6 would configure a link-local,
bring it up, which will trigger in.ndpd to do its think. If we take the
kernel approach above all that would need to do is set IFF_UP and the
rest will happen.
Erikj
