Re: IPv6 link-local addresses and init data type - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: IPv6 link-local addresses and init data type
Date
Msg-id CAJrrPGdrkoAEJwpfi3vBDg9dE_NL9kWjkQfvD5tr6DmtXSFWWw@mail.gmail.com
Whole thread Raw
In response to Re: IPv6 link-local addresses and init data type  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: IPv6 link-local addresses and init data type
Re: IPv6 link-local addresses and init data type
List pgsql-hackers
On Sat, Jun 4, 2016 at 1:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Yeah, but what if somebody doesn't want to store scopes?
>
> [ shrug... ]  We can invent a "strip_scope()" sort of function,
> analogous to the weight-stripping function for tsvectors, or several
> other examples.  That's a really lame excuse for not being *able*
> to store scopes.
>
>>
ff::1%fourscoreandsevenyearsagoourforefathersbroughtforthonthiscontinentanewnationconceivedinlibertyanddedicatedtothepropositionthatlallmenarecreatedequal
>
> I have not looked at the spec, but I wouldn't be surprised if there
> were an upper limit on the length of valid scope names.

I am not able to find any link that suggests the maximum length of the scope id.
>From [1], I came to know that, how the scope id is formed in different operating
systems.

windows - fe80::3%1
unix systems - fe80::3%eth0

>From [2], the maximum interface name allowed in linux is 16 bytes and windows
256 bytes. Any way for windows the zone id is a number index to the interface.

I added another character array of 256 member into inet_struct as a last member
to store the zone id. Modified the inet_cidr_pton_ipv6 function to handle '%'.
Currently all the printable characters are treated as zone id's. I
will restrict this
to only alphabets and numbers.

Here I attached POC patch that adds the support of storing ipv6 with scope id
in the inet datatype.

Approach of adding the member to the structure and storing is fine or any better
way to handle the same? If we come to an conclusion on the approach, i will
add the zone support for everything and send the patch.

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.


[1] - https://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_indices
[2] - http://stackoverflow.com/questions/24932172/what-length-can-a-network-interface-name-have

Regards,
Hari Babu
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: COMMENT ON, psql and access methods
Next
From: Noah Misch
Date:
Subject: Re: parallel.c is not marked as test covered