Date: Sun, 1 Jul 2018 00:30:57 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "Andrey V. Elsukov" <bu7cher@yandex.ru>, 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: <YTOPR0101MB09536FD714DA6AEB25D35DFCDD4C0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <048d1b79-f263-506c-210e-21d9e4437c3e@yandex.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey V. Elsukov wrote: >On 30.06.2018 21:33, Rick Macklem wrote: >>> 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"%"? > >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 reachable= : > >[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. Ok, I think I follow that. I didn't explain what this case is... 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 to HostB.) I think what you are saying above is that a Link-local address won't work and that the address must be a global one? Should the code check for "fe8" at the start and skip over those ones? The "on-the-wire" address sent to HostC is specified in standard string for= m (can't remember the RFC#, but it is referenced by RFC5661), so I can't send any more than that to HostC. >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] >> >> So maybe others can clarify if it would be better to use getnameinfo() f= or this >> use case? Thanks for your comments sofar. I'm still not sure what I should be sending to HostC? rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB09536FD714DA6AEB25D35DFCDD4C0>