On 06/03/2016 12:14 AM, Tom Lane wrote: > Markus Wanner <mar...@bluegap.ch> writes: >> I'm even wondering if 'fe80::1%1'::inet = 'fe80::1%2'::inet shouldn't >> simply yield true. After all, it's the same (non-global) address. > > Surely not? If the zone_ids didn't mean anything, why would the concept > even exist? ISTM that what you've got there is two different addresses > neither of which is reachable from outside the given machine --- but > within that machine, they are different.
You are right, both of these addresses actually are considered different from 'fe80::1', i.e. I cannot ping6 fe80::1, but need to explicitly specify an interface - either via an additional argument or with the percent notation. That's interesting news to me, as this means that only global IPv6 addresses can be stored in 128 bits. For non-global ones that's not sufficient and 'fe80::1' isn't even considered a valid address by itself. Checking the headers and manpages, the sockaddr_in6 sports an uint32_t sin6_scope_id (as per RFC 2553). Then, there also is the embedded form which uses the 2nd 16-bit word of the IPv6 address to store the scope id, see for example "220.127.116.11 Scope Index" in . However, that document also clearly states: "When you specify scoped address to the command line, NEVER write the embedded form (such as ff02:1::1 or fe80:2::fedc)". Given that interfaces are addressed by index internally, I'm pretty sure the two representations are equivalent (i.e. if eth3 currently happens to be the 7th interface , then 'fe80::1%eth3' resolves to 'fe80::1%7'). Considering that Postgres is not unlikely to write INET types to permanent storage, its values should better survive a reboot. And while I have some doubts about persistence of interface names, those clearly have a higher chance of surviving a reboot compared to interface indices. Therefore, I'd advocate resolving interface indices (if given) to interface names using if_indextoname(3) and let INET types store only names. Assuming such an implementation, the following would hold (assuming an example system as mentioned above): 'fe80::1%1'::inet != 'fe80::1%2'::inet but: 'fe80::1%7'::inet = 'fe80::1%eth3'::inet I also tend to deny scope ids for global addresses (like ping6), but allow non-global ('fe80::1') addresses to be stored without an interface name, as pre-existing applications may rely on that to work (unlike ping6). Does that sound like a more reasonable plan? Kind Regards Markus Wanner : FreeBSD dev handbook, Section 18.104.22.168: Scope Index: https://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers