Re: strange problem with ip6

I have postgresql installed on a mac, and I'm connecting from another
mac on the network using ip6. When I try to select out of
pg_stat_activity i get this error. I suspect the %en0 has something
to do with the problem, but I'm no IP6 expert.

load=# select * from pg_stat_activity ;
ERROR: invalid input syntax for type inet: "fe80::216:cbff:fe84:8ac2%
en0"
load=# select version();
version
------------------------------------------------------------------------
----------------------------------------------------------------
PostgreSQL 8.2.4 on i386-apple-darwin8.9.1, compiled by GCC i686-
apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5341)
(1 row)

load=#

Any thoughts?

--brian

On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
> I have postgresql installed on a mac, and I'm connecting from another
> mac on the network using ip6. When I try to select out of
> pg_stat_activity i get this error. I suspect the %en0 has something
> to do with the problem, but I'm no IP6 expert.

That would indeed be a problem. "%" is not a valid character in an
IPv6 text representation of the address (see RFC 4291,
<http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=4291&type=ftp&file_format=txt>).
Whether this is a bug for postgres seems to depend on whether that
reading is coming from the OS or postgres itself. (I don't know the
answer to that.)

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
> On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
>> I have postgresql installed on a mac, and I'm connecting from another
>> mac on the network using ip6. When I try to select out of
>> pg_stat_activity i get this error. I suspect the %en0 has something
>> to do with the problem, but I'm no IP6 expert.

> That would indeed be a problem. "%" is not a valid character in an
> IPv6 text representation of the address (see RFC 4291,
> <http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=4291&type=ftp&file_format=txt>).
> Whether this is a bug for postgres seems to depend on whether that
> reading is coming from the OS or postgres itself.

