Good morning!
We have questions about NFSv4 referrals:
1. Is there a way to test them in Debian Linux?
2. How does a fs_locations attribute look like when a nonstandard port
like 6666 is used?
RFC5661 says this:
* http://tools.ietf.org/html/rfc5661#section-11.9
* 11.9. The Attribute fs_locations
* An entry in the server array is a UTF-8 string and represents one of a
* traditional DNS host name, IPv4 address, IPv6 address, or a zero-length
* string. An IPv4 or IPv6 address is represented as a universal address
* (see Section 3.3.9 and [15]), minus the netid, and either with or without
* the trailing ".p1.p2" suffix that represents the port number. If the
* suffix is omitted, then the default port, 2049, SHOULD be assumed. A
* zero-length string SHOULD be used to indicate the current address being
* used for the RPC call.
Does anyone have an example of how the content of fs_locations should
look like with a custom port number?
Thanks,
Martin
On 1 Nov 2023, at 5:06, Martin Wege wrote:
> Good morning!
>
> We have questions about NFSv4 referrals:
> 1. Is there a way to test them in Debian Linux?
>
> 2. How does a fs_locations attribute look like when a nonstandard port
> like 6666 is used?
> RFC5661 says this:
>
> * http://tools.ietf.org/html/rfc5661#section-11.9
> * 11.9. The Attribute fs_locations
> * An entry in the server array is a UTF-8 string and represents one of a
> * traditional DNS host name, IPv4 address, IPv6 address, or a zero-length
> * string. An IPv4 or IPv6 address is represented as a universal address
> * (see Section 3.3.9 and [15]), minus the netid, and either with or without
> * the trailing ".p1.p2" suffix that represents the port number. If the
> * suffix is omitted, then the default port, 2049, SHOULD be assumed. A
> * zero-length string SHOULD be used to indicate the current address being
> * used for the RPC call.
>
> Does anyone have an example of how the content of fs_locations should
> look like with a custom port number?
If you keep following the references, you end up with the example in
rfc5665, which gives an example for IPv4:
https://datatracker.ietf.org/doc/html/rfc5665#section-5.2.3.3
Ben
On Tue, Nov 14, 2023 at 3:07 AM Chuck Lever III <[email protected]> wrote:
>
>
> > On Nov 13, 2023, at 5:57 PM, Cedric Blancher <[email protected]> wrote:
> >
> > On Mon, 13 Nov 2023 at 17:19, Chuck Lever III <[email protected]> wrote:
> >>
> >>
> >>> On Nov 10, 2023, at 2:54 AM, Martin Wege <[email protected]> wrote:
> >>>
> >>> On Wed, Nov 1, 2023 at 3:42 PM Benjamin Coddington <[email protected]> wrote:
> >>>>
> >>>> On 1 Nov 2023, at 5:06, Martin Wege wrote:
> >>>>
> >>>>> Good morning!
> >>>>>
> >>>>> We have questions about NFSv4 referrals:
> >>>>> 1. Is there a way to test them in Debian Linux?
> >>>>>
> >>>>> 2. How does a fs_locations attribute look like when a nonstandard port
> >>>>> like 6666 is used?
> >>>>> RFC5661 says this:
> >>>>>
> >>>>> * http://tools.ietf.org/html/rfc5661#section-11.9
> >>>>> * 11.9. The Attribute fs_locations
> >>>>> * An entry in the server array is a UTF-8 string and represents one of a
> >>>>> * traditional DNS host name, IPv4 address, IPv6 address, or a zero-length
> >>>>> * string. An IPv4 or IPv6 address is represented as a universal address
> >>>>> * (see Section 3.3.9 and [15]), minus the netid, and either with or without
> >>>>> * the trailing ".p1.p2" suffix that represents the port number. If the
> >>>>> * suffix is omitted, then the default port, 2049, SHOULD be assumed. A
> >>>>> * zero-length string SHOULD be used to indicate the current address being
> >>>>> * used for the RPC call.
> >>>>>
> >>>>> Does anyone have an example of how the content of fs_locations should
> >>>>> look like with a custom port number?
> >>>>
> >>>> If you keep following the references, you end up with the example in
> >>>> rfc5665, which gives an example for IPv4:
> >>>>
> >>>> https://datatracker.ietf.org/doc/html/rfc5665#section-5.2.3.3
> >>>
> >>> So just <address>.<upper-byte-of-port-number>.<lower-byte-of-port-number>?
> >>
> >>> How can I test that with the refer= option in /etc/exports? nfsref
> >>> does not seem to have a ports option...
> >>
> >> Neither refer= nor nfsref support alternate ports for exactly the
> >> same reason: The mountd upcall/downcall, which is how the kernel
> >> learns of referral target locations, needs to be fixed first. Then
> >> support for alternate ports can be implemented in both refer= and
> >> nfsref.
> >
> > Just turn "hostname" into "hostport", i.e. the "hostname" string in
> > the mountd protocol gets the port number encoded into it. Problem
> > done. This is seriously a non-brainer,
>
> It's not as simple as you think.
>
> As far as I can tell, the mountd upcall/downcall already uses the "@"
> character in the refer= value for another purpose. It has the same
> problem as using ":" -- it would overload the meaning of the character
> and make the refer= value ambiguous and unparsable.
>
> NFSD supports IPv4 addresses, IPv6 addresses, and DNS labels as the
> hostname part of each fs_locations entry. DNS label support is one
> reason we might have some difficulty using a universal address in
> this interface -- the dot notation for the port number bytes looks
> no different than the dot notation for subdomains, and we want to
> enable alternate ports for both raw IP addresses and DNS labels.
Which syntax does a DNS label have?
Thanks,
Martin
> On Jan 29, 2024, at 6:46 PM, Martin Wege <[email protected]> wrote:
>
> On Tue, Nov 14, 2023 at 3:07 AM Chuck Lever III <[email protected]> wrote:
>>
>>
>>> On Nov 13, 2023, at 5:57 PM, Cedric Blancher <[email protected]> wrote:
>>>
>>> On Mon, 13 Nov 2023 at 17:19, Chuck Lever III <[email protected]> wrote:
>>>>
>>>>
>>>>> On Nov 10, 2023, at 2:54 AM, Martin Wege <[email protected]> wrote:
>>>>>
>>>>> On Wed, Nov 1, 2023 at 3:42 PM Benjamin Coddington <[email protected]> wrote:
>>>>>>
>>>>>> On 1 Nov 2023, at 5:06, Martin Wege wrote:
>>>>>>
>>>>>>> Good morning!
>>>>>>>
>>>>>>> We have questions about NFSv4 referrals:
>>>>>>> 1. Is there a way to test them in Debian Linux?
>>>>>>>
>>>>>>> 2. How does a fs_locations attribute look like when a nonstandard port
>>>>>>> like 6666 is used?
>>>>>>> RFC5661 says this:
>>>>>>>
>>>>>>> * http://tools.ietf.org/html/rfc5661#section-11.9
>>>>>>> * 11.9. The Attribute fs_locations
>>>>>>> * An entry in the server array is a UTF-8 string and represents one of a
>>>>>>> * traditional DNS host name, IPv4 address, IPv6 address, or a zero-length
>>>>>>> * string. An IPv4 or IPv6 address is represented as a universal address
>>>>>>> * (see Section 3.3.9 and [15]), minus the netid, and either with or without
>>>>>>> * the trailing ".p1.p2" suffix that represents the port number. If the
>>>>>>> * suffix is omitted, then the default port, 2049, SHOULD be assumed. A
>>>>>>> * zero-length string SHOULD be used to indicate the current address being
>>>>>>> * used for the RPC call.
>>>>>>>
>>>>>>> Does anyone have an example of how the content of fs_locations should
>>>>>>> look like with a custom port number?
>>>>>>
>>>>>> If you keep following the references, you end up with the example in
>>>>>> rfc5665, which gives an example for IPv4:
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/html/rfc5665#section-5.2.3.3
>>>>>
>>>>> So just <address>.<upper-byte-of-port-number>.<lower-byte-of-port-number>?
>>>>
>>>>> How can I test that with the refer= option in /etc/exports? nfsref
>>>>> does not seem to have a ports option...
>>>>
>>>> Neither refer= nor nfsref support alternate ports for exactly the
>>>> same reason: The mountd upcall/downcall, which is how the kernel
>>>> learns of referral target locations, needs to be fixed first. Then
>>>> support for alternate ports can be implemented in both refer= and
>>>> nfsref.
>>>
>>> Just turn "hostname" into "hostport", i.e. the "hostname" string in
>>> the mountd protocol gets the port number encoded into it. Problem
>>> done. This is seriously a non-brainer,
>>
>> It's not as simple as you think.
>>
>> As far as I can tell, the mountd upcall/downcall already uses the "@"
>> character in the refer= value for another purpose. It has the same
>> problem as using ":" -- it would overload the meaning of the character
>> and make the refer= value ambiguous and unparsable.
>>
>> NFSD supports IPv4 addresses, IPv6 addresses, and DNS labels as the
>> hostname part of each fs_locations entry. DNS label support is one
>> reason we might have some difficulty using a universal address in
>> this interface -- the dot notation for the port number bytes looks
>> no different than the dot notation for subdomains, and we want to
>> enable alternate ports for both raw IP addresses and DNS labels.
>
> Which syntax does a DNS label have?
I'm not sure what you're asking.
A DNS label is just a hostname (fully-qualified or not). It
never includes a port number.
According to RFC 8881, fs_location4's server field can contain:
- A DNS label (no port number; 2049 is assumed)
- An IP presentation address (no port number; 2049 is assumed)
- a universal address
A universal address is an IP address plus a port number. Therefore
a universal address is the only way an alternate port can be
communicated in an NFSv4 referral.
The RFC is only about wire protocol. It says nothing about the
server's administrative interfaces; those are always up to the
whim of server developers.
In NFSD's case, refer= can specify a DNS label (no port), an IPv4
or IPv6 address (no port), or an IPv4 universal address. This
is because of the punctuation involved with separating the list
of export options, and the punctuation used internally in DNS
labels and IP addresses.
To add support for other combinations would require code changes.
--
Chuck Lever
On Mon, 2024-02-05 at 15:13 +0000, Chuck Lever III wrote:
>
>
> A DNS label is just a hostname (fully-qualified or not). It
> never includes a port number.
>
> According to RFC 8881, fs_location4's server field can contain:
>
> - A DNS label (no port number; 2049 is assumed)
>
> - An IP presentation address (no port number; 2049 is assumed)
>
> - a universal address
>
> A universal address is an IP address plus a port number. Therefore
> a universal address is the only way an alternate port can be
> communicated in an NFSv4 referral.
That's not strictly true. RFC8881 has little to say about how you are
to go about using the DNS hostname provided by fs_locations4. There is
just some non-normative and vague language about using DNS to look up
the addresses.
The use of DNS service records do allow you to look up the full IP
address and port number (i.e. the equivalent of a universal address)
given a fully qualified hostname and a service. While we do not use the
hostname that way in the Linux NFS client today, I see nothing in the
spec that would appear to disallow it at some future time.
> The RFC is only about wire protocol. It says nothing about the
> server's administrative interfaces; those are always up to the
> whim of server developers.
>
> In NFSD's case, refer= can specify a DNS label (no port), an IPv4
> or IPv6 address (no port), or an IPv4 universal address. This
> is because of the punctuation involved with separating the list
> of export options, and the punctuation used internally in DNS
> labels and IP addresses.
>
> To add support for other combinations would require code changes.
Agreed, and there would also be the major issue of trying to ensure
backward compatibility if you were to rely on client behaviour that
differs from today.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
> On Feb 5, 2024, at 11:17 AM, Trond Myklebust <[email protected]> wrote:
>
> On Mon, 2024-02-05 at 15:13 +0000, Chuck Lever III wrote:
>>
>>
>> A DNS label is just a hostname (fully-qualified or not). It
>> never includes a port number.
>>
>> According to RFC 8881, fs_location4's server field can contain:
>>
>> - A DNS label (no port number; 2049 is assumed)
>>
>> - An IP presentation address (no port number; 2049 is assumed)
>>
>> - a universal address
>>
>> A universal address is an IP address plus a port number. Therefore
>> a universal address is the only way an alternate port can be
>> communicated in an NFSv4 referral.
>
> That's not strictly true. RFC8881 has little to say about how you are
> to go about using the DNS hostname provided by fs_locations4. There is
> just some non-normative and vague language about using DNS to look up
> the addresses.
>
> The use of DNS service records do allow you to look up the full IP
> address and port number (i.e. the equivalent of a universal address)
> given a fully qualified hostname and a service. While we do not use the
> hostname that way in the Linux NFS client today, I see nothing in the
> spec that would appear to disallow it at some future time.
We absolutely could do that. But first a service name would need to be
reserved, yes?
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=dns
--
Chuck Lever
On Mon, 2024-02-05 at 19:53 +0000, Chuck Lever III wrote:
>
>
> > On Feb 5, 2024, at 11:17 AM, Trond Myklebust
> > <[email protected]> wrote:
> >
> > On Mon, 2024-02-05 at 15:13 +0000, Chuck Lever III wrote:
> > >
> > >
> > > A DNS label is just a hostname (fully-qualified or not). It
> > > never includes a port number.
> > >
> > > According to RFC 8881, fs_location4's server field can contain:
> > >
> > > - A DNS label (no port number; 2049 is assumed)
> > >
> > > - An IP presentation address (no port number; 2049 is assumed)
> > >
> > > - a universal address
> > >
> > > A universal address is an IP address plus a port number.
> > > Therefore
> > > a universal address is the only way an alternate port can be
> > > communicated in an NFSv4 referral.
> >
> > That's not strictly true. RFC8881 has little to say about how you
> > are
> > to go about using the DNS hostname provided by fs_locations4. There
> > is
> > just some non-normative and vague language about using DNS to look
> > up
> > the addresses.
> >
> > The use of DNS service records do allow you to look up the full IP
> > address and port number (i.e. the equivalent of a universal
> > address)
> > given a fully qualified hostname and a service. While we do not use
> > the
> > hostname that way in the Linux NFS client today, I see nothing in
> > the
> > spec that would appear to disallow it at some future time.
>
> We absolutely could do that. But first a service name would need to
> be
> reserved, yes?
>
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=dns
>
What's wrong with the one that is already assigned? I'm talking about:
nfs 2049 tcp Network File System - Sun [Brent_Callaghan] [Brent_Callaghan] Defined TXT keys: path=<path to mount point>
Microsystems
nfs 2049 udp Network File System - Sun [Brent_Callaghan] [Brent_Callaghan] Defined TXT keys: path=<path to mount point>
Microsystems
nfs 2049 sctp Network File System [RFC5665] Defined TXT keys: path=<path to mount point>
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
On Mon, Feb 05, 2024 at 08:34:46PM +0000, Trond Myklebust wrote:
> On Mon, 2024-02-05 at 19:53 +0000, Chuck Lever III wrote:
> >
> >
> > > On Feb 5, 2024, at 11:17 AM, Trond Myklebust
> > > <[email protected]> wrote:
> > >
> > > On Mon, 2024-02-05 at 15:13 +0000, Chuck Lever III wrote:
> > > >
> > > >
> > > > A DNS label is just a hostname (fully-qualified or not). It
> > > > never includes a port number.
> > > >
> > > > According to RFC 8881, fs_location4's server field can contain:
> > > >
> > > > - A DNS label (no port number; 2049 is assumed)
> > > >
> > > > - An IP presentation address (no port number; 2049 is assumed)
> > > >
> > > > - a universal address
> > > >
> > > > A universal address is an IP address plus a port number.
> > > > Therefore
> > > > a universal address is the only way an alternate port can be
> > > > communicated in an NFSv4 referral.
> > >
> > > That's not strictly true. RFC8881 has little to say about how you
> > > are
> > > to go about using the DNS hostname provided by fs_locations4. There
> > > is
> > > just some non-normative and vague language about using DNS to look
> > > up
> > > the addresses.
> > >
> > > The use of DNS service records do allow you to look up the full IP
> > > address and port number (i.e. the equivalent of a universal
> > > address)
> > > given a fully qualified hostname and a service. While we do not use
> > > the
> > > hostname that way in the Linux NFS client today, I see nothing in
> > > the
> > > spec that would appear to disallow it at some future time.
> >
> > We absolutely could do that. But first a service name would need to
> > be
> > reserved, yes?
> >
> > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=dns
> >
>
> What's wrong with the one that is already assigned? I'm talking about:
>
> nfs 2049 tcp Network File System - Sun [Brent_Callaghan] [Brent_Callaghan] Defined TXT keys: path=<path to mount point>
> Microsystems
> nfs 2049 udp Network File System - Sun [Brent_Callaghan] [Brent_Callaghan] Defined TXT keys: path=<path to mount point>
> Microsystems
> nfs 2049 sctp Network File System [RFC5665] Defined TXT keys: path=<path to mount point>
For reference:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2049
My search terms excluded these, so I missed them.
I don't see the IANA action request text in RFC 5665. These must
have been specified and requested in some other document, or that
action request was removed before RFC 5665 was published.
Putative example: NFS on port 2050 of example.com:
_nfs._tcp.example.com. 86400 IN SRV 0 5 2050 server1.example.com.
I suppose "mount.nfs" could recognize this mapping as well.
Since the transport protocol is included in the SRV record, I'm not
sure how one would encode "rdma" for NFS on iWARP, which uses a
distinct port (20049).
--
Chuck Lever