Re: [nfsv4] Proposal: Registered port numbers for NFS-related daemons

[Nils Steinger <[e-mail]>]

On 2017-09-16 18:35, Tom Talpey wrote:
> Properly implemented RPC clients will use the RPC Portmapper (RFC1833)
> on port 111 to resolve the port of each RPC service, for instance NFS,
> statd, lockd, mountd, etc. For this reason, there's been no need to
> standardize the port numbers for each of the services you mention; each
> one is free to choose any local port, as long as the server advertises
> via portmap.

The need for fixed port numbers arises when using a firewall between the
NFS server and client.
I have yet to find a firewall that can talk to the portmapper to
dynamically configure ACCEPT rules for the ports currently in use, so
the only option is to configure away the dynamic behaviour.
The client will of course still ask the portmapper for the port numbers,
but the response will always be the same.

I'm very uncomfortable with just choosing any arbitrary port number
that happens to be unregistered *now*, since it might be registered at
some point in the future, perhaps to a service that I wish to use.

Hence the request to get some officially sanctioned port numbers to
avoid any future double use scenarios.


> This situation changes in NFSv4.x. In these versions, there are no
> "side protocols" and the NFS port is used for all client-to-server
> communications. Additionally, the registered port 2049 (or 20049 for
> NFS/RDMA) is used without required lookups to the portmapper. In
> NFSv4.0, however, the callback channel is dynamically allocated and
> requires explicit firewall configuration to allow the server to connect
> to the client (note the opposite polarity). This was corrected in
> NFSv4.1 and all recent NFS minor versions use the single port.

I have to admit I have very little experience with NFSv4 at this time.
From what I've gathered, it no longer should (or can) use raw numeric
user/group IDs on the wire. My small environment doesn't have a central
user database (yet), so it was my impression that using v4 instead of v3
would break things.

> You should think very carefully before exposing NFSv3 services to
> the internet. I assume you are considering this only in private
> network settings.

The firewall sits between the fileserver on the main network and a VPN
for "road warriors". Technically, I could just grant unrestricted access
from the VPN to the main network, but (again planning for potential
future services), I'd rather specify what services the VPN users have
access to.