Re: IPv6 link-local addresses and init data type

On Wed, Jun 29, 2016 at 6:31 AM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
>> I added another character array of 256 member into inet_struct as a last member
>> to store the zone id.
>
> I haven't looked at the patch in detail, but zeroing or memcpy'ing those
> 256 bytes seems like overkill to me. I'd recommend to limit this to only
> allocate and move around as many bytes as needed for the scope id.

Currently a static structure members are passed to the inet_net_pton function
to fill the data, to make it simple i added a member to store the zoneid in the
structure.

>> Currently all the printable characters are treated as zone id's. I
>> will restrict this
>> to only alphabets and numbers.
>
> I fear alphanumeric only is too restrictive. RFC 4007 only specifies
> that the zone id "must not conflict with the delimiter character" and
> leaves everything beyond that to the implementation (which seems too
> loose, printable characters sounds about right to me...).

Ok. Currently the patch supports all printable characters, except '/' that is
reserved for specifying the bits.

>> How about the following case, Do we treat them as same or different?
>>
>> select 'fe80::%eth1'::inet = 'fe80::%ETH1'::inet;
>
> Let's be consistent in not interpreting the scope id in any way, meaning
> those would be different. (After all, interfaces names seem to be case
> sensitive - on my variant of Linux at the very least - i.e. ETH1 cannot
> be found, while eth1 can be.)

Added a case sensitive comparison for zoneid.

>> 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 didn't find any evidence for the second case being invalid; nor for it
> being valid.

Yes, that's correct. Second one invalid. Patch throws an error.

>I'm starting to question if it's really wise to add the scope id to the
>INET6 type...

I didn't find any major database that support inet datatype, which is good
for storing IP address. I feel it may be better to extend it to support new
IP enhancements.

Updated patch is attached. Docs and tests are pending.

Regards,
Hari Babu
Fujitsu Australia