IPv6 scope handling, was Re: svn commit: r335806 - projects/pnfs-planb-server/usr.sbin/nfsd

Rick Macklem rmacklem at uoguelph.ca
Sat Jun 30 18:33:27 UTC 2018


Andrey V. Elsukov wrote:
>On 30.06.2018 01:07, Rick Macklem wrote:
>> Author: rmacklem
>> Date: Fri Jun 29 22:07:25 2018
>> New Revision: 335806
>> URL: https://svnweb.freebsd.org/changeset/base/335806
>>
>> Log:
>>   Add support for IPv6 addresses to the "-p" option for the pNFS server DS
>>   specifications.
>>
>> +     char *mdspath, *mdsp, ip6[INET6_ADDRSTRLEN];
>> +     const char *ad;
>>       int ecode;
>> +             hints.ai_flags = AI_CANONNAME | AI_ADDRCONFIG;
>> +             hints.ai_family = PF_UNSPEC;
>>               hints.ai_socktype = SOCK_STREAM;
>>               hints.ai_protocol = IPPROTO_TCP;
>>               ecode = getaddrinfo(cp, NULL, &hints, &ai_tcp);
>>               if (ecode != 0)
>>                       err(1, "getaddrinfo pnfs: %s %s", cp,
>>                           gai_strerror(ecode));
>> +                             memcpy(&sin6, res->ai_addr, sizeof(sin6));
>> +                             ad = inet_ntop(AF_INET6, &sin6.sin6_addr, ip6,
>> +                                 sizeof(ip6));
>
>Hi,
>
>I'm unaware of applicability of IPv6 addresses with restricted scope in
>this area, but when you use inet_ntop() to get IPv6 address text
>representation, you can lost IPv6 scope zone id. getaddrinfo() can
>return sockaddr structure with properly filled sin6_scope_id field. It
>is better to use getnameinfo() with NI_NUMERICHOST flag. Also the size
>of ip6 buffer should be enough to keep scope specifier.
Thanks for mentioning this. First off, you could write what I know about IPv6
addresses on a very small postage stamp...

Are you referring to the 4bits in the second octet of the address or the stuff that
can end up as a suffix starting with"%"?

In this case, the address string is put "on the wire" for the client to use to connect
to a data server (DS). I'm not sure if the "%..." stuff is useful in this case and,
when it gets to the client, it will be translated to an address via the kernel
version of inet_pton(), which does not parse "%..." as far as I can see.

So maybe others can clarify if it would be better to use getnameinfo() for this
use case?

Thanks, rick
ps: I changed the mailing list to freebsd-nat@ so hopefully the net folks will notice.



More information about the freebsd-net mailing list