* IPv6 support
@ 2009-11-02 8:20 Suresh Jayaraman
2009-11-02 16:40 ` Chuck Lever
0 siblings, 1 reply; 10+ messages in thread
From: Suresh Jayaraman @ 2009-11-02 8:20 UTC (permalink / raw)
To: Chuck Lever; +Cc: Linux NFS mailing list
Hi Chuck et al,
Thanks for all the excellent work on IPv6 support. There have been
considerable amount of development that has been happening recently.
However, it's not very clear what are the missing pieces or open
problems (if any).
>From what I understand, the current status is (CMIW):
+ kernel support
- client side and server (kernel pieces) are almost there and the
missing pieces are expected to get in by 2.6.32.
+ userspace support
- nfsd support has already been added but disabled temporarily till
we get statd and mountd IPv6 aware.
- making statd IPv6 aware is currently under development/review.
- mount.nfs changes - done?
- rpc.mountd, exportfs changes - TBD.
Is the above information correct? How far we are from getting full IPv6
support?
Thanks,
--
Suresh Jayaraman
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: IPv6 support 2009-11-02 8:20 IPv6 support Suresh Jayaraman @ 2009-11-02 16:40 ` Chuck Lever 2009-11-02 20:43 ` Jeff Layton ` (3 more replies) 0 siblings, 4 replies; 10+ messages in thread From: Chuck Lever @ 2009-11-02 16:40 UTC (permalink / raw) To: Suresh Jayaraman; +Cc: Linux NFS Mailing list, Chris Mason On Nov 2, 2009, at 3:20 AM, Suresh Jayaraman wrote: > Hi Chuck et al, > > Thanks for all the excellent work on IPv6 support. There have been > considerable amount of development that has been happening recently. > However, it's not very clear what are the missing pieces or open > problems (if any). There's a working document on the linux-nfs.org wiki that has a full list, but I can't seem to get to linux-nfs.org right now. > From what I understand, the current status is (CMIW): > > + kernel support > - client side and server (kernel pieces) are almost there and the > missing pieces are expected to get in by 2.6.32. The client-side implementation of IPv6 in the kernel is usable. There's been a request for the proto= mount option to accept netids instead of protocol names, and that's still pending. Otherwise, you can pass an IPv6 address to the kernel and it will do the right thing. NFSv4 is pretty much working now, NFSv2/v3 still needs the IPv6-aware statd. We've tested against NetApp and Solaris NFS servers. Server side in the kernel is nearly done. There are a handful of small patches outstanding. Until I have mountd working, there's no way to test the server side pieces thoroughly. So for now, "completion" of the server side is some time in the future. > + userspace support > - nfsd support has already been added but disabled temporarily till > we get statd and mountd IPv6 aware. > - making statd IPv6 aware is currently under development/review. Basic support is code complete and has seen some testing. We're waiting for upstream NFS maintainers to review the latest patch series. > - mount.nfs changes - done? The netid changes mentioned above will require some mount.nfs support, which is in the works. 2.6.33, maybe? > - rpc.mountd, exportfs changes - TBD. These are the next step. This is going to be a fairly heavy-weight change -- mountd and exportfs internals are unsuited for internationalized domain names, IPv6, and mixed IPv4/IPv6 environments, and will need to be replaced. There is also the gssd twins. Jeff has fixed up at least one of them. I think we've reviewed the kerberos libraries and determined that they are IPv6-aware, but that could be incorrect. TCP wrappers are definitely not IPv6-aware. rpcbind and libtirpc are also prerequisites, but there are few distributions I know of that have replaced portmapper with rpcbind. > How far we are from getting full IPv6 support? The short answer is mountd/exportfs will take about six months. The client side is close enough that I think we can promise basic IPv6 support for upcoming enterprise releases. We're also thinking the kernel work on the server is close enough that few or no kABI changes will be needed once mountd is working, but that's just a guess. The long answer depends on your definition of "full". :-) Does that include complete support for link-local IPv6 addresses? Does that include full support for netids in the kernel? Does that include complete multi-homed host support in lockd and statd? Does that include full support for internationalized domain names? Does that include IPv6 netgroup support? Does it include IPv6 support in TCP wrappers? Does it include support for systems that have no IPv4 addresses (not even loopback)? There are a bunch of details that still need to be worked through. I've only been able to guess at what features are required, and which can be implemented at a later time. What I would dearly love to have is a list of specific features that folks feel is a baseline (based on actual data, of course). Unfortunately there are very few Linux customers who have deployed IPv6 and an IPv6-capable NFS implementation (like Solaris) and can tell us what they would need on Linux. Plus, most distributions don't have fluent user space infrastructure for IPv6 yet. NetworkManager is one area that may need work. The Network Administration tool in Fedora is still IPv4-centric, iirc. We don't have firewall admin tools that handle IPv6 rules. Unlike IPv4, admins can (and often do) use IPv6-aware kernels without ipv6.ko, so all of our tools and support have to be careful about using IPv6 when the O/S may not support it. This is different than IPv4, which is nearly always available. In other words, system support for IPv6 outside of NFS is kind of like wireless was 5 years ago -- innumerable small admin tools that users had to integrate themselves, usually without much success. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: IPv6 support 2009-11-02 16:40 ` Chuck Lever @ 2009-11-02 20:43 ` Jeff Layton 2009-11-05 11:49 ` Suresh Jayaraman ` (2 subsequent siblings) 3 siblings, 0 replies; 10+ messages in thread From: Jeff Layton @ 2009-11-02 20:43 UTC (permalink / raw) To: Chuck Lever; +Cc: Suresh Jayaraman, Linux NFS Mailing list, Chris Mason On Mon, 2 Nov 2009 11:40:47 -0500 Chuck Lever <chuck.lever@oracle.com> wrote: > > There is also the gssd twins. Jeff has fixed up at least one of > them. I think we've reviewed the kerberos libraries and determined > that they are IPv6-aware, but that could be incorrect. TCP wrappers > are definitely not IPv6-aware. > rpc.gssd should be ready to go for IPv6. rpc.svcgssd didn't need any changes since it only talks to the kernel. -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: IPv6 support 2009-11-02 16:40 ` Chuck Lever 2009-11-02 20:43 ` Jeff Layton @ 2009-11-05 11:49 ` Suresh Jayaraman 2009-11-05 14:41 ` Chuck Lever 2009-11-19 15:17 ` IPv6 support: dreaming of Ivan Shmakov 2009-11-19 16:18 ` IPv6 support Ivan Shmakov 3 siblings, 1 reply; 10+ messages in thread From: Suresh Jayaraman @ 2009-11-05 11:49 UTC (permalink / raw) To: Chuck Lever; +Cc: Linux NFS Mailing list, Chris Mason Hi Chuck, Thanks much for the detailed update. On 11/02/2009 10:10 PM, Chuck Lever wrote: > On Nov 2, 2009, at 3:20 AM, Suresh Jayaraman wrote: >> Hi Chuck et al, >> >> Thanks for all the excellent work on IPv6 support. There have been >> considerable amount of development that has been happening recently. >> However, it's not very clear what are the missing pieces or open >> problems (if any). > > There's a working document on the linux-nfs.org wiki that has a full > list, but I can't seem to get to linux-nfs.org right now. Is this what you mentioned? http://wiki.linux-nfs.org/wiki/index.php/Server_IPv6_support http://wiki.linux-nfs.org/wiki/index.php/NFSv4_Introduction#IPv6_support_for_the_client > > The long answer depends on your definition of "full". :-) > > Does that include complete support for link-local IPv6 addresses? Does > that include full support for netids in the kernel? Does that include > complete multi-homed host support in lockd and statd? Does that include > full support for internationalized domain names? Does that include IPv6 > netgroup support? Does it include IPv6 support in TCP wrappers? Does > it include support for systems that have no IPv4 addresses (not even > loopback)? > > There are a bunch of details that still need to be worked through. I've > only been able to guess at what features are required, and which can be > implemented at a later time. What I would dearly love to have is a list > of specific features that folks feel is a baseline (based on actual > data, of course). I'd try and see if I could get the list of specific features. > > Plus, most distributions don't have fluent user space infrastructure for > IPv6 yet. NetworkManager is one area that may need work. The Network > Administration tool in Fedora is still IPv4-centric, iirc. We don't > have firewall admin tools that handle IPv6 rules. Unlike IPv4, admins > can (and often do) use IPv6-aware kernels without ipv6.ko, so all of our > tools and support have to be careful about using IPv6 when the O/S may > not support it. This is different than IPv4, which is nearly always > available. > Thanks, -- Suresh Jayaraman ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: IPv6 support 2009-11-05 11:49 ` Suresh Jayaraman @ 2009-11-05 14:41 ` Chuck Lever 0 siblings, 0 replies; 10+ messages in thread From: Chuck Lever @ 2009-11-05 14:41 UTC (permalink / raw) To: Suresh Jayaraman; +Cc: Linux NFS Mailing list, Chris Mason On Nov 5, 2009, at 6:49 AM, Suresh Jayaraman wrote: > Hi Chuck, > > Thanks much for the detailed update. > > On 11/02/2009 10:10 PM, Chuck Lever wrote: >> On Nov 2, 2009, at 3:20 AM, Suresh Jayaraman wrote: >>> Hi Chuck et al, >>> >>> Thanks for all the excellent work on IPv6 support. There have been >>> considerable amount of development that has been happening recently. >>> However, it's not very clear what are the missing pieces or open >>> problems (if any). >> >> There's a working document on the linux-nfs.org wiki that has a full >> list, but I can't seem to get to linux-nfs.org right now. > > Is this what you mentioned? > > http://wiki.linux-nfs.org/wiki/index.php/Server_IPv6_support > http://wiki.linux-nfs.org/wiki/index.php/NFSv4_Introduction#IPv6_support_for_the_client Those are old design documents. I was referring to: http://wiki.linux-nfs.org/wiki/index.php/Ipv6PlanningDocument which is usually updated at least once a quarter. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 10+ messages in thread
* IPv6 support: dreaming of... 2009-11-02 16:40 ` Chuck Lever 2009-11-02 20:43 ` Jeff Layton 2009-11-05 11:49 ` Suresh Jayaraman @ 2009-11-19 15:17 ` Ivan Shmakov [not found] ` <87hbsqbl3d.fsf_-_-Hr8DDCuc/25fzK4uoAgqGcYP0srqJqIshoJSb6RVeLg@public.gmane.org> 2009-11-19 16:18 ` IPv6 support Ivan Shmakov 3 siblings, 1 reply; 10+ messages in thread From: Ivan Shmakov @ 2009-11-19 15:17 UTC (permalink / raw) To: linux-nfs >>>>> "CL" == Chuck Lever <chuck.lever...> writes: >>>>> "SJ" == Suresh Jayaraman wrote: ... And first of all: it seems that there're an immense amount of work being done to add the NFS over IPv6 support for GNU/Linux. Thanks for that! [...] SJ> How far we are from getting full IPv6 support? CL> The short answer is mountd/exportfs will take about six months. CL> The client side is close enough that I think we can promise basic CL> IPv6 support for upcoming enterprise releases. We're also thinking CL> the kernel work on the server is close enough that few or no kABI CL> changes will be needed once mountd is working, but that's just a CL> guess. CL> The long answer depends on your definition of "full". :-) Well, I'll try to answer to it based on my own use of NFS (mostly NFSv3, at this moment), as was suggested. Basically, every now and then I have to set up some shared filesystem-like resources. To this end, I usually deploy (at the same time): * HTTP, for its ubiquity; Alias /public /var/public <Directory /var/public> Options Indexes SymLinksIfOwnerMatch IncludesNoExec ExecCGI AllowOverride FileInfo AuthConfig Limit </Directory> * Rsync, for its superior handling of replication; [public] path = /var/public comment = Public directory * NFS, for it requires no specific support from the applications themselves. /var/public *(ro,all_squash,async,insecure) /var/public/debian *(ro,all_squash,async,insecure) /var/public/storage *(ro,all_squash,async,insecure) Mostly, these are used to conserve disk space by allowing a few copies of certain files to be used by a number of users. Rarely I need to maintain anything writable, and if possible, prefer to deploy SSH/SFTP for ``uploading''. I need almost no access management, as most of the data was received from open sources (say, http://www.debian.org/, http://www.landcover.org/ or http://wist.echo.nasa.gov/), and there were no DoS-doers or bandwidth hogs so far. Actually, even NFSv3 suits my needs almost completely, though occasionally I need Kerberos. CL> Does that include complete support for link-local IPv6 addresses? No. Not for me, at the least. IIUC, these are to be used mainly for low-level network services and testing. It could be handy to support these widely, but I'd not make it a priority task. CL> Does that include full support for netids in the kernel? No clue on this, sorry. CL> Does that include complete multi-homed host support in lockd and CL> statd? I believe that multi-homing is going to be more likely in IPv6 environments. I've never experimented with NFS on multi-homed IPv4 hosts, though, so I'm not sure what's meant by ``complete support'' here. CL> Does that include full support for internationalized domain names? Not for me. CL> Does that include IPv6 netgroup support? Do you mean netgroup like in NIS (or LDAP with a NIS-like schema)? These also could be handy, but not a priority task, at least for me. CL> Does it include IPv6 support in TCP wrappers? In general, I see TCP wrappers as, roughly, a functional equivalent of netfilter / ip6tables(8). So, once again, not a priority for me. (If I don't miss something.) CL> Does it include support for systems that have no IPv4 addresses CL> (not even loopback)? Absolutely. But it surely can wait. CL> There are a bunch of details that still need to be worked through. CL> I've only been able to guess at what features are required, and CL> which can be implemented at a later time. What I would dearly love CL> to have is a list of specific features that folks feel is a CL> baseline (based on actual data, of course). Hopefully, the bits above will help. CL> Unfortunately there are very few Linux customers who have deployed CL> IPv6 and an IPv6-capable NFS implementation (like Solaris) and can CL> tell us what they would need on Linux. It seems that my brother's going to do me a favor and install OpenSolaris for me (which, as I saw today, is being able to export and mount filesystems using NFS over IPv6.) (I wonder, are there Apache and Rsync bundled with OpenSolaris?) Perhaps I'll be able to experiment with some (up to 20 or so) Debian GNU/Linux hosts using it as a file server. CL> Plus, most distributions don't have fluent user space CL> infrastructure for IPv6 yet. NetworkManager is one area that may CL> need work. The Network Administration tool in Fedora is still CL> IPv4-centric, iirc. ... And, unfortunately, even interfaces(5) handling in Debian has flaws in that respect. Sigh. CL> We don't have firewall admin tools that handle IPv6 rules. Personally, I prefer ip6tables(8), which does. CL> Unlike IPv4, admins can (and often do) use IPv6-aware kernels CL> without ipv6.ko, so all of our tools and support have to be careful CL> about using IPv6 when the O/S may not support it. This is CL> different than IPv4, which is nearly always available. Agreed. CL> In other words, system support for IPv6 outside of NFS is kind of CL> like wireless was 5 years ago -- innumerable small admin tools that CL> users had to integrate themselves, usually without much success. -- FSF associate member #7257 ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <87hbsqbl3d.fsf_-_-Hr8DDCuc/25fzK4uoAgqGcYP0srqJqIshoJSb6RVeLg@public.gmane.org>]
* Re: IPv6 support: dreaming of... [not found] ` <87hbsqbl3d.fsf_-_-Hr8DDCuc/25fzK4uoAgqGcYP0srqJqIshoJSb6RVeLg@public.gmane.org> @ 2009-11-19 16:05 ` Chuck Lever 0 siblings, 0 replies; 10+ messages in thread From: Chuck Lever @ 2009-11-19 16:05 UTC (permalink / raw) To: Ivan Shmakov; +Cc: linux-nfs Thanks, Ivan. That echoes my own concept of a basic NFS over IPv6 deployment use case. On Nov 19, 2009, at 10:17 AM, Ivan Shmakov wrote: >>>>>> "CL" == Chuck Lever <chuck.lever...> writes: >>>>>> "SJ" == Suresh Jayaraman wrote: > > ... And first of all: it seems that there're an immense amount > of work being done to add the NFS over IPv6 support for > GNU/Linux. Thanks for that! > > [...] > > SJ> How far we are from getting full IPv6 support? > > CL> The short answer is mountd/exportfs will take about six months. > CL> The client side is close enough that I think we can promise basic > CL> IPv6 support for upcoming enterprise releases. We're also > thinking > CL> the kernel work on the server is close enough that few or no kABI > CL> changes will be needed once mountd is working, but that's just a > CL> guess. > > CL> The long answer depends on your definition of "full". :-) > > Well, I'll try to answer to it based on my own use of NFS > (mostly NFSv3, at this moment), as was suggested. > > Basically, every now and then I have to set up some shared > filesystem-like resources. To this end, I usually deploy (at > the same time): > > * HTTP, for its ubiquity; > > Alias /public /var/public > > <Directory /var/public> > Options Indexes SymLinksIfOwnerMatch IncludesNoExec ExecCGI > AllowOverride FileInfo AuthConfig Limit > </Directory> > > * Rsync, for its superior handling of replication; > > [public] > path = /var/public > comment = Public directory > > * NFS, for it requires no specific support from the applications > themselves. > > /var/public *(ro,all_squash,async,insecure) > /var/public/debian *(ro,all_squash,async,insecure) > /var/public/storage *(ro,all_squash,async,insecure) > > Mostly, these are used to conserve disk space by allowing a few > copies of certain files to be used by a number of users. Rarely > I need to maintain anything writable, and if possible, prefer to > deploy SSH/SFTP for ``uploading''. > > I need almost no access management, as most of the data was > received from open sources (say, http://www.debian.org/, > http://www.landcover.org/ or http://wist.echo.nasa.gov/), and > there were no DoS-doers or bandwidth hogs so far. > > Actually, even NFSv3 suits my needs almost completely, though > occasionally I need Kerberos. > > CL> Does that include complete support for link-local IPv6 addresses? > > No. Not for me, at the least. IIUC, these are to be used > mainly for low-level network services and testing. It could be > handy to support these widely, but I'd not make it a priority > task. > > CL> Does that include full support for netids in the kernel? > > No clue on this, sorry. > > CL> Does that include complete multi-homed host support in lockd and > CL> statd? > > I believe that multi-homing is going to be more likely in IPv6 > environments. I've never experimented with NFS on multi-homed > IPv4 hosts, though, so I'm not sure what's meant by ``complete > support'' here. > > CL> Does that include full support for internationalized domain names? > > Not for me. > > CL> Does that include IPv6 netgroup support? > > Do you mean netgroup like in NIS (or LDAP with a NIS-like > schema)? These also could be handy, but not a priority task, at > least for me. > > CL> Does it include IPv6 support in TCP wrappers? > > In general, I see TCP wrappers as, roughly, a functional > equivalent of netfilter / ip6tables(8). So, once again, not a > priority for me. (If I don't miss something.) > > CL> Does it include support for systems that have no IPv4 addresses > CL> (not even loopback)? > > Absolutely. But it surely can wait. > > CL> There are a bunch of details that still need to be worked through. > CL> I've only been able to guess at what features are required, and > CL> which can be implemented at a later time. What I would dearly > love > CL> to have is a list of specific features that folks feel is a > CL> baseline (based on actual data, of course). > > Hopefully, the bits above will help. > > CL> Unfortunately there are very few Linux customers who have deployed > CL> IPv6 and an IPv6-capable NFS implementation (like Solaris) and can > CL> tell us what they would need on Linux. > > It seems that my brother's going to do me a favor and install > OpenSolaris for me (which, as I saw today, is being able to > export and mount filesystems using NFS over IPv6.) > > (I wonder, are there Apache and Rsync bundled with OpenSolaris?) > > Perhaps I'll be able to experiment with some (up to 20 or so) > Debian GNU/Linux hosts using it as a file server. > > CL> Plus, most distributions don't have fluent user space > CL> infrastructure for IPv6 yet. NetworkManager is one area that may > CL> need work. The Network Administration tool in Fedora is still > CL> IPv4-centric, iirc. > > ... And, unfortunately, even interfaces(5) handling in Debian > has flaws in that respect. Sigh. > > CL> We don't have firewall admin tools that handle IPv6 rules. > > Personally, I prefer ip6tables(8), which does. > > CL> Unlike IPv4, admins can (and often do) use IPv6-aware kernels > CL> without ipv6.ko, so all of our tools and support have to be > careful > CL> about using IPv6 when the O/S may not support it. This is > CL> different than IPv4, which is nearly always available. > > Agreed. > > CL> In other words, system support for IPv6 outside of NFS is kind of > CL> like wireless was 5 years ago -- innumerable small admin tools > that > CL> users had to integrate themselves, usually without much success. > > -- > FSF associate member #7257 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" > in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: IPv6 support 2009-11-02 16:40 ` Chuck Lever ` (2 preceding siblings ...) 2009-11-19 15:17 ` IPv6 support: dreaming of Ivan Shmakov @ 2009-11-19 16:18 ` Ivan Shmakov 3 siblings, 0 replies; 10+ messages in thread From: Ivan Shmakov @ 2009-11-19 16:18 UTC (permalink / raw) To: linux-nfs >>>>> "CL" == Chuck Lever <chuck.lever...> writes: [...] CL> In other words, system support for IPv6 outside of NFS is kind of CL> like wireless was 5 years ago -- innumerable small admin tools that CL> users had to integrate themselves, usually without much success. BTW, I tend to disagree with that. I've ``discovered'' IPv6 only this summer, and for me, the whole thing was smooth... ... Almost. There were only a few issues: * /etc/network/interfaces (like in Debian GNU/Linux) handling is a bit IPv4-centric (even more so in Etch, oldstable); say, one may have to resort to the hacks like: iface eth1 inet6 static address X:Y:Z:W::1234:5678 netmask 64 gateway X:Y:Z:W::1 post-up ip -6 addr add G:H:I:J::DEAD:1/64 dev "$IFACE" && ip -6 addr add K:L:M:N::1337:CAFE/64 dev "$IFACE" (with Etch, one'd have to add IPv6 management commands to the existing IPv4 interfaces' stanzas.) * the stable version of Squid lacks IPv6 support completely; Apache has it, but it lacks caching, which is a must for me; * there're no VoIP switches with IPv6 support in Debian; in particular, Asterisk speaks no IPv6, while FreeSWITCH is not in Debian; (there was an ITP); there's Linphone for an IPv6-compatible user agent; * NFS. Otherwise, I use IPv6 on a daily basis, both at home and at work, and there seems to be no significant flaws, other than those few above. Occasionally, some hardware seems to behave strangely (e. g., I was unable to use IPv6 in one of classrooms here), and sometimes there're noticeable response times from hosts using old NICs, but hey, there're still a couple of 10 Mbit/s hubs in the darker corners of the network, and nobody seems to worry about it much. -- FSF associate member #7257 ^ permalink raw reply [flat|nested] 10+ messages in thread
* IPv6 support @ 2011-01-18 13:40 Mika Liljeberg 0 siblings, 0 replies; 10+ messages in thread From: Mika Liljeberg @ 2011-01-18 13:40 UTC (permalink / raw) To: ofono [-- Attachment #1: Type: text/plain, Size: 107 bytes --] Hi all, I plan to start working on IPv6 support. Br, MikaL [PATCH 1/1] TODO: claim IPv6 task ^ permalink raw reply [flat|nested] 10+ messages in thread
* IPv6 Support @ 2021-02-02 0:28 Raymond Yeung 0 siblings, 0 replies; 10+ messages in thread From: Raymond Yeung @ 2021-02-02 0:28 UTC (permalink / raw) To: u-boot Does uboot currently support IPv6? If so, how mature/stable is it? Thanks, Raymond ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-02-02 0:28 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-11-02 8:20 IPv6 support Suresh Jayaraman 2009-11-02 16:40 ` Chuck Lever 2009-11-02 20:43 ` Jeff Layton 2009-11-05 11:49 ` Suresh Jayaraman 2009-11-05 14:41 ` Chuck Lever 2009-11-19 15:17 ` IPv6 support: dreaming of Ivan Shmakov [not found] ` <87hbsqbl3d.fsf_-_-Hr8DDCuc/25fzK4uoAgqGcYP0srqJqIshoJSb6RVeLg@public.gmane.org> 2009-11-19 16:05 ` Chuck Lever 2009-11-19 16:18 ` IPv6 support Ivan Shmakov 2011-01-18 13:40 Mika Liljeberg 2021-02-02 0:28 IPv6 Support Raymond Yeung
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.