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

Sat, 28 Dec 2002 23:36:02 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
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

Sun, 5 Jan 2003 22:18:48 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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


Mon, 6 Jan 2003 22:29:00 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: IPv6 patch
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


06 Jan 2003 15:39:49 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: IPv6 patch
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

Mon, 6 Jan 2003 16:40:36 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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

Mon, 6 Jan 2003 16:43:38 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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


06 Jan 2003 15:54:13 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: IPv6 patch
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

Mon, 6 Jan 2003 16:59:30 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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


06 Jan 2003 16:02:59 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: IPv6 patch
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

Mon, 6 Jan 2003 17:17:46 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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


06 Jan 2003 16:29:00 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: IPv6 patch
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

Mon, 6 Jan 2003 17:33:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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




06 Jan 2003 17:36:34 -0500
Robert Treat <xzilla@users.sourceforge.net>
Re: IPv6 patch