Re: IPv6 link-local addresses and init data type - Mailing list pgsql-hackers
From | Markus Wanner |
---|---|
Subject | Re: IPv6 link-local addresses and init data type |
Date | |
Msg-id | 0aa7522a-429b-d67d-23bb-a4b457bbd9ff@bluegap.ch Whole thread Raw |
In response to | Re: IPv6 link-local addresses and init data type (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Responses |
Re: IPv6 link-local addresses and init data type
|
List | pgsql-hackers |
Haribabu, On 07.06.2016 07:19, Haribabu Kommi wrote: >> 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. Yeah, I didn't find any upper limit, either. > 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 eth0 may well be interface number 1 on some machine, therefore being equivalent. However, as discussed before, Postgres cannot know, so it shouldn't bother. > 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 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...). > i will add the zone support for everything and send the patch. What's currently missing? > 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.) > 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. Note, however, that RFC 4007 only gives recommendations for textual representations (with a "should" preference for the former). It explicitly "does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses". Also note that RFC 2732 (Format for Literal IPv6 Addresses in URL's) doesn't have the '%' sign in the set of reserved characters (not even in the "unwise" one). I'm starting to question if it's really wise to add the scope id to the INET6 type... > [2] - http://stackoverflow.com/questions/24932172/what-length-can-a-network-interface-name-have Note that the scope id doesn't necessarily have to be a network interface name. Concluding there's at max 256 bytes, just because that's the network interface name's max, doesn't seem correct. However, I agree that's a reasonable limit for a scope id of the inet6 data type. Kind Regards Markus Wanner
pgsql-hackers by date: