> On Jan 29, 2024, at 6:46 PM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: > > On Tue, Nov 14, 2023 at 3:07 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> >>> On Nov 13, 2023, at 5:57 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>> >>> On Mon, 13 Nov 2023 at 17:19, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>> >>>>> On Nov 10, 2023, at 2:54 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: >>>>> >>>>> On Wed, Nov 1, 2023 at 3:42 PM Benjamin Coddington <bcodding@xxxxxxxxxx> 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
