Subject: [nfsv4] Format of IPv4/IPv6 addresses in fs_locations / fs_locations_info

From: Trond Myklebust <[email-masked]>
Date: Thu, 21 Aug 2008 14:14:06 -0700

Hi,

RFC3530 and the draft NFSv4.1 spec both state that the server addresses
supplied in fs_locations and fs_locations_info may be either DNS names,
or as 'literal IP addresses'.

My question is then, what is a 'literal IP address'? Is it another
instance of a 'universal address' as defined in section 2.2 of RFC2373,
or is it something else? If so, what is the definition?

Cheers
  Trond

Subject: Re: [PATCH] nfs: Fix misparsing of nfsv4 fs_locations attribute
From: "J. Bruce Fields" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 21 Aug 2008 16:46:20 -0400
List-Id: <linux-nfs.vger.kernel.org>

On Wed, Aug 20, 2008 at 10:00:25PM -0400, Chuck Lever wrote:
> On Wed, Aug 20, 2008 at 7:30 PM, J. Bruce Fields <[email-masked]> wrote:
> > On Wed, Aug 20, 2008 at 06:07:50PM -0400, Chuck Lever wrote:
> >> What may be confusing you is that scope delimiters are used almost
> >> exclusively for link-local addresses, which are valid only on the
> >> local host.
> >>
> >> If you don't want to handle a referral that uses a link-local address,
> >> or you don't want to handle a link-local address with a scope ID, then
> >> there are explicit checks you can do.
> >
> > Well, the current code does allow a referral to point to 127.0.0.1.  I
> > don't know what to think of that; it seems unlikely to be useful for
> > anything but testing, and possibly succeptible to abuse, but of course
> > the protocol doesn't forbid it.
> 
> Link-local is not the same as loopback.
> 
> A link-local address is an address that is constructed by a
> standards-defined method for each active NIC on a host.  It is not a
> route-able address, so it's good only for the local subnet.  It's a
> method by which network service is exposed to higher levels in the
> network layer without having to use an external service like DHCP.
> It's a bootstrap address, more or less.
> 
> > I google around a bit, but still don't get the scope stuff.  Are they
> > really part of an "ipv6 address"?  I thought an ipv6 address was just a
> > 128-bit number?  (Or do they just give another way of writing something
> > that you could already write without the %?)
> 
> Unfortunately good IPv6 documentation is pretty hard to find.  There
> are a lot of RFCs that specify just a little corner of IPv6 (and even
> those usually have corrections or amendments in later RFCs), so it's
> difficult to know where to begin.  IPv6 is nearly a complete
> reconception of the internet, so many IPv4 concepts simply don't
> translate.  I don't think there's anything equivalent to a scope
> delimiter in IPv4.  The following is my understanding of how this
> works.
> 
> This is really a question of how to map a presentation format address
> (a string that represents the numeric form of the address, like
> dotted-quad notation) to a sockaddr.

OK, but what the v4 rfc says isn't that the fs_location field can
contain any representation of a sockaddr; it says that it can contain "a
traditional DNS host name, IPv4 address, or IPv6 address."

Every definition of "IPv6 address" I can find says that it's just the
128 bits you put in sin6_addr.  The scope id field, like a port number,
is something in addition.

So if we see such a string we should just assume it's garbage.

> The sockaddr_sin6 structure has a field for the scope ID,
> sin6_scope_id.  The % delimits the host address from a string that
> identifies a local NIC.  You can specify a device name, like "eth0,"
> or a number, which means the same thing.  The number is referred to as
> an interface index, or a scope ID.  The device name is converted by a
> locally-defined mechanism to a scope ID (the numeric equivalent) and
> stored in the sin6_scope_id field of a sockaddr_sin6.
>
> Link-local addresses require a specific NIC to be identified to work
> properly, even if there is only a single NIC on the host, since the
> "lo" virtual interface also has an interface index.  You can also use
> a scope ID with a non-link-local address to force which NIC is used.
> By and large, these interface indices are not meaningful anywhere but
> on the host that has that link-local address assigned to one of its
> NICs.

OK, so that definitely doesn't sound like something that makes sense
outside the client.

