Re: IPv6 link-local addresses and init data type

On Fri, Nov 4, 2016 at 6:33 AM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 6/7/16 2:43 PM, Peter Eisentraut wrote:
> > On 6/7/16 1:19 AM, Haribabu Kommi wrote:
> >> How about the following case, Do we treat them as same or different?
> >>
> >> select 'fe80::%eth1'::inet = 'fe80::%ETH1'::inet;
> >>
> >> fe80::%2/64 is only treated as the valid address but not other way as
> >> fe80::/64%2.
> >> Do we need to throw an error in this case or just ignore.
> >
> > I suspect questions like these are already solved in someone else's IP
> > address type/object/class implementation, and we could look there.
>
> I have been doing some testing and reviewed the RFCs again. I'm having
> some second thoughts about this.
>
> I tried the IP address parsing modules in Perl, Python, Ruby, and they
> all reject zone IDs.
>
> The Java class java.net.Inet6Address accepts zone IDs, but only numbers
> and names actually present on the local host.
>

Thanks for the review and analyzing other modules behavior.

> RFC 4007 specifies that the zone IDs "should" not be used for global
> addresses or the loopback address. The presented patch does not check
> for that.
>

I will add the check.

>
> The original message in this thread mentioned an address "::1%0", so
> that is not even valid. 0 is supposed to be the default zone, so one
> could argue that that can be silently accepted.
>

Yes, I agree that default zone is the main use case of the original thread.
From the RFC 4007, the default zone is used for the global addresses,
This may be the main use case with zone id. How about currently just
ignoring it and store the actual IP address with the attached patch and
handle the rest of the actual zone id support later once the it gets
properly standardized?

> A zone ID is only meaningful inside a node. So storing it in a table
> without an associated node is meaningless. (compare: storing a time
> with time zone without a date)
>
> There are also questions about comparing addresses with zone IDs, such
> as in the example at the very top. We don't have a good answer on
> whether those addresses should be equal. (My OS seems to think that
> interface names are case-insensitive.) Also, since there is no node
> associated with the address, it's questionable what equal really means
> anyway.
>
> So I'm having doubts that the proposed change to allow any string to be
> appended to any address is really sound. This could invite a lot of
> shenanigans, where equality comparisons or range operations are
> subverted, for example.

Currently there is lack of information to decide for the above problems from
the RFC, may be lets wait for the standardization to be clear and then
support zone id by adding minimal support for default zone?

Regards,
Hari Babu
Fujitsu Australia