On Fri, Mar 6, 2009 at 6:17 PM, Doug Barton <do...@freebsd.org> wrote: > David Horn wrote: >> Proposal: Rework ipv6 rtsol initialization in rc.d > >> Why: on multihomed or transient (e.g. laptops) connections, ipv6 >> autoconfiguration can be slow, causing ipv6 initialization delays >> while waiting for unsolicited router advertisements > > I don't quite understand this problem statement. Can you flesh it out > a bit? >
Apologies, I was a bit too brief. Here is a better set of descriptions for the two issues: - (1) Slow ipv6 initialization after link state changes - (2) Multihomed ipv6 rtsol initialization at boot Issue (1) IPv6 can be slow to initialize if link changes state in a single interface environment, and is not UP during boot. Example (1) Boot laptop, but no net interface UP during boot. (e.g. wifi out of range, Ethernet cable unplugged, etc.) and ipv6_enable rcvar is "YES". When link state does go UP, IPv4 initializes immediately due to dhclient being called from devd (in either 802.11 or Ethernet situations) e.g. /etc/devd.conf relevant lines: media-type "ethernet"; action "/etc/rc.d/dhclient start $subsystem"; media-type "802.11"; action "/etc/rc.d/dhclient start $subsystem"; IPv6 RA may be received either immediately (if you are lucky), or after upto a 10 minute wait depending on timing. The leaves the link in an indeterminate state for a random (0 seconds to 600 seconds) period of time for IPv6 connectivity. The solution is clearly spelled out in RFC 2461 (6.3.7): <SNIPPET of RFC 2461> 6.3.7. Sending Router Solicitations When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Router Advertisement to locate default routers or learn prefixes. To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. - The host attaches to a link for the first time. - The host re-attaches to a link after being detached for some time. </SNIPPET of RFC 2461> Proposal (1) - Try to get IPv6 initialization timing to ~ parity with IPv4 initialization by calling rtsol at same or similar times as dhclient is being called. - Create /etc/rc.d/rtsol script that checks for disabled ipv6, and other rc.conf vars then calls /sbin/rtsol e.g. ipv6_enabled rcvar and ipv6_network_interfaces rcvar, rtsol_flags - Add devd.conf action lines for new /etc/rc.d/rtsol script for both Ethernet and 802.11 types - I *think* devd.conf entries are preferable to running rtsold in the background having it watch for link-up events. - This also applies to situations like roaming wi-fi, and devd should do nicely here, and should allow seemlessly moving from one ipv6 prefix to another (in the case where one 802.11 AP is on one /64 prefix, and a different 802.11 AP may be on another /64 prefix) =================================================================== Issue (2): In a multihomed network interface environment, rtsol will only be called on the first interface in the list during boot sequence due to a perception that there *may* be problems. See network.subr in network6_interface_setup(), specifically "rtsol $1" and comments rather than "rtsol $rtsol_interfaces" Example (2): Laptop has both Ethernet and WiFi network interfaces, and appropriate rc.conf entries to make them both attempt to start at boot, and ipv6_enable rcvar is "YES". In my case, this would be bfe0 and iwn0 (realy wlan0 in -current, as iwn0 can not be used). Ethernet cable is disconnected, but wifi does succeed in connecting. ifconfig -l returns bfe0 in the list before wlan0, so rtsol is called on the non-connected interface, but never called on wlan0. dhclient is called on wlan0 properly however, so ipv4 initializes quickly, and ipv6 can take some time (0 - 600 seconds). Proposal (2): Investigate in what cases it would be acceptable and prudent to initialize all potential ipv6 interface (e.g. $rtsol_interfaces). /sbin/rtsol already works properly if called with multiple interfaces. >> What: add devd.conf entries, create /etc/rc.d/rtsol script (ala >> dhclient script), modify network.subr, update man 5 rtsol > > This sounds like a significant change so I would like to see a > thorough justification for it before it goes in, and it will need > thorough testing to make sure that there are no regressions. > I absolutely agree. This will need to be thoroughly tested. >> Discussion point: There is a comment in network.subr, and in man 5 >> rtsol about multihomed connections not being appropriate for rtsol >> >> I read through RFC 2461 and 2462, and while it does list multihomed >> issues in appendix A of RFC 2461, it does not have any "MUST NOT" or >> "SHOULD NOT" language around router solicitations with respect to >> multihomed ipv6 systems. (Someone, please correct me if I am wrong >> here, or if there is some other RFC that applies) The multihomed >> issue is more around IPv6 autoconfiguration in general, not specific >> to soliciting for a router. Since FreeBSD already allows for IPv6 >> autoconfiguration on multihomed ipv6 systems (just without calling >> rtsol on multiple interfaces), I would think that this is really a >> non-issue for rtsol. > > My main concern would be making sure that the routing issues > (particularly default routes for the various interfaces) don't end up > with regressions. In general I agree with the concern that RA isn't > really designed for use in a multihomed environment. That said, there > aren't really any good multihome solutions in any case, so as long as > this doesn't break anything I'm not opposed to giving it a go. > > I need to do some more investigation, but from what I can tell FreeBSD already works in multihomed IPv6 RA environment, there is just the issue of waiting for an RA, or soliciting via rtsol. I also need to look at this on 7.1-STABLE just to make sure that some of the things I am seeing are not -CURRENT specific. -Thanks in advance. -_Dave > hth, > > Doug _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"