Hello, I have the system running and did first tests. This was interesting although I observed basically the behaviour you were expecting. >From what I see without libtirpc (standard package), autofs is as expected oblivious to IPv6. It passes the servers hostname to mount, which in the case of IPv4 and a single IPv6 address in the end uses the IPv6 one. In the case of two IPv6 addresses it falls back to IPv4 for some reason. So that is unrelated to autofs then (and I should ask somewhere else) ? I attached two syslog ouputs (debug level) covering the single IPv6 (single_log_wo_tirpc.txt.gz) and double IPv6 (multi_log_wo_tirpc.txt.gz) cases. I note, though, that mount on its own (mount -tnfs4 core330:/locals ...) always picks one of the IPv6 addresses and never the IPv4 address if both IPv6 addresses are in the DNS. So there is some difference to the behaviour when called from autofs. Do you have an idea what that might be or what I can do to find that out ? I rebuilt the stock package "--with-libtirpc" (after removing the problematic #ifdef block from rpc_subs.c) against the systems libtirpc 0.2.5. Then I tested again the two cases mentioned above, log output is attached as single_log_tirpc.txt.gz and multi_log_tirpc.txt.gz. In the "single" case the IPv6 address is always used as far as I could see (about 10 tries, fewer in log). The response time is apparently not used e.g. (see single_log_tirpc.txt.gz) Apr 27 16:23:33 core400 automount[2473]: get_nfs_info: nfs v4 rpc ping time: 0.000115 Apr 27 16:23:33 core400 automount[2473]: get_nfs_info: nfs v4 rpc ping time: 0.000153 results in Apr 27 16:23:33 core400 automount[2473]: mount_mount: mount(nfs): calling mount -t nfs4 -s -o rw,intr,nosuid,soft,nodev core330:/locals /local/core330 which then apparently decides to use the IPv6 address in its own. In the double IPv6 address case I see that all available addresses (IPv4 192.168.220.118, IPv6 GUA 2001:...:118 and IPv6 ULA fd5f:...:118) are used to mount and that actual IP addresses are passed to mount instead of a hostname (see single example above for the opposite behaviour). The choice of address is a direct result of the response time as you mentioned. It is unclear to me how it decides if an IP address or an hostname should be passed to mount, might this be multi-homed or failover behaviour ? But then even with IPv4 and a single IPv6 address the host sould be considered multi-homed for that purpose and not only if it has multiple IPv6 addresses ? Or is it working as designed ? Now some opinions before some package rebuild and technical questions: On Wed, Apr 27, 2016 at 09:54:38AM +0800, Ian Kent wrote: > > Then there's the question of order of addresses to try. > Should IPv6 addresses be higher priority than IPv4? I now see and understand the question. The behaviour of mount (stand alone or called from autofs) is puzzling in this context. Stand alone mount does IMHO the right thing: I always assumed that there was an agreed preference, e.g. observing for http/ssh connections that IPv6 in fact is preferred before eventually falling back to IPv4 (perhaps after a timeout). RFC 6724's Abstract says: "In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa." and in Section 10.3. "The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. This means that applications will use IPv6 in preference to IPv4 when the two are equally suitable." This is what /etc/gai.conf (source selection) and "ip addrlabel" defaults (destination selection) are based on. But may be I am overinterpreting the RFC considering its Abstract. As far as I read earlier this preference caused/can cause a great deal of pain sometimes. > > Should I even use IPv4 addresses when IPv6 addresses are present and > fall back to IPv4 if all IPv6 addresses fail? Fallback after failure might be reasonable. But I agree that there will be opinions and my use case is not a general or really complicated one, so I will abstain. > > If there is more than one distinct host and a host with only an IPv4 > address is "closer" (that's the proximity question and also response > time) than another host with only an IPv6 address, what selection policy > should I use? Yes, I see the point. This is obviously out of the RFC's scope. One could argue for a configuration file or compile time option(s) to influence address selection, but you know pros and cons of that and I do not. Especially considering that (some) distros are not even using libtirpc to begin with. Now the package rebuild questions: You built libtirpc 1.0.1 from the sourceforge source, put include and library files in the system locations by hand and then recompiled the autofs package against these ? Or is there a neat trick to avoid messing in the system locations by hand ? I am unsure how to reproduce what you did. Another question: What is your expectation in a situation where only IPv6 is available, no IPv4 for the server ? Is the one mentioned in #25 of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737679 expected to be still a working solution ? I might have an NFS server soon which, due to a routing conflict difficult to resolve, would only get an IPv6 address visible to the clients. I should test this case with a dedicated vm as server anyway ... > > And setting up a IPv6 test environment is difficult so having someone > that needs this is useful. > Thanks fr doing this. > I am glad to be able to help with testing. And of course thank You for taking the time to help me ! Best Regards Christof -- Dr. rer. nat. Christof Köhler email: c.koehler@xxxxxxxxxxxxxxxxxxx Universitaet Bremen/ BCCMS phone: +49-(0)421-218-62334 Am Fallturm 1/ TAB/ Raum 3.12 fax: +49-(0)421-218-62770 28359 Bremen PGP: http://www.bccms.uni-bremen.de/cms/people/c_koehler/
Attachment:
multi_log_wo_tirpc.txt.gz
Description: Binary data
Attachment:
multi_log_tirpc.txt.gz
Description: Binary data
Attachment:
single_log_wo_tirpc.txt.gz
Description: Binary data
Attachment:
single_log_tirpc.txt.gz
Description: Binary data
