> On Jan 10, 2024, at 1:06 AM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > On Mon, 8 Jan 2024 at 15:39, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> On Sun, Jan 07, 2024 at 11:33:31PM +0100, Cedric Blancher wrote: >>> Could you please make a concentrated effort and allow non-2049 port >>> numbers for NFSv4 mounts, in all of the lifecycle of a NFSv4 mount? >>> From nfsd, nfsd referrals, client mount/umount, autofs >>> mount/umount+LDAP spec >> >> One reason we have not pursued stack-wide NFSv4 support for >> alternate ports is that they are not firewall-friendly. A major >> design point of NFSv4 (and NFSv4.1, with its backchannel) is that >> it is supposed to be more firewall-friendly than NFSv3, its >> auxiliary protocols, and its requirement to deploy rpcbind. > > Who came up with THAT argument?! The IETF's NFSv4 standards group. NLM, NSM, MNT, NFSACL, and NFS were made a single protocol with NFSv4.0. One reason for this design was the necessity to add OPEN/CLOSE operations to make file locking more reliable. But another was to reduce the number of open ports needed, and to eliminate the need to run rpcbind on NFS servers. With NFSv4.1, callback operation was also combined into the main protocol by making servers do callbacks on the same transport connection as forechannel operation. This is precisely because callbacks could not transition NAT boxes and firewalls in a convenient fashion. You can find a generic mention of it here: https://www.rfc-editor.org/rfc/rfc8881#name-nfsv4-goals Though that is not as detailed a discussion as I might have hoped. The overall goal mentioned here is good operation on the open internet and the ability to transition firewalls easily. > NFSv4 was designed around the concept of ONE TCP port for everything > (fs, mount, lock daemons, ...), so multiple servers per IPv4 address > can become a reality, but not specifically 2049 - with the clear > assumption that using port 2049 might not be feasible for all > organisations. I've never heard that, and I've been active in the NFS standards group for many years, and have worked closely with the authors of these standards and the folks who created the implementation of NFSv4 on several platforms. So if that truly was a goal of the single-port design, it has not been mentioned recently, and there are certain protocol gaps (like no explicit port field in the fs_locations attribute) that make me doubt your assertion that alternate ports was a primary protocol design goal. But this is only a sidebar. > If you look at Solaris BUGSTER (remember, we were a big SUN customer > in the 1990/2000, so we had lots of bugs open for this mess), you'll > find lots of reasons why one single port for NFS is not feasible in > all scenarios. > Just some examples, but certainly not limited to: > - Fine-grained HSM, all on one host > - Fine-grained project/resource management, i.e. one nfs server per > project, all on one host > - Competing teams > - Hostile IT department (e.g. port 2049 blocked out of FEAR - not > reason, no further discussion/negotiation possible) > - NFSv4 tunneled via ssh > - NAT, e.g. private IPv4 address range inside, only one IPv4 address outside > - IPv4 address shortage > - Software test deployments in parallel to the production systems, on > the same machine > - ... > > In any of these scenarios you'll end up with NFSv4 certainly not using > TCP port 2049. In most of these cases, the use of alternate ports has been superceded in the past 20 years. I'm not saying there are no legitimate uses for alternate ports, only that they seem to be increasingly a corner case, and that's the way the Linux NFS community has prioritized them. (And incidentally, they do mostly work today in Linux. There are just a few missing spots). Look, you are really not hearing me, clearly. No-one has said no we won't. We have said: this is harder than you think, and here is why. We have said: if you want to do this sooner, here is what we, as the stewards of this code, will accept. We do have a plan for this, after all. Just not enough time to do it. This is open source. If you have an itch, you can scratch it yourself. You do not demand that others implement what you want, for free. Where do you think the resources for developing new features comes from? Please stop arguing with strawmen and write some code. -- Chuck Lever
