Re: IPv6 link-local addresses and init data type

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Andreas Karlsson <andreas(at)proxel(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Tom Dunstan <pgsql(at)tomd(dot)cc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: IPv6 link-local addresses and init data type
Date: 2016-06-02 21:48:52
Message-ID: 5750A9C4.6020104@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31.05.2016 12:40, Andreas Karlsson wrote:
> On 05/31/2016 04:06 AM, Tom Lane wrote:
>> Unless there's a semantic difference between fe80::1%2/64 and
>> fe80::1/64%2, this doesn't seem like a big deal to me.
>
> As far as I can till only fe80::1%2/64 is valid, but I am not 100% sure.

According to RFC 4007, Section 11.7 states: "In this combination, it is
important to place the zone index portion before the prefix length when
we consider parsing the format by a name-to-address library function
[11]. That is, we can first separate the address with the zone index
from the prefix length, and just pass the former to the library function."

However, in the sense of being liberal in what you accept, 'fe80::/64%2'
should probably work as well.

Given that a zone_id is a) highly system dependent and b) only ever
meaningful for non-global addresses, I'm wondering what the use case for
storing them is.

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.

Kind Regards

Markus Wanner

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-02 22:14:22 Re: IPv6 link-local addresses and init data type
Previous Message Corey Huinker 2016-06-02 20:48:17 Let file_fdw access COPY FROM PROGRAM