IPv6 patch

Patch applied. I added a small mention of IPv6 addresses to the
pg_hba.conf documentation. Not sure where else to mention it.

---------------------------------------------------------------------------

Bruce Momjian wrote:

I have been working on a patch to implement IPv6 connections. A working
patch was supplied by Nigel Kukard about two weeks ago, and I have been
improving it. The original patch assumed the system has IPv6 functions,
like getaddrinfo(), so the major work was patching it into our existing
code that doesn't use IPv6 functions, so systems with/without IPv6 will
be able to compile the same code.

The patch is at:

ftp://candle.pha.pa.us/pub/postgresql/mypatches/ipv6.full

It has a configure test to determine if getaddrinfo() exists, and sets a
#define and a Makefile variable appropriately. Most of the changes are
in backend/libpq/pqcomm.c::StreamServerPort and
interfaces/libpq/fe-connect.c::connectDBStart. There are also two new
files, ip.c and ip.h, which contain IP-specific support functions.

I have done my best to make the code as clear as possible. There are
more define tests than I would like, but I am hesitant to split out more
of the code into almost duplicate functions for IPv4 and IPv6
functionality.

I have tested the code using IPv6 functions, and IPv4 functions. The
system also has no IPv6 support in the kernel, so that has also been
tested.

The patch is about a week away from being applied, but I thought I would
post the URL so folks can see where I am going. I am interested in
improvements and testing with various configurations.

FYI, I am also working with someone on the openprojects IRC channel
#ipv6 on an IPv6 data type.

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

Patch applied. I added a small mention of IPv6 addresses to the
pg_hba.conf documentation. Not sure where else to mention it.

Can this patch please be cleaned up so the code doesn't contain an #ifdef
on every other line?

I would also like to discuss how IPv6 is handled during the server start
and in pg_hba.conf. It seems that we should treat the address families
Unix, IPv4, and IPv6 consistenly, which would mean two things:

(1) pg_hba.conf entries pertaining to the address family are allowed and
present in the default file, no matter whether the address family is used
by the server.

(2) A socket type is explicitly enabled for the server to use, and if
creation fails, server startup fails. It seems that the current code
falls back to IPv4 if IPv6 fails.

--
Peter Eisentraut peter_e@gmx.net

On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote:

(2) A socket type is explicitly enabled for the server to use, and if
creation fails, server startup fails. It seems that the current code
falls back to IPv4 if IPv6 fails.

IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6
support but the kernel isn't compiled to support IPv6. If that is the
case, admittedly, you seem to have a point. If someone compiles in v6
support and their system doesn't have v6 support and it's been requested
via run-time config, it's should fail just like any other.

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Peter Eisentraut wrote:

Bruce Momjian writes:

Patch applied. I added a small mention of IPv6 addresses to the
pg_hba.conf documentation. Not sure where else to mention it.

Can this patch please be cleaned up so the code doesn't contain an #ifdef
on every other line?

I posted the patch a week ago, and mentioned this exact problem. Any
suggestions? I realized I could break out the parts into IPv4/6
sections, but then I would have duplicate code paths that were identical
except for the IPv4/6 calls. Is that the way to go? The major ugliness
is in pqcomm.c and fe-connect.c. Add the unix domain socket and SSL
defines, and it is a mess. However, the danger of breaking out the code
into separate routines is that then we have to keep them consistent if
we make any changes.

I would also like to discuss how IPv6 is handled during the server start
and in pg_hba.conf. It seems that we should treat the address families
Unix, IPv4, and IPv6 consistenly, which would mean two things:

(1) pg_hba.conf entries pertaining to the address family are allowed and
present in the default file, no matter whether the address family is used
by the server.

(2) A socket type is explicitly enabled for the server to use, and if
creation fails, server startup fails. It seems that the current code
falls back to IPv4 if IPv6 fails.

The issue is that right now, there isn't any special IPv6 enabling,
except for lines in pg_hba.conf. I think it is fine to add some
enabling, but we then have an additional user interface issue. One idea
I had was to change tcpip_socket from true/false to true/false/4/6 so
you can specify if you want none(false)/4/6/both(true). The original
patch author wants this functionality too, so there clearly is a need
for this. This doesn't play nice with the -i flag, however.

Also, I need help specifying to listen on _just_ IPv4 or IPv6. The way it
is coded, you open IPv6 and IPv4 comes along with it. We could add some
test that checks _after_ the connection is made and reject IPv4/6, but
it would be better to listen _just_ on the IP version specified. I am
not sure how to do that, and the #ipv6 IRC channel wasn't clear either.
I tried Google but didn't get a clear answer there either.

Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6
isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true,
but when run, opening an IPV6 server fails and I fall back to IPv4 ---
just throwing that out as a data point. What would be our default as
shipped?

I do think we need some user interface control over IPv6 and IPv4. I
just coded it to get it working, and compilable on most platforms, and
then we can iron out these issues.

If we have an IPv6 enablement, it would allow us to keep the pg_hba.conf
IPv6 line, and just ignore it, or throw a warning in the logs, though if
it is by default in pg_hba.conf, a warning seems strange.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Greg Copeland wrote:

On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote:

(2) A socket type is explicitly enabled for the server to use, and if
creation fails, server startup fails. It seems that the current code
falls back to IPv4 if IPv6 fails.

IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6
support but the kernel isn't compiled to support IPv6. If that is the
case, admittedly, you seem to have a point. If someone compiles in v6
support and their system doesn't have v6 support and it's been requested
via run-time config, it's should fail just like any other.

Yes, right now, it is kind of a mystery when it falls back to IPv4. It
does print a message in the server logs:

LOG: server socket failure: getaddrinfo2() using IPv6: hostname nor servname provided, or not known
LOG: IPv6 support disabled --- perhaps the kernel does not support IPv6
LOG: IPv4 socket created

It appears right at the top because creating the socket is the first
thing it does. A good question is once we have a way for the user to
control IPv4/6, what do we ship as a default? IPv4-only? Both, and if
both, do we fail on a kernel that doesn't have IPv6 enabled?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2003-01-06 at 15:43, Bruce Momjian wrote:

Greg Copeland wrote:

On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote:

(2) A socket type is explicitly enabled for the server to use, and if
creation fails, server startup fails. It seems that the current code
falls back to IPv4 if IPv6 fails.

IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6
support but the kernel isn't compiled to support IPv6. If that is the
case, admittedly, you seem to have a point. If someone compiles in v6
support and their system doesn't have v6 support and it's been requested
via run-time config, it's should fail just like any other.

Yes, right now, it is kind of a mystery when it falls back to IPv4. It
does print a message in the server logs:

LOG: server socket failure: getaddrinfo2() using IPv6: hostname nor servname provided, or not known
LOG: IPv6 support disabled --- perhaps the kernel does not support IPv6
LOG: IPv4 socket created

It appears right at the top because creating the socket is the first
thing it does. A good question is once we have a way for the user to
control IPv4/6, what do we ship as a default? IPv4-only? Both, and if
both, do we fail on a kernel that doesn't have IPv6 enabled?

So you're saying that by using the IPv6 address family and you bind to
an IPv6 address (or even ANY interface), you still get v4 connections on
the same bind/listen/accept sequence?

I'm asking because I've never done v6 stuff.

Regards,

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Greg Copeland wrote:

It appears right at the top because creating the socket is the first
thing it does. A good question is once we have a way for the user to
control IPv4/6, what do we ship as a default? IPv4-only? Both, and if
both, do we fail on a kernel that doesn't have IPv6 enabled?

So you're saying that by using the IPv6 address family and you bind to
an IPv6 address (or even ANY interface), you still get v4 connections on
the same bind/listen/accept sequence?

I'm asking because I've never done v6 stuff.

Yes, it listens on both. The original author, Nigel, tested in using
both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem
to indicate that too. What I am not sure how to do is say _only_ IPv4.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:

Greg Copeland wrote:

It appears right at the top because creating the socket is the first
thing it does. A good question is once we have a way for the user to
control IPv4/6, what do we ship as a default? IPv4-only? Both, and if
both, do we fail on a kernel that doesn't have IPv6 enabled?

