netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gilles Quillard <gilles.quillard@bull.net>
To: netdev@oss.sgi.com, linux-ipv6@list.f00f.org
Cc: Gerrit Huizenga <gh@us.ibm.com>, Tony Reix <Tony.Reix@bull.net>
Subject: support of IPv6 by NFS
Date: Tue, 01 Mar 2005 11:10:21 +0100	[thread overview]
Message-ID: <42243F8D.5030302@bull.net> (raw)

I'm working on the support of IPv6 by NFS and the RPC on Linux.

As now preconized for the developing of new networking applications, I 
have developed a prototype implementation on which I have migrated all 
the NFS / RPC kernel stack and the user commands to use IPv6 addresses. 
The IPv4-mapping mechanism is used to assume the backward compatibility 
for IPv4 addresses which are still the most used.
This works but this needs that the kernel has been compiled with IPv6, 
which is not mandotary. A lot of people in the Linux community do not 
have experience with IPv6 yet and are not ready to use it. So making it 
mandatory for NFS, even in a pure IPv4 network, is not easy.
It seems that the most of the major distributions already provide 
default kernel built with IPv6, but the reference on kernel.org is still 
providing with the IPv6 support not set; and there are some 
unwillingness to make mandatory the compilation of the kernel with IPv6 
to support NFS.

The problem is not specific to NFS, any networking application written 
using IPv6 mechanisms for both IPv4 and IPv6 addresses (AF_INET6 socket 
opened, IPv4 addresses mapped) couldn't work without a kernel built with 
IPv6.

Are the final users really against the use of kernels built with IPv6 ?
What is preconized on Linux for the support of IPv6 ? The solution 
described above or the cohabitation of the two modes (struct sockaddr or 
sockaddr_storage used to contain either struct sockaddr_in or struct 
sockaddr_in6) with specific processing according to the family of the 
addresses ?

Regards,
Gilles

             reply	other threads:[~2005-03-01 10:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-01 10:10 Gilles Quillard [this message]
2005-03-01 13:44 ` support of IPv6 by NFS Quantum Scientific
2005-03-01 15:08   ` (usagi-users 03222) " Jeroen Massar
2005-03-01 16:19     ` Olaf Kirch
2005-03-01 17:18       ` Jeroen Massar
2005-03-01 18:39       ` (usagi-users 03224) " Rémi Denis-Courmont
2005-03-01 18:56     ` (usagi-users 03222) " Quantum Scientific
2005-03-01 19:46       ` Jeroen Massar
2005-03-01 21:37       ` (usagi-users 03226) " Elliott Mitchell
2005-03-06 11:04     ` (usagi-users 03222) " Harald Welte
2005-03-06 15:40       ` (usagi-users 03249) " Jeroen Massar
2005-03-01 15:19   ` (usagi-users 03222) " YOSHIFUJI Hideaki / 吉藤英明
2005-03-01 16:35   ` Rémi Denis-Courmont
2005-03-06 11:02   ` Harald Welte
2005-03-01 15:42 ` YOSHIFUJI Hideaki / 吉藤英明

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42243F8D.5030302@bull.net \
    --to=gilles.quillard@bull.net \
    --cc=Tony.Reix@bull.net \
    --cc=gh@us.ibm.com \
    --cc=linux-ipv6@list.f00f.org \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).