Date: Sat, 30 Jun 2018 23:59:19 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Rick Macklem <rmacklem@uoguelph.ca>, Rick Macklem <rmacklem@FreeBSD.org>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: IPv6 scope handling, was Re: svn commit: r335806 - projects/pnfs-planb-server/usr.sbin/nfsd Message-ID: <048d1b79-f263-506c-210e-21d9e4437c3e@yandex.ru> In-Reply-To: <YTOPR0101MB09532F60F2905ECA610DF86DDD4D0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> References: <201806292207.w5TM7QX9052770@repo.freebsd.org> <0c85d229-3b8f-3b4c-ba3c-34ec06728455@yandex.ru> <YTOPR0101MB09532F60F2905ECA610DF86DDD4D0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5uD05bVjgapJWCJTP1JIHVo3Rh0SN83Zr Content-Type: multipart/mixed; boundary="TsWq0gkOH73dXBohZ8jzh9nN9nH86z854"; protected-headers="v1" From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Rick Macklem <rmacklem@uoguelph.ca>, Rick Macklem <rmacklem@FreeBSD.org>, FreeBSD Net <freebsd-net@freebsd.org> Message-ID: <048d1b79-f263-506c-210e-21d9e4437c3e@yandex.ru> Subject: Re: IPv6 scope handling, was Re: svn commit: r335806 - projects/pnfs-planb-server/usr.sbin/nfsd References: <201806292207.w5TM7QX9052770@repo.freebsd.org> <0c85d229-3b8f-3b4c-ba3c-34ec06728455@yandex.ru> <YTOPR0101MB09532F60F2905ECA610DF86DDD4D0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <YTOPR0101MB09532F60F2905ECA610DF86DDD4D0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> --TsWq0gkOH73dXBohZ8jzh9nN9nH86z854 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 30.06.2018 21:33, Rick Macklem wrote: >> I'm unaware of applicability of IPv6 addresses with restricted scope i= n >> 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 abou= t IPv6 > addresses on a very small postage stamp... >=20 > Are you referring to the 4bits in the second octet of the address or th= e stuff that > can end up as a suffix starting with"%"? RFC4007 defines scopes of IPv6 addresses. The important part of this is that a host can have several interfaces (links) and each interface can have the same unicast IPv6 address, but the scope of these addresses will be restricted by these links. I.e. IPv6 link-local address from e.g. igb0 interface can be used only within igb0, and the same address on the igb1 interface can be used only within igb1. And neighbor hosts on these links can have the same addresses, but they will not be reachabl= e: [neighbor1 fe80::100]<-->[fe80::1%igb0 | fe80::1%igb1]<-->[fe80::100 neighbor2] neighbor1 can not reach neighbor2, since these addresses belongs to different scope zones. On the host with two interfaces you as user can use link-local addresses and can specify such addresses in application. To disambiguate them you must specify scope zone identifier, "%igb0" or "%igb1". E.g. if you want to connect with neighbor1, you can use "telnet fe80::100%igb0 someport" and the kernel will initiate connection with neighbor1 through igb0. inet_ntop() call doesn't support this. KAME-based IPv6 stack uses the second 16-bits word of the address to store scope zone id. It is hack and user applications should not use it, and should not rely on this hack. The struct sockaddr_in6 has special field sin6_scope_id to specify scope zone id. Note, that the size of this field is 32-bits. If you want to support such addresses, you need to use scope zones aware API - getaddrinfo()/getnameinfo(). Together with using such API you will need to use struct sockaddr_in6, or keep zone id separately. In the kernel when you operate with IPv6 link-local addresses you need to properly prepare them in the IPv6 header, i.e. embed scope zone identifier. Otherwise the kernel will fail to send such packets. > 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 th= is 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= =2E >=20 > So maybe others can clarify if it would be better to use getnameinfo() = for this > use case? --=20 WBR, Andrey V. Elsukov --TsWq0gkOH73dXBohZ8jzh9nN9nH86z854-- --5uD05bVjgapJWCJTP1JIHVo3Rh0SN83Zr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAls37ycACgkQAcXqBBDI oXq9ngf8CrBegzjQ27nhuDT1t+F2TADwGtp14yv0UQtf7PismwmbONTjWUQceMvP LMuAUIJB/mBSXird0rPPn8L8dXPzD29mW01DJXNB3d6kuZhJ2m7m+lS9+DJr1Z+u dzZHEyxhd48aChey8s3smiQVFEuUA3QI6OMVBpsjGUw2q9nIFd82d0zILx5EEJUF 1FsuY/D9hhBHe2yA7DISw8v6E6qOwtDyjdOs9wfiYmjcTa/KN/zn5dfwjqJJsZZ+ hr5WVZNj2LmAnkLfXhvItC2UcyduhzkbFOzWUSITAxB9ddrvSksjkgG9HDenKJgt R3comk3Tjx5utmKgJjK4aWeu8e/r3g== =ktLt -----END PGP SIGNATURE----- --5uD05bVjgapJWCJTP1JIHVo3Rh0SN83Zr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?048d1b79-f263-506c-210e-21d9e4437c3e>