So you're saying that by using the IPv6 address family and you bind to
an IPv6 address (or even ANY interface), you still get v4 connections on
the same bind/listen/accept sequence?

I'm asking because I've never done v6 stuff.

Yes, it listens on both. The original author, Nigel, tested in using
both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem
to indicate that too. What I am not sure how to do is say _only_ IPv4.

Wouldn't you just use an IPv4 address family when creating your socket?

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Greg Copeland wrote:

On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:

Greg Copeland wrote:

It appears right at the top because creating the socket is the first
thing it does. A good question is once we have a way for the user to
control IPv4/6, what do we ship as a default? IPv4-only? Both, and if
both, do we fail on a kernel that doesn't have IPv6 enabled?

So you're saying that by using the IPv6 address family and you bind to
an IPv6 address (or even ANY interface), you still get v4 connections on
the same bind/listen/accept sequence?

I'm asking because I've never done v6 stuff.

Yes, it listens on both. The original author, Nigel, tested in using
both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem
to indicate that too. What I am not sure how to do is say _only_ IPv4.

Wouldn't you just use an IPv4 address family when creating your socket?

Sorry, I meant only IPv6.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2003-01-06 at 16:17, Bruce Momjian wrote:

Greg Copeland wrote:

On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:

Greg Copeland wrote:

It appears right at the top because creating the socket is the first
thing it does. A good question is once we have a way for the user to
control IPv4/6, what do we ship as a default? IPv4-only? Both, and if
both, do we fail on a kernel that doesn't have IPv6 enabled?

So you're saying that by using the IPv6 address family and you bind to
an IPv6 address (or even ANY interface), you still get v4 connections on
the same bind/listen/accept sequence?

I'm asking because I've never done v6 stuff.

Yes, it listens on both. The original author, Nigel, tested in using
both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem
to indicate that too. What I am not sure how to do is say _only_ IPv4.

Wouldn't you just use an IPv4 address family when creating your socket?

Sorry, I meant only IPv6.

I found this. It seems to imply that you need different sockets to do
what you want to do. You might snag a copy of the latest openldap code
and look at slapd to see what it's doing.

At any rate, here's what I found that pointed me at it:

slapd compiled with --enable-ipv6 does only listen to the IPv6 connections. I
suspect this is tested on an operating system that receives IPv4 connections to
the IPv6 socket as well, although this is not not the case for OpenBSD (nor
FreeBSD or NetBSD ,IIRC). slapd needs to listen to both IPv4 and IPv6 on
separate sockets.

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Greg Copeland wrote:

Yes, it listens on both. The original author, Nigel, tested in using
both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem
to indicate that too. What I am not sure how to do is say _only_ IPv4.

Wouldn't you just use an IPv4 address family when creating your socket?

Sorry, I meant only IPv6.

I found this. It seems to imply that you need different sockets to do
what you want to do. You might snag a copy of the latest openldap code
and look at slapd to see what it's doing.

At any rate, here's what I found that pointed me at it:

slapd compiled with --enable-ipv6 does only listen to the IPv6 connections. I
suspect this is tested on an operating system that receives IPv4 connections to
the IPv6 socket as well, although this is not not the case for OpenBSD (nor
FreeBSD or NetBSD ,IIRC). slapd needs to listen to both IPv4 and IPv6 on
separate sockets.

I wasn't clear on which OS's supported dual ipv4/6 on the same socket.
Nigel is testing on Linux, so he says that works for both on the same
socket. Maybe on those other OS's we can do separate sockets on the
same port number --- not sure. Now that it is in there various OS's can
run tests and we will see.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote:

Peter Eisentraut wrote:

Bruce Momjian writes:

The issue is that right now, there isn't any special IPv6 enabling,
except for lines in pg_hba.conf. I think it is fine to add some
enabling, but we then have an additional user interface issue. One idea
I had was to change tcpip_socket from true/false to true/false/4/6 so
you can specify if you want none(false)/4/6/both(true). The original
patch author wants this functionality too, so there clearly is a need
for this. This doesn't play nice with the -i flag, however.

