On (04/27/09 22:35), Erik Nordmark wrote:
>>
>>> I suspect the kernel needs some work before we fully endorse the
>>> disable-address. For instance, today IPv6 assumes that the link-local
>>> lives on :0, but what happens when :0 is disabled? (I guess some
>>> kernel code just blasts along using that disabled address.)
>>
>> today the kernel just disables all the ipv6 addresses - in.ndpd
>> notices that the link-local disappeard and takes down the all
>> the autoconfigured addrs... we should
>> retain that behavior
>
> Good. But that only handles the case of autoconfigured IPv6 addresses.
>
> If I statically assign a link local to bge0 and a global to bge0:1, and
> then ifconfig bge0 inet6 down, how does the system good.
If I do
# ifconfig bge0 inet6 plumb fe80::1234/10 up
and, after the onlink prefix gets autoconfigured, if I do
# ifconfig bge0 inet6 down
I'm left with a global prefix on bge0, but no link-local (and that behavior
is true even if the link-local is generated from the token).
But (and to summarise a discussion I had with Erik earlier this week)
there is a fundamental problem here, with having the 0'th address and
the interface ("ill") have the same name-space, while all other addresses
are free-floating objects. Here's why-
Even if we fix the routing socket messages so that address
addtion/deletion is exclusively reported as NEWADDR/DELADDR,
and the RTM_IFINFO is generated only when the ill->ill_ipif_up_count
goes to 0, there is still a a problem:
an application that does a GLIFFLAGS on net0 may incorrectly decide
that the interface is down because the 0'th ipif is down. To correctly
figure out the up/down status of the interface, it *has* to get all
the ipifs on the interface and then determine the status.
And we can't really suppress ~IFF_UP addresses from GLIFCONF output
easily because then we may end up suppressing the information for
net0 itself, and thereby confusing applications that see net0:1, net0:2
etc, but no net0 itself.
Another problem arises from the fact that both through ipadm and
ifconfig, we allow the removal (i.e. deletion) of non-zero addresses
("logical interfaces"), but the only way to remove the 0'th address is
by unplumbing. Thus, for example, with ipadm, I can create the first
(0'th, in today's nevada model) address as a static address, and then
get the next address via dhcp (say). Now if I did "ipadm delete-addr.."
to delete the static address, I risk tearing down all the dhcp
addresses as well.
so if we want to make the distinction between "delete" and "disable"
for an address, the 0'th address becomes problematic.
The 0'th logical interface has become "special" because of the
implementation details around logical interfaces - it's used as the
anchor for the ipsq, and there are other places in the kernel which
have a deeply embedded assumption that at least one ipif exists on any
plumbed ill. But we are trying to hide such details from user-space
system calls.
One way to make all logical interfaces to be equivalent (i.e.,
0'th IP address is not a "special"): we could modify the ill/ipif
layout so that the first ipif is just an anchor ipif to track the ill
status itself. E.g., the anchor ipif could have INADDR_ANY or the ::
address (note that we already do this for ipmp test interfaces, and
dhcpagent also does this as a precursor to starting dhcp, though ipv6
will need some tweaking, to avoid making the assumption like '0'th
interface is always the link-local'). Another option is to store the
AF_LINK as the 0'th "anchor" ipif- if this was displayed in 'ifconfig
-a' then it would be more informational (and, fwiw, in line with output
from bsd/linux).
But then the issue is- if we report the 0.0.0.0 address or AF_LINK
in GLIFCONF, will that create confusion for existing legacy apps that
parse this ioctl? There's some history of confusion here:
http://www.mail-archive.com/[email protected]/msg06196.html
which makes this look risky. If we make this an AF_LINK, then
any application which parses the output of GLIFCONF as
for (i = 0; i < num; i++, lifrp++) {
:
if (lifrp->lifr_addr.ss_family == AF_INET) {
/* .. */
} else {
/* .. */
}
}
will be in trouble (yes, they should be more robust, but the above example
was lifted from ON itself without much searching :-().
Thoughts?
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