> It really depends on how the referral hostname string is generated,
> but I would say that whatever follows the % should be ignored, or you
> could generate a warning or error.

So I think we should be harsher and just not attempt to parse a string
that looks like this at all.

--b.

> You can let the existing super.c
> address parser handle the '%' and check to see if sin6_scope_id is
> non-zero on return (or just zero it unconditionally if you want to
> ignore these altogether).  If the NFSv4 standard doesn't say anything
> about IPv6 interface IDs, then I suppose we are free to treat this any
> way we think is reasonable.
> 
> I'm still not quite sure how to handle link-local addresses for NFSv4
> callback, for example.  Generally it doesn't make sense to hand the
> server an interface ID that is valid only on the client, so mount.nfs
> just strips the interface ID when generating the callback IP address
> string: it won't pass a scope-delimited presentation format address in
> the clientaddr= option.
> 
> For a link-local callback address, the server then must determine
> which of its own interfaces it must use to contact the client via that
> link-local address, and append it via a % or by setting the
> sin6_scope_id field.  Or it can simply decide not to call a client
> back that passed it a link-local address as a callback address.
> 
> -- 
> Chuck Lever
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [email-masked]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 22 Aug 2008 08:17:53 -0500

> or is it something else? If so, what is the definition?

My working assumption/intent has been Universal address.  This allows  
for port
redirection as well as IP address redirection and relies on a  
definition that is used
within the spec already.

Spencer

> Date: August 21, 2008 3:46:20 PM CDT
> To: [email-masked]
>> On Wed, Aug 20, 2008 at 7:30 PM, J. Bruce Fields <[email-masked] 
>> > wrote:

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 22 Aug 2008 11:02:35 -0700 (PDT)

Since this is underspecified, we need to be very forgiving.

> > My working assumption/intent has been Universal address.  This allows

There is no netid though. The NFSv4.0 and 4.1 specifications
only allow IPv4 and IPv6. In addition, the specifications do not
mention the port part of the address.

So I think that clients have to be able to deal with:

   h1.h2.h3.h4 - an IPv4 address assumed to listen on port 2049
   h1.h2.h3.h4.p1.p2 - an IPv4 address assume to listen on port p2*256+p1.

   x1:x2:x3:x4:x5:x6:x7:x8 - an IPv6 assumed to listen on port 2049
   x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 - an IPv6 assumed to listen on port
                      p2*256+p1

   Also there are bunches of short representations for x1:...x6,
   which
http://tools.ietf.org/html/draft-ietf-nfsv4-rpc-netid-03#section-3.2.3.4
   alludes to, and makes a reference to RFC  (Section 2.2) 4291.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 22 Aug 2008 13:06:05 -0500

> Since this is underspecified, we need to be very forgiving.

Sure.  I don't have any problem with what is below.

Spencer

---

From: Robert Gordon <[email-masked]>
Date: Fri, 22 Aug 2008 13:26:34 -0500

>   alludes to, and makes a reference to RFC  (Section 2.2) 4291.

there is also this format for mixed v6 and v4 environments (as you  
alluded to)

0:0:0:0:0:FFFF:129.144.52.38 (for 2049)

0:0:0:0:0:FFFF:129.144.52.38.p1.p2

Hmmm..

Robert..

---

From: Robert Gordon <[email-masked]>
Date: Fri, 22 Aug 2008 14:40:17 -0500

I was wondering if section 3.2.3.4 of draft-ietf-nfsv4-rpc-netid-03  
would read better along the lines of :-

3.2.3.4.  Uaddr Format for Most IPv6 Transports

    Most transport protocols that operate over IPv6 use 16 bit port
    numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP
    [15].  The format of the uaddr for the above 16 bit port transports
    (when used over IPv6) is any text representation of an IPv6 address
    as defined in Section 2.2 of [3] with the suffix "p1.p2". The suffix
    is computed the same way as with uaddrs for transports over
    IPv4 (see Section 3.2.3.3).

--

Robert.

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 22 Aug 2008 12:51:08 -0700 (PDT)

I think your change suffers from not explaining at least one format,
i.e.
        x1:x2:x3:x4:x5:x6:x7:x8.p1.p2