Would there a downside to specifying both (enabling ipv6) on a machine
that doesn't support it? If not I'd suggest making -i equivalent to
tcp_ip_socket = true. I don't think it's too much to ask people to use
the preferred method to obtain maximum functionality.

Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6
isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true,
but when run, opening an IPV6 server fails and I fall back to IPv4 ---
just throwing that out as a data point. What would be our default as
shipped?

If there is no downside to allowing both, probably both. If there is a
downside then ipv4, since it much more likely to be the default on OS's
for the next release or two.

Robert Treat

OK, what do we ship as a default?

---------------------------------------------------------------------------

Nigel Kukard wrote:

Sorry i'm not subscribed to hackers, guess i must get soon!

Anyway what i think should happen is follows, if in the configuration file
we specify that it must bind to both ie. tcpip_socket = true, the server
should check if first its compiled to support ipv6 (or skip this if we use
#ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it
must try to bind to both. Ok thats the first case, the second case is if
we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6
and if there is no ipv4 support on the box it should fail, not fallback.
And finally the third case, if we specify tcpip_socket = 6, we should
again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we
cannot bind to the specific interface we should fail.

Thats my opinion ;)

-Nigel

On 6 Jan 2003, Robert Treat wrote:

On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote:

Peter Eisentraut wrote:

Bruce Momjian writes:

The issue is that right now, there isn't any special IPv6 enabling,
except for lines in pg_hba.conf. I think it is fine to add some
enabling, but we then have an additional user interface issue. One idea
I had was to change tcpip_socket from true/false to true/false/4/6 so
you can specify if you want none(false)/4/6/both(true). The original
patch author wants this functionality too, so there clearly is a need
for this. This doesn't play nice with the -i flag, however.

Would there a downside to specifying both (enabling ipv6) on a machine
that doesn't support it? If not I'd suggest making -i equivalent to
tcp_ip_socket = true. I don't think it's too much to ask people to use
the preferred method to obtain maximum functionality.

Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6
isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true,
but when run, opening an IPV6 server fails and I fall back to IPv4 ---
just throwing that out as a data point. What would be our default as
shipped?

If there is no downside to allowing both, probably both. If there is a
downside then ipv4, since it much more likely to be the default on OS's
for the next release or two.

Robert Treat

--

Nigel Kukard (Chief Executive Officer)
Lando Technologies Africa (Pty) Ltd
nigel@lando.co.za www.lando.co.za
Tel: 083 399 5822 Fax: 086 1100036
Hoheisen Park Bellville, Cape Town
National Internet Service Provider

The best language to use is the language that was designed for
what you want to use it for - 1997

=====================================================================

Disclaimer
----------
The contents of this message and any attachments are intended
solely for the addressee's use and may be legally privileged and/or
confidential information. This message may not be retained,
distributed, copied or used if you are not he addressee of this
message. If this message was sent to you in error, please notify
the sender immediately by reply e-mail and then destroy the message
and any copies thereof.

Opinions, conclusions and other information in this message may be
personal to the sender and is not that of Lando Technologies Africa
or any of it's subsideries, associated companies or principals and
is therefore not endorsed by any of the Lando groups of companies.
Due to e-maill communication being insecure, Lando groups of
companies do not guarantee confidentiality, security, accuracy or
performance of the e-mail. Any liability for viruses is excluded
to the fullest extent.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

You mean ship with only IPv4 enabled, but not IPv6. (Of course, both
are enabled in the binary.) But then what does -i do? We currently
tell people to use -i. Do we need another postgresql.conf option that
says, "If tcpip_socket is enabled, enable IPv6 too"? But that doesn't
work if you want _only_ IPv6.

The big problem is it doesn't mix with tcpip_socket and -i very well. I
am not saying I have a better idea, I am just looking for something
clearer. Perhaps we need a separate flag/postgresql.conf option for
IPv6 so they can be controlled separately. Have we figured out how to
listen on IPv6 only?

---------------------------------------------------------------------------

Nigel Kukard wrote:

IPV4 only should be shipped by default, but disabled as it is at present.

On Tue, 7 Jan 2003, Bruce Momjian wrote:

OK, what do we ship as a default?

---------------------------------------------------------------------------

Nigel Kukard wrote:

Sorry i'm not subscribed to hackers, guess i must get soon!

Anyway what i think should happen is follows, if in the configuration file
we specify that it must bind to both ie. tcpip_socket = true, the server
should check if first its compiled to support ipv6 (or skip this if we use
#ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it
must try to bind to both. Ok thats the first case, the second case is if
we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6
and if there is no ipv4 support on the box it should fail, not fallback.
And finally the third case, if we specify tcpip_socket = 6, we should
again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we
cannot bind to the specific interface we should fail.

Thats my opinion ;)

-Nigel

On 6 Jan 2003, Robert Treat wrote:

On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote:

Peter Eisentraut wrote:

Bruce Momjian writes:

The issue is that right now, there isn't any special IPv6 enabling,
except for lines in pg_hba.conf. I think it is fine to add some
enabling, but we then have an additional user interface issue. One idea
I had was to change tcpip_socket from true/false to true/false/4/6 so
you can specify if you want none(false)/4/6/both(true). The original
patch author wants this functionality too, so there clearly is a need
for this. This doesn't play nice with the -i flag, however.

Would there a downside to specifying both (enabling ipv6) on a machine
that doesn't support it? If not I'd suggest making -i equivalent to
tcp_ip_socket = true. I don't think it's too much to ask people to use
the preferred method to obtain maximum functionality.

Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6
isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true,
but when run, opening an IPV6 server fails and I fall back to IPv4 ---
just throwing that out as a data point. What would be our default as
shipped?

If there is no downside to allowing both, probably both. If there is a
downside then ipv4, since it much more likely to be the default on OS's
for the next release or two.

Robert Treat

--

Nigel Kukard (Chief Executive Officer)
Lando Technologies Africa (Pty) Ltd
nigel@lando.co.za www.lando.co.za
Tel: 083 399 5822 Fax: 086 1100036
Hoheisen Park Bellville, Cape Town
National Internet Service Provider

The best language to use is the language that was designed for
what you want to use it for - 1997

=====================================================================

Disclaimer
----------
The contents of this message and any attachments are intended
solely for the addressee's use and may be legally privileged and/or
confidential information. This message may not be retained,
distributed, copied or used if you are not he addressee of this
message. If this message was sent to you in error, please notify
the sender immediately by reply e-mail and then destroy the message
and any copies thereof.

Opinions, conclusions and other information in this message may be
personal to the sender and is not that of Lando Technologies Africa
or any of it's subsideries, associated companies or principals and
is therefore not endorsed by any of the Lando groups of companies.
Due to e-maill communication being insecure, Lando groups of
companies do not guarantee confidentiality, security, accuracy or
performance of the e-mail. Any liability for viruses is excluded
to the fullest extent.

--

Nigel Kukard (Chief Executive Officer)
Lando Technologies Africa (Pty) Ltd
nigel@lando.co.za www.lando.co.za
Tel: 083 399 5822 Fax: 086 1100036
Hoheisen Park Bellville, Cape Town
National Internet Service Provider

The best language to use is the language that was designed for
what you want to use it for - 1997

=====================================================================

Disclaimer
----------
The contents of this message and any attachments are intended
solely for the addressee's use and may be legally privileged and/or
confidential information. This message may not be retained,
distributed, copied or used if you are not he addressee of this
message. If this message was sent to you in error, please notify
the sender immediately by reply e-mail and then destroy the message
and any copies thereof.

Opinions, conclusions and other information in this message may be
personal to the sender and is not that of Lando Technologies Africa
or any of it's subsideries, associated companies or principals and
is therefore not endorsed by any of the Lando groups of companies.
Due to e-maill communication being insecure, Lando groups of
companies do not guarantee confidentiality, security, accuracy or
performance of the e-mail. Any liability for viruses is excluded
to the fullest extent.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Another idea is to have the -i take an optional argument. Something where
-i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only
v6.

I am guessing that most people will want to bind to both when they
just specify -i, which is what is usually suggested when they want to get
the box up and running.

If they want do something fancy, like only bind to v6, then they will read
the docs and see that they can do that with something like -i6.

-rocco

On Tue, 7 Jan 2003, Bruce Momjian wrote:

Rocco Altier <RoccoA@Routescape.com> writes:

Another idea is to have the -i take an optional argument. Something where
-i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only
v6.

I don't see why we need any such thing. The current behavior of the
postmaster (assuming -i or tcpip_socket is set) is:

1. By default: bind to all IPs on the machine.

2. If virtual_host is set: bind only to that one IP.

It seems to me that in a machine with both v4 and v6 IP addresses, the
natural extension is that the default behavior is to bind to all of
them, or if virtual_host is set then bind to only that one, be it v4 or
v6. (Does the existing patch work with virtual_host identifying a v6
IP? If not, that's certainly a bug.)

No one has offered any scenario in which it's important to bind to only
v4 or only v6 addresses when both are present. In the absence of a
compelling argument why that would be useful, I do not see why we're
worrying. My own thought is that if I wanted to constrain PG to bind
to a subset of a machine's addresses, the extension I'd want is to allow
virtual_host to contain a list of names or IP addresses --- of either
version. Basing it on v4 versus v6 has no payback that I can see.

regards, tom lane

--On Tuesday, January 07, 2003 11:51:44 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

Rocco Altier <RoccoA@Routescape.com> writes:

Another idea is to have the -i take an optional argument. Something
where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6
to only v6.

I don't see why we need any such thing. The current behavior of the
postmaster (assuming -i or tcpip_socket is set) is:

1. By default: bind to all IPs on the machine.

2. If virtual_host is set: bind only to that one IP.

It seems to me that in a machine with both v4 and v6 IP addresses, the
natural extension is that the default behavior is to bind to all of
them, or if virtual_host is set then bind to only that one, be it v4 or
v6. (Does the existing patch work with virtual_host identifying a v6
IP? If not, that's certainly a bug.)

No one has offered any scenario in which it's important to bind to only
v4 or only v6 addresses when both are present. In the absence of a
compelling argument why that would be useful, I do not see why we're
worrying. My own thought is that if I wanted to constrain PG to bind
to a subset of a machine's addresses, the extension I'd want is to allow
virtual_host to contain a list of names or IP addresses --- of either
version. Basing it on v4 versus v6 has no payback that I can see.

Please make sure that you can handle the situation of a IPv6 API, but no
IPv6
stack. (E.G. UnixWare up to at least 7.1.3).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler@lerctr.org> writes:

Please make sure that you can handle the situation of a IPv6 API, but no
IPv6 stack. (E.G. UnixWare up to at least 7.1.3).

Certainly. But that is just an autoconfiguration problem. If a v6 IP
address is available, we should bind to it.

regards, tom lane

Tom Lane wrote:

Rocco Altier <RoccoA@Routescape.com> writes:

Another idea is to have the -i take an optional argument. Something where
-i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only
v6.

I don't see why we need any such thing. The current behavior of the
postmaster (assuming -i or tcpip_socket is set) is:

1. By default: bind to all IPs on the machine.

2. If virtual_host is set: bind only to that one IP.

It seems to me that in a machine with both v4 and v6 IP addresses, the
natural extension is that the default behavior is to bind to all of
them, or if virtual_host is set then bind to only that one, be it v4 or
v6. (Does the existing patch work with virtual_host identifying a v6
IP? If not, that's certainly a bug.)

No one has offered any scenario in which it's important to bind to only
v4 or only v6 addresses when both are present. In the absence of a
compelling argument why that would be useful, I do not see why we're
worrying. My own thought is that if I wanted to constrain PG to bind
to a subset of a machine's addresses, the extension I'd want is to allow
virtual_host to contain a list of names or IP addresses --- of either
version. Basing it on v4 versus v6 has no payback that I can see.

The issue was that folks didn't like silent fallback to just IPv4 if the
code supported IPv6 but it didn't bind to IPv6 for some reason, e.g.
kernel doesn't have IPv6 enabled. Right now it puts a message in the
server logs, but others wanted some specific way to enable IPv6 and fail
if it didn't work. They want something that says "I want IPv6 and I
don't want to start if it doesn't start." Right now if we do -i, and
tcpip doesn't start, be bomb out. They want that for IPv6, and the
tricky part is we can't enable that by default because many systems have
the API but no kernel support.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073