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