I enabled IPv6 on my laptop (maybe I did it wrong, dunno) and noted that
%en1 and %lo0 and similar notations were appended to some but not all of
the IPv6 addresses output by "netstat -r -n". Furthermore it seemed
that adding or not adding these notations to IPv6 addresses given to
psql's -h switch affected whether I could connect or not. I didn't see
a case where the %-thingy showed up in getnameinfo() output within
Postgres, as is apparently happening for Brian; but it sure looked like
it was happening to netstat. So Apple is doing something mighty
nonstandard here :-(. I ran out of time/interest to probe deeper.

regards, tom lane

Hi,

On Thu, 17 May 2007, Tom Lane wrote:

> Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
>> On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
>>> I have postgresql installed on a mac, and I'm connecting from another
>>> mac on the network using ip6. When I try to select out of
>>> pg_stat_activity i get this error. I suspect the %en0 has something
>>> to do with the problem, but I'm no IP6 expert.
>
>> That would indeed be a problem. "%" is not a valid character in an
>> IPv6 text representation of the address (see RFC 4291,
>> <http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=4291&type=ftp&file_format=txt>).
>> Whether this is a bug for postgres seems to depend on whether that
>> reading is coming from the OS or postgres itself.
>
> I enabled IPv6 on my laptop (maybe I did it wrong, dunno) and noted that
> %en1 and %lo0 and similar notations were appended to some but not all of
> the IPv6 addresses output by "netstat -r -n". Furthermore it seemed
> that adding or not adding these notations to IPv6 addresses given to
> psql's -h switch affected whether I could connect or not. I didn't see
> a case where the %-thingy showed up in getnameinfo() output within
> Postgres, as is apparently happening for Brian; but it sure looked like
> it was happening to netstat. So Apple is doing something mighty
> nonstandard here :-(. I ran out of time/interest to probe deeper.

fe80:: addresses adre link local addresses and only valid in the context
of a specific interface. This is why bsd based oprating systems append
%ifname to the address so that they know which Interface this address
is on.

Windows seems to append %interfacenumber. Not sure what linux does.
Propably %ethN.

Check RFC4007 IPv6 Scoped Address Architecture for details.

There is propbaly not much point in using link local addreses for postgres.
You should have global ipv6 prefix on your interfaces to really make use
of ipv6.

Greetins
Christian

--
Christian Kratzer CK Software GmbH
Email: ck(at)cksoft(dot)de Schwarzwaldstr. 31
Phone: +49 7452 889 135 D-71131 Jettingen
Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
> of a specific interface. This is why bsd based oprating systems append
> %ifname to the address so that they know which Interface this address

Oh, I forgot about that wart in RFC4007. Thanks for the cluestick.

> There is propbaly not much point in using link local addreses for postgres.

I think that's not quite right. For instance, JDBC can't use UNIX
domain sockets last I checked, and I can imagine using it in a
disconnected context where you'd want to emulate multiple connection
points. Link local addresses would be perfect for this. So I think
it might be a bug, because Postgres isn't accepting the address
specification for scoped addresses. (In the local 8.1.x version I
have installed here, the inet type doesn't accept it either.) Now
that I re-read it, RFC4007 seems to be pretty clear that the scope
info is a necessary part of the addressing, so I don't think it can
be thrown away before looking at the address.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin

Hi,

On Thu, 17 May 2007, Andrew Sullivan wrote:

> On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
>> of a specific interface. This is why bsd based oprating systems append
>> %ifname to the address so that they know which Interface this address
>
> Oh, I forgot about that wart in RFC4007. Thanks for the cluestick.
>
>> There is propbaly not much point in using link local addreses for postgres.
>
> I think that's not quite right. For instance, JDBC can't use UNIX
> domain sockets last I checked, and I can imagine using it in a
> disconnected context where you'd want to emulate multiple connection
> points. Link local addresses would be perfect for this. So I think
> it might be a bug, because Postgres isn't accepting the address
> specification for scoped addresses. (In the local 8.1.x version I
> have installed here, the inet type doesn't accept it either.) Now
> that I re-read it, RFC4007 seems to be pretty clear that the scope
> info is a necessary part of the addressing, so I don't think it can
> be thrown away before looking at the address.

supporting scoped addresses could have their uses but then again
theres nothing stopping you to bind multiple global ipv6 addresses
to your loopback interface which would work fine for disconnected
setups and it might be a bit cleaner.

Greetings
Christian

--
Christian Kratzer CK Software GmbH
Email: ck(at)cksoft(dot)de Schwarzwaldstr. 31
Phone: +49 7452 889 135 D-71131 Jettingen
Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

On Thu, May 17, 2007 at 07:29:47PM +0200, Christian Kratzer wrote:
> supporting scoped addresses could have their uses but then again
> theres nothing stopping you to bind multiple global ipv6 addresses
> to your loopback interface which would work fine for disconnected
> setups and it might be a bit cleaner.

True, but there's no unscoped private-use address space in IPv6 the
way there is in v4 (i.e. no 1918-style addresses for v6). Which
means that unless you want to use addresses that ought to be
scoped (like link-local) without a scope, you have to use real
addresses instead. Hmm. Well, I guess you could use 2001:DB8::/32,
which is reserved for documentation. I'm just worried that, because
we don't support scoped addresses, people are going to configure
things with _real_ addresses they haven't been allocated, and then
accidentally connect such a configuration to the Internet. All my
experience tells me that such things eventually always leak, and I'd
hate for Postgres to be the source of that sort of damage.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
The whole tendency of modern prose is away from concreteness.
--George Orwell

Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
> On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
>> of a specific interface. This is why bsd based oprating systems append
>> %ifname to the address so that they know which Interface this address

> Oh, I forgot about that wart in RFC4007. Thanks for the cluestick.

>> There is propbaly not much point in using link local addreses for postgres.

> I think that's not quite right. For instance, JDBC can't use UNIX
> domain sockets last I checked, and I can imagine using it in a
> disconnected context where you'd want to emulate multiple connection
> points. Link local addresses would be perfect for this. So I think
> it might be a bug, because Postgres isn't accepting the address
> specification for scoped addresses. (In the local 8.1.x version I
> have installed here, the inet type doesn't accept it either.) Now
> that I re-read it, RFC4007 seems to be pretty clear that the scope
> info is a necessary part of the addressing, so I don't think it can
> be thrown away before looking at the address.

It seems the correct solution here is to extend the inet type to support
RFC4007 "zone_id" strings. Yech. Not going to happen as a bug fix,
but we should probably put it on the TODO list.

As a temporary workaround, should we hack the server to suppress any
%-foo found in the result of getnameinfo()?

regards, tom lane

Hi,

On Thu, 17 May 2007, Andrew Sullivan wrote:

> On Thu, May 17, 2007 at 07:29:47PM +0200, Christian Kratzer wrote:
>> supporting scoped addresses could have their uses but then again
>> theres nothing stopping you to bind multiple global ipv6 addresses
>> to your loopback interface which would work fine for disconnected
>> setups and it might be a bit cleaner.
>
> True, but there's no unscoped private-use address space in IPv6 the
> way there is in v4 (i.e. no 1918-style addresses for v6). Which
> means that unless you want to use addresses that ought to be
> scoped (like link-local) without a scope, you have to use real
> addresses instead. Hmm. Well, I guess you could use 2001:DB8::/32,
> which is reserved for documentation. I'm just worried that, because
> we don't support scoped addresses, people are going to configure
> things with _real_ addresses they haven't been allocated, and then
> accidentally connect such a configuration to the Internet. All my
> experience tells me that such things eventually always leak, and I'd
> hate for Postgres to be the source of that sort of damage.

thats what I also thought. Using link local addresses for real
applications is propably not quite what I would call "best practice"
but it will happen when people just turn on ipv6 and check what their
shiny new address looks like.

It's not that simple though. The ipv6 stack will propably not allow
users to build sockets from addresses in link local scope from a
specific interface to a server bound to a global address, ::1, or
scoped to any other interface. After all link local means exactly
this.

So if you have your postgres listening on ::1 you will not be
able to connect from your fe80::dead:beef%fxp0 address.

All in all it seems to me its best to leave everything as it is.

Greetings
Christian

>
> A
>
> --
> Andrew Sullivan | ajs(at)crankycanuck(dot)ca
> The whole tendency of modern prose is away from concreteness.
> --George Orwell
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
>
>

--
Christian Kratzer CK Software GmbH
Email: ck(at)cksoft(dot)de Schwarzwaldstr. 31
Phone: +49 7452 889 135 D-71131 Jettingen
Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

On Thu, May 17, 2007 at 02:39:55PM -0400, Tom Lane wrote:
> It seems the correct solution here is to extend the inet type to support
> RFC4007 "zone_id" strings. Yech. Not going to happen as a bug fix,
> but we should probably put it on the TODO list.
>
> As a temporary workaround, should we hack the server to suppress any
> %-foo found in the result of getnameinfo()?

Well, Christian's point about scoped versus global addresses is a
good one, so there might be an argument for leaving it alone, on the
grounds that you ought not to be able to come from there. On the
other hand, since people are tripping over the feature right now,
they obviously _are_ able to come from there. So maybe just hacking
it up is the best answer for the time being. (I'm slightly more
concerned that the inet datatype apparently has this issue too,
because it would seem that it's rejecting perfectly well-formed
input, which is surely bad.)

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
Everything that happens in the world happens at some place.
--Jane Jacobs

Hi,

On Thu, 17 May 2007, Tom Lane wrote:
<snipp/>
> It seems the correct solution here is to extend the inet type to support
> RFC4007 "zone_id" strings. Yech. Not going to happen as a bug fix,
> but we should probably put it on the TODO list.

propably yes. But we should bear in mind that addresses of different
scopes are not comparable with each other in the sense of apples vs.
oranges.

i.e:

select 'fe80::1%em0'::inet = 'fe80::1%em1'::inet;

should return null.

Also how do we define sort order if not all values are comparable.

> As a temporary workaround, should we hack the server to suppress any
> %-foo found in the result of getnameinfo()?

Not sure what that would buy us. Stripping the scope from the address
does not seem the right thing to do.

Extending the generic inet type with scoped addresss is another question.

Greetings
Christian

--
Christian Kratzer CK Software GmbH
Email: ck(at)cksoft(dot)de Schwarzwaldstr. 31
Phone: +49 7452 889 135 D-71131 Jettingen
Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

Christian Kratzer <ck-lists(at)cksoft(dot)de> writes:
> On Thu, 17 May 2007, Tom Lane wrote:
>> As a temporary workaround, should we hack the server to suppress any
>> %-foo found in the result of getnameinfo()?

> Not sure what that would buy us.

Mostly, it would buy us not having pg_stat_activity fail completely
whenever someone is connected over a scoped connection.

regards, tom lane

Christian Kratzer <ck-lists(at)cksoft(dot)de> writes:
> It's not that simple though. The ipv6 stack will propably not allow
> users to build sockets from addresses in link local scope from a
> specific interface to a server bound to a global address, ::1, or
> scoped to any other interface. After all link local means exactly
> this.

> So if you have your postgres listening on ::1 you will not be
> able to connect from your fe80::dead:beef%fxp0 address.

But if you tell it to listen to *, won't it bind to everything in sight?
In particular we know that this thread started because someone had a
connection through a scoped address, so one way or another it's possible.

regards, tom lane

Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
> On Thu, May 17, 2007 at 02:39:55PM -0400, Tom Lane wrote:
>> It seems the correct solution here is to extend the inet type to support
>> RFC4007 "zone_id" strings. Yech. Not going to happen as a bug fix,
>> but we should probably put it on the TODO list.
>>
>> As a temporary workaround, should we hack the server to suppress any
>> %-foo found in the result of getnameinfo()?

> Well, Christian's point about scoped versus global addresses is a
> good one, so there might be an argument for leaving it alone, on the
> grounds that you ought not to be able to come from there. On the
> other hand, since people are tripping over the feature right now,
> they obviously _are_ able to come from there. So maybe just hacking
> it up is the best answer for the time being.

Agreed, and done. I found btw that "fe80::something%lo0" works
perfectly well in pg_hba.conf ... so there are parts of the code
able to handle this already.

> (I'm slightly more
> concerned that the inet datatype apparently has this issue too,
> because it would seem that it's rejecting perfectly well-formed
> input, which is surely bad.)

Well, let's be clear: this is entirely the fault of the inet type not
accepting what we now know to be RFC-compliant address specifications.
So we ought to put fixing that on the TODO list. It's not happening
for 8.3 though, let alone in existing release branches, so we'd best
put in a workaround until it's there.

regards, tom lane

Tom Lane wrote:
> Well, let's be clear: this is entirely the fault of the inet type not
> accepting what we now know to be RFC-compliant address specifications.
> So we ought to put fixing that on the TODO list. It's not happening
> for 8.3 though, let alone in existing release branches, so we'd best
> put in a workaround until it's there.

Already added to TODO.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Hi,

On Thu, 17 May 2007, Tom Lane wrote:

> Christian Kratzer <ck-lists(at)cksoft(dot)de> writes:
>> It's not that simple though. The ipv6 stack will propably not allow
>> users to build sockets from addresses in link local scope from a
>> specific interface to a server bound to a global address, ::1, or
>> scoped to any other interface. After all link local means exactly
>> this.
>
>> So if you have your postgres listening on ::1 you will not be
>> able to connect from your fe80::dead:beef%fxp0 address.
>
> But if you tell it to listen to *, won't it bind to everything in sight?

yes.

> In particular we know that this thread started because someone had a
> connection through a scoped address, so one way or another it's possible.

thats propably exactly how it happened. I agree now that a workaround
is needed until the inet types supports scoped addresses.

Greetings
Christian

--
Christian Kratzer CK Software GmbH
Email: ck(at)cksoft(dot)de Schwarzwaldstr. 31
Phone: +49 7452 889 135 D-71131 Jettingen
Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer