Date: Sun, 1 Jul 2018 13:53:03 +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: <1e62847a-fe06-9190-ac98-ce120e96f325@yandex.ru> In-Reply-To: <YTOPR0101MB09536FD714DA6AEB25D35DFCDD4C0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> References: <201806292207.w5TM7QX9052770@repo.freebsd.org> <0c85d229-3b8f-3b4c-ba3c-34ec06728455@yandex.ru> <YTOPR0101MB09532F60F2905ECA610DF86DDD4D0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> <048d1b79-f263-506c-210e-21d9e4437c3e@yandex.ru> <YTOPR0101MB09536FD714DA6AEB25D35DFCDD4C0@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) --JxV3f7m17jRishiJFAFgxsVGGlVdDE3zT Content-Type: multipart/mixed; boundary="J8Cl7koHUPE8iNBRMH1a347jE5qicCoJS"; 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: <1e62847a-fe06-9190-ac98-ce120e96f325@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> <048d1b79-f263-506c-210e-21d9e4437c3e@yandex.ru> <YTOPR0101MB09536FD714DA6AEB25D35DFCDD4C0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <YTOPR0101MB09536FD714DA6AEB25D35DFCDD4C0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> --J8Cl7koHUPE8iNBRMH1a347jE5qicCoJS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01.07.2018 03:30, Rick Macklem via freebsd-net wrote: >> [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= =2E >> To disambiguate them you must specify scope zone identifier, "%igb0" o= r >> "%igb1". E.g. if you want to connect with neighbor1, you can use "teln= et >> fe80::100%igb0 someport" and the kernel will initiate connection with >> neighbor1 through igb0. inet_ntop() call doesn't support this. > Ok, I think I follow that. I didn't explain what this case is... >=20 > The code for this patch runs on HostA. > If looks up an address for HostB, but not so it can connect to HostB. > It sends the address to HostC, so that HostC can connect to HostB. > (So the address needed is the address that HostC would use to connect t= o > HostB.) > > I think what you are saying above is that a Link-local address won't wo= rk > and that the address must be a global one? > Should the code check for "fe8" at the start and skip over those ones? It is possible that all hosts are in the same scope zone, e.g. they are connected in the one broadcast domain through the switch. In this case it is possible to use link-local addresses and they all will be reachable. > The "on-the-wire" address sent to HostC is specified in standard string= form > (can't remember the RFC#, but it is referenced by RFC5661), so I can't = send > any more than that to HostC. So if I understand correctly, after formatting you are sending this address string to the some foreign host? The scope zone id specifier is only does matter for the host where it is used. I.e. there is no sense to send "%ifname" to the foreign host, because it can have different ifname for the link and that address specification won't work. I think for now we can leave the code as is (put some XXX with comment here), and then in the future, if it will be needed, add better handling for that :) >> 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. > How would HostA know what HostC should use? > (I don't think it can know?) > [stuff snipped] The possible solution can be: * for the sending host use scope zone id to determine proper interface to send through; * for the receiving host track the receiving interface and if given address is link-local, recover the scope zone id from the receiving interface. --=20 WBR, Andrey V. Elsukov --J8Cl7koHUPE8iNBRMH1a347jE5qicCoJS-- --JxV3f7m17jRishiJFAFgxsVGGlVdDE3zT 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/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAls4so8ACgkQAcXqBBDI oXr9awf/eLEaWZKak08CTr2VCrUeDUVYlGu6SVuYtH+Je0EeJoA+tnaBfjfbVcAd QbzuPTWUaPImeHLMrX8LCE2kxg5lsxHaP5y+bxJxCbO8AjagRjiIpBI77YxrGhkY vn9p+X/zhLXxjyALJ7v0Kv53f1wGC6kp0cFbmBe7KR8EnTpLr+iK9Q0mmIWnIbB1 1ZonBcLpnSMrXLPFb3x7hgAsKy9dzAvDRGQ3zEgLioLbaf+AV/t4Qu3FDcxzgHau 2O0NDRkY6b/9poL4kqQvXlYlUj6r3/fYpPmbRzqlf9ieW4zBulLEUc5lnuCqj0X4 EHFbLftCMqBvZAOwAIbfdfSHvrdMJA== =zmfq -----END PGP SIGNATURE----- --JxV3f7m17jRishiJFAFgxsVGGlVdDE3zT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1e62847a-fe06-9190-ac98-ce120e96f325>