On Jan 30, 2009, at Jan 30, 2009, 4:59 PM, Trond Myklebust wrote:
On Fri, 2009-01-30 at 16:30 -0500, Chuck Lever wrote:
Yes and no. I thought the motivation for doing what you currently
do
was
to avoid mixing AF_INET and AF_INET6 sockets, since the latter
listen on
both IPv4 (via the IPv4 mapping) and IPv6?
AF_INET6 listeners can receive AF_INET packets too, but don't have
to. My motivation was to use a single listener so we don't have to
support multiple family listeners for each transport protocol in the
server-side code. Also, having a separate IPv6-only listener means
that someone can come along and hijack the IPv4 packets on that port.
It's just less of a headache with one listener.
The ipv6 manpage says that the port spaces are shared. If so, I don't
see how you can have both an AF_INET socket and an AF_INET6 socket
bound
to the same port.
I've been told that the IPV6_V6ONLY socket option modulates this
behavior. If it's set, then the port spaces are separate.
The question is how to deal with mapped IPv4 traffic. if IPV6_V6ONLY
is set, then what happens to mapped IPv4 traffic?
If so, it sounds to me as if
we _must_ have lockd and the callback server set up IPv6 sockets
whenever they are available.
That's what the code does now. The problem is exactly what does
"whenever they are available" mean?
Are you suggesting we shouldn't ever fall back to AF_INET? (I'm OK
with that answer, but would like a discussion). This means that if I
try an IPv4 mount on a system built with an IPv6 module, but the
module is unloadable, all mounts (even IPv4) fail outright.
Apparently a lot of folks blacklist their IPv6 modules.
I'd rather advocate that we try to use AF_INET6 at service set up
time,
then fall back on AF_INET only if the former isn't available. I'm not
sure that we should allow the user to change the service once it has
been set up, since it would appear that would force you to close the
current socket, and then reopen a new one of a different type. That's
both racy and constitutes an interruption of service.
The listeners will pin the ipv6 module while they exist. At some
point, if the listeners are stopped, the ipv6 module can be
blacklisted. Subsequent NFS mounts will fail at that point, but a
reboot (or perhaps unloading the lockd and nfs modules) will make it
right again.
Seems like a good argument for separate listeners.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
