Date: Sat, 7 Mar 2009 10:15:27 -0500 From: David Horn <dhorn2000@gmail.com> To: Doug Barton <dougb@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Proposal: Rework ipv6 rtsol initialization in rc.d Message-ID: <25ff90d60903070715h72f00241v6e20c44e1769453@mail.gmail.com> In-Reply-To: <49B1AF12.2010302@FreeBSD.org> References: <25ff90d60903041057k2e8a469ej43734effd30fd3ff@mail.gmail.com> <49B1AF12.2010302@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 6, 2009 at 6:17 PM, Doug Barton <dougb@freebsd.org> wrote:
> David Horn wrote:
>> Proposal: =A0 Rework ipv6 rtsol initialization in rc.d
>
>> Why: =A0on 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_fl=
ags
- 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)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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: =A0There 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. =A0(Someone, please correct me if I am wrong
>> here, or if there is some other RFC that applies) =A0The multihomed
>> issue is more around IPv6 autoconfiguration in general, not specific
>> to soliciting for a router. =A0Since 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 alre=
ady
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 spec=
ific.
-Thanks in advance.
-_Dave
> hth,
>
> Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25ff90d60903070715h72f00241v6e20c44e1769453>