From owner-freebsd-net@freebsd.org Sat Jun 30 21:03:02 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FA80FDB807 for ; Sat, 30 Jun 2018 21:03:02 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward106j.mail.yandex.net (forward106j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 102A18CBD1; Sat, 30 Jun 2018 21:03:01 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback1j.mail.yandex.net (mxback1j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10a]) by forward106j.mail.yandex.net (Yandex) with ESMTP id 381AF1801358; Sun, 1 Jul 2018 00:02:31 +0300 (MSK) Received: from smtp3p.mail.yandex.net (smtp3p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:8]) by mxback1j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id oAxemBRJWI-2UnmIhpa; Sun, 01 Jul 2018 00:02:31 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1530392551; bh=o4ecgV7Jse4c2V04gJ3R5e+A/+W+yb6wUovp/2MbBSI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=cf7Fqo77unkn90VYXIVkji9kTOXoUqirRytCoVwF5dy0nW4rBPswo0uUeMj9kvwjD v42LE9G1vAfXWXHxySMvA0e2OcPHy0mHQnlVuMYVrAgjOjfnk/WPdeB4ghTEPc7tRA An3hJ2b5U0BdH56eOEbW/PBxH+4v2KN2jOtGnr5o= Received: by smtp3p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id gVEgha37O2-2UxO4bk7; Sun, 01 Jul 2018 00:02:30 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1530392550; bh=o4ecgV7Jse4c2V04gJ3R5e+A/+W+yb6wUovp/2MbBSI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=YATXcPMxCR48lVeYBX3pIHEde66tI2a5035MiBrNdL19Pscy9kIiUf2nZh5zwEVf3 sTveDAcuEP2M1gvUJbXsdJAqnFNBJ2Tb6j8mvlbM51Sk16cUrQuLLzye6+LUoEJXVK fiOB+cP94sk2VFWyzLmd5FCzA/IeqK7exUBMGifo= Authentication-Results: smtp3p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: IPv6 scope handling, was Re: svn commit: r335806 - projects/pnfs-planb-server/usr.sbin/nfsd To: Rick Macklem , Rick Macklem , FreeBSD Net References: <201806292207.w5TM7QX9052770@repo.freebsd.org> <0c85d229-3b8f-3b4c-ba3c-34ec06728455@yandex.ru> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <048d1b79-f263-506c-210e-21d9e4437c3e@yandex.ru> Date: Sat, 30 Jun 2018 23:59:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5uD05bVjgapJWCJTP1JIHVo3Rh0SN83Zr" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 21:03:02 -0000 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" To: Rick Macklem , Rick Macklem , FreeBSD Net 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> In-Reply-To: --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--