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

Nils Steinger <nst@voidptr.de> Thu, 14 September 2017 22:03 UTC

Return-Path: <nst@voidptr.de>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C331321A7 for <nfsv4@ietfa.amsl.com>; Thu, 14 Sep 2017 15:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beUXW6Et-UlO for <nfsv4@ietfa.amsl.com>; Thu, 14 Sep 2017 15:02:57 -0700 (PDT)
Received: from rho.voidptr.de (rho.voidptr.de [84.200.43.138]) by ietfa.amsl.com (Postfix) with ESMTP id BEF3F13208E for <nfsv4@ietf.org>; Thu, 14 Sep 2017 15:02:57 -0700 (PDT)
To: nfsv4@ietf.org
From: Nils Steinger <nst@voidptr.de>
Openpgp: id=01795F52941E8169E359C173EECBF7FA485586E8; url=https://voidptr.de/pubkey.asc
Message-ID: <d425d70c-eb30-6ef7-c278-5143a3b81b48@voidptr.de>
Date: Fri, 15 Sep 2017 00:02:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="rtB2tsaNPF18iQxe9UNX1WKWl5STqmbIw"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/El5XrF88B8Q86wfrl4VOOpTcG5s>
Subject: [nfsv4] Proposal: Registered port numbers for NFS-related daemons
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2017 22:04:17 -0000

Dear all,

I recently had to grant access to an NFSv3 server behind a firewall,
which requires reconfiguring statd, mountd, lockd, and possibly rquotad
to use static port numbers, rather than ones assigned dynamically in
conjunction with portmap.
This raised the question which ports to use to minimise the risk of
collisions with other existing or future services.

I was unable to find any best practice documentation or IANA port
registrations for statd, lockd, and rquotad.
For mountd, there is a IANA registration for port 20048, granted to one
Nicolas Williams (@oracle.com) in 2010. [1]


*Proposal:*
Obtain IANA port registrations for the remaining three services.
(And perhaps contact Mr Williams about transferring the administration
of his port registration to the IETF.)

This would establish a guideline that would hopefully prevent any
(production-quality) software from using that set of ports, so they
could be used safely whenever the need for static NFS port configuration
arises.

Is this an idea that would be (1) feasible and (2) make sense to
implement?
From my inquiry to the IANA, they see any NFS-related requests and
decisions as a responsibility of the IETF (i.e., they refused to discuss
the matter with me and directed me to this WG instead).


(Incidentally, I'm also inclined to ask why NFS doesn't use static ports
in the first place. As a mere user of implementations of the protocol, I
frankly have no clue about the design decisions behind this and am
curious to learn about them.)


Kind regards,
Nils Steinger


[1]:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=mountd