IPv6 support missing in perl5.10, perl5.12

[p5pRT]

Migrated from rt.perl.org#75740 (status was 'open')

Searchable as RT75740$

[p5pRT]

From sullr@cpan.org

Created by sullr@cpan.org

Hi,

It's 2010, everybody talks about IPv6 but current perl CORE is missing
any useful support for it.
I've talked to this last year at the german perl workshop and touched
the topic this year again because the situation did not change.
Marc Overmeer recommended that I file a bug about it.

This is not only a bug report.
It contains suggestions how the problem can be solved and I don't think
it is too much hassle.

What's there​:
- Socket exports AF_INET6

What's missing in the CORE​:
- getaddrinfo (gethostbyname gives only IPv4)
- inet_pton, inet_ntop (similar to inet_aton, inet_ntoa but also for
  IPv6)
- support for IPv6 in Net​::* Modules (Net​::SMTP, Net​::FTP.. are bound to
  use IO​::Socket​::INET which does not do IPv6)
- comfortable use of sockets similar to IO​::Socket​::INET6

What help could CPAN provide​:
- Socket6 - which provides getaddrinfo, inet_ntop, inet_pton..
- IO​::Socket​::INET6 which is similar to IO​::Socket​::INET but supports
  also IPv6
- Net​::INET6Glue, which is a hack to provide IPv6 functionality in the
  Net​::* Modules, LWP...

So what could be done?
I think it's not that hard​:
- integrate Socket6 and IO​::Socket​::INET6 into CORE, complementing
  Socket and IO​::Socket​::INET
- integrate IPv6 in the Net​::* CORE modules, thus making a lot of
  Net​::INET6Glue obsolete. This is not hard, it's mostly using
  IO​::Socket​::INET6 instead of IO​::Socket​::INET if available. I did this
  with IO​::Socket​::SSL already, which is automatically IPv6 aware if
  IO​::Socket​::INET6 is available.
  The added functionality needed for Net​::FTP can be used from
  Net​::INET6Glue​::FTP.

Who can do it?
- I could definitly help with the Net​::* Modules because I have already
  most of the code from writing Net​::INET6Glue
- From my experience the maintainer of IO​::Socket​::INET6 seems to be a
  nice and responsive guy so he might help to move the module to CORE.
  It has no dependencies on non CORE except Socket6.
- I don't know about the Socket6 maintainer, but the module is stable
  for years and has not dependencies to non CORE modules.

When can it be done?
As soon as possible. I think it's not hard to fix.

Regards,
Steffen

Perl Info

Flags:
    category=library
    severity=wishlist

Site configuration information for perl 5.10.1:

Configured by Debian Project at Fri Apr 23 07:59:14 UTC 2010.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=2.6.24-27-server, archname=i486-linux-gnu-thread-multi
    uname='linux vernadsky 2.6.24-27-server #1 smp fri mar 12 01:45:06 utc 2010 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.1 -Dsitearch=/usr/local/lib/perl/5.10.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.1 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.4.3', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/lib64
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.11.1.so, so=so, useshrplib=true, libperl=libperl.so.5.10.1
    gnulibc_version='2.11.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.10.1:
    /etc/perl
    /usr/local/lib/perl/5.10.1
    /usr/local/share/perl/5.10.1
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.10
    /usr/share/perl/5.10
    /usr/local/lib/site_perl
    .


Environment for perl 5.10.1:
    HOME=/home/steffen
    LANG=en_US.UTF-8
    LANGUAGE=
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/steffen/genua/bin:/home/steffen/bin:/Users/Shared/Software/perl-5.8.7/bin:/Users/Shared/Software/sqlite3/bin:/usr/lib/postgresql/8.3/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

From @rgarcia

On 14 June 2010 18​:39, sullr@​cpan.org <perlbug-followup@​perl.org> wrote​:

What's missing in the CORE​:
- getaddrinfo (gethostbyname gives only IPv4)
- inet_pton, inet_ntop (similar to inet_aton, inet_ntoa but also for
 IPv6)

Note that Configure already probes for those functions.

- support for IPv6 in Net​::* Modules (Net​::SMTP, Net​::FTP.. are bound to
 use IO​::Socket​::INET which does not do IPv6)
- comfortable use of sockets similar to IO​::Socket​::INET6

What help could CPAN provide​:
- Socket6 - which provides getaddrinfo, inet_ntop, inet_pton..

I'd vote against : looking at it, its compilation process is too
complex, it contains an incomplete implementation of getaddrinfo (used
when the system has none), and its license is complex.

We could provide instead a bare-bones module that just wraps around
getaddrinfo, getnameinfo, inet_ntop and inet_pton (maybe other ones).

What about the IP​:: namespace for those ? (or we could also stuff them
in POSIX​::)

- IO​::Socket​::INET6 which is similar to IO​::Socket​::INET but supports
 also IPv6

It currently requires Socket6, which could be made optional.

- Net​::INET6Glue, which is a hack to provide IPv6 functionality in the
 Net​::* Modules, LWP...

So what could be done?
I think it's not that hard​:
- integrate Socket6 and IO​::Socket​::INET6 into CORE, complementing
 Socket and IO​::Socket​::INET
- integrate IPv6 in the Net​::* CORE modules, thus making a lot of
 Net​::INET6Glue obsolete. This is not hard, it's mostly using
 IO​::Socket​::INET6 instead of IO​::Socket​::INET if available. I did this
 with IO​::Socket​::SSL already, which is automatically IPv6 aware if
 IO​::Socket​::INET6 is available.
 The added functionality needed for Net​::FTP can be used from
 Net​::INET6Glue​::FTP.

For that you'd need to ask Graham Barr, maintainer of libnet on CPAN.
The perl core just integrates the CPAN version. I personally like the
idea. Graham ?

Who can do it?
- I could definitly help with the Net​::* Modules because I have already
 most of the code from writing Net​::INET6Glue
- From my experience the maintainer of IO​::Socket​::INET6 seems to be a
 nice and responsive guy so he might help to move the module to CORE.
 It has no dependencies on non CORE except Socket6.
- I don't know about the Socket6 maintainer, but the module is stable
 for years and has not dependencies to non CORE modules.

When can it be done?
As soon as possible. I think it's not hard to fix.

Thanks for volunteering!

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @csjewell

On Tue, 15 Jun 2010 10​:00 +0200, "Rafael Garcia-Suarez"
<rgs@​consttype.org> wrote​:

On 14 June 2010 18​:39, sullr@​cpan.org <perlbug-followup@​perl.org> wrote​:

What's missing in the CORE​:
- getaddrinfo (gethostbyname gives only IPv4)
- inet_pton, inet_ntop (similar to inet_aton, inet_ntoa but also for
 IPv6)

Note that Configure already probes for those functions.

- support for IPv6 in Net​::* Modules (Net​::SMTP, Net​::FTP.. are bound to
 use IO​::Socket​::INET which does not do IPv6)
- comfortable use of sockets similar to IO​::Socket​::INET6

What help could CPAN provide​:
- Socket6 - which provides getaddrinfo, inet_ntop, inet_pton..

I'd vote against : looking at it, its compilation process is too
complex, it contains an incomplete implementation of getaddrinfo (used
when the system has none), and its license is complex.

I want to -1 this as well. (ok, so I'm not a committer yet.)

Reason being that insane compilation process. It did NOT compile on
Strawberry (I wanted to include it in Professional!)

--Curtis

We could provide instead a bare-bones module that just wraps around
getaddrinfo, getnameinfo, inet_ntop and inet_pton (maybe other ones).

What about the IP​:: namespace for those ? (or we could also stuff them
in POSIX​::)

NOT POSIX​::. But otherwise a good idea.

--Curtis Jewell
--
Curtis Jewell
csjewell@​cpan.org http​://csjewell.dreamwidth.org/
perl@​csjewell.fastmail.us http​://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas​: http​://strawberryperl.com/beta/

[p5pRT]

From @nwc10

On Tue, Jun 15, 2010 at 10​:00​:26AM +0200, Rafael Garcia-Suarez wrote​:

On 14 June 2010 18​:39, sullr@​cpan.org <perlbug-followup@​perl.org> wrote​:

What's missing in the CORE​:
- getaddrinfo (gethostbyname gives only IPv4)
- inet_pton, inet_ntop (similar to inet_aton, inet_ntoa but also for
 IPv6)

Note that Configure already probes for those functions.

- support for IPv6 in Net​::* Modules (Net​::SMTP, Net​::FTP.. are bound to
 use IO​::Socket​::INET which does not do IPv6)
- comfortable use of sockets similar to IO​::Socket​::INET6

What help could CPAN provide​:
- Socket6 - which provides getaddrinfo, inet_ntop, inet_pton..

I'd vote against : looking at it, its compilation process is too
complex, it contains an incomplete implementation of getaddrinfo (used
when the system has none), and its license is complex.

We could provide instead a bare-bones module that just wraps around
getaddrinfo, getnameinfo, inet_ntop and inet_pton (maybe other ones).

What about the IP​:: namespace for those ? (or we could also stuff them
in POSIX​::)

We added inet_ntop and inet_pton to Socket in March 2009​:
http​://perl5.git.perl.org/perl.git/commit/036d8bd42e6e43

Hence they are already in Socket 5.12
That leaves only getaddrinfo. What is wrong with also putting that in Socket?

- IO​::Socket​::INET6 which is similar to IO​::Socket​::INET but supports
 also IPv6

It currently requires Socket6, which could be made optional.

- Net​::INET6Glue, which is a hack to provide IPv6 functionality in the
 Net​::* Modules, LWP...

So what could be done?
I think it's not that hard​:
- integrate Socket6 and IO​::Socket​::INET6 into CORE, complementing
 Socket and IO​::Socket​::INET
- integrate IPv6 in the Net​::* CORE modules, thus making a lot of
 Net​::INET6Glue obsolete. This is not hard, it's mostly using
 IO​::Socket​::INET6 instead of IO​::Socket​::INET if available. I did this
 with IO​::Socket​::SSL already, which is automatically IPv6 aware if
 IO​::Socket​::INET6 is available.
 The added functionality needed for Net​::FTP can be used from
 Net​::INET6Glue​::FTP.

For that you'd need to ask Graham Barr, maintainer of libnet on CPAN.
The perl core just integrates the CPAN version. I personally like the
idea. Graham ?

I think that this comes down to a policy/philosophy distinction.

Either​:
  Socket is called Socket, not Socket4, and likewise NET​::*, such as
  IO​::Socket​::INET being that, not IO​::Socket​::INET4
  Hence they're not just about IPv4, so *they* should be made to support
  IPv6 too (and no new namespaces)

Or​:
  IPv6 is something new, and it is reasonable for programs to need to load
  new/different modules to support it.

Personally, I prefer the former. I'm not sure how hard it is to get there.
This means that I am disagreeing with the specific proposal to integrate
Socket6 and IO;​:Socket​::INET6 into the code.

Partly this is because I believe that it is viable (and not that hard)
make this work in the core modules, without breaking the existing IPv6
specific modules on CPAN, such that existing code that loads them will
continue working, but new or updated code can be cleaner.

Nicholas Clark

[p5pRT]

From @rgarcia

On 15 June 2010 17​:45, Nicholas Clark <nick@​ccl4.org> wrote​:

We could provide instead a bare-bones module that just wraps around
getaddrinfo, getnameinfo, inet_ntop and inet_pton (maybe other ones).

What about the IP​:: namespace for those ? (or we could also stuff them
in POSIX​::)

We added inet_ntop and inet_pton to Socket in March 2009​:
http​://perl5.git.perl.org/perl.git/commit/036d8bd42e6e43

Ah, I already forgot about that.

Hence they are already in Socket 5.12
That leaves only getaddrinfo. What is wrong with also putting that in Socket?

And probably getnameinfo too, for good measure.
Yes, I agree, we could complement Socket with them. (And probably
ipv6 functionality as you suggested below)

- IO​::Socket​::INET6 which is similar to IO​::Socket​::INET but supports
 also IPv6

It currently requires Socket6, which could be made optional.

- Net​::INET6Glue, which is a hack to provide IPv6 functionality in the
 Net​::* Modules, LWP...

So what could be done?
I think it's not that hard​:
- integrate Socket6 and IO​::Socket​::INET6 into CORE, complementing
 Socket and IO​::Socket​::INET
- integrate IPv6 in the Net​::* CORE modules, thus making a lot of
 Net​::INET6Glue obsolete. This is not hard, it's mostly using
 IO​::Socket​::INET6 instead of IO​::Socket​::INET if available. I did this
 with IO​::Socket​::SSL already, which is automatically IPv6 aware if
 IO​::Socket​::INET6 is available.
 The added functionality needed for Net​::FTP can be used from
 Net​::INET6Glue​::FTP.

For that you'd need to ask Graham Barr, maintainer of libnet on CPAN.
The perl core just integrates the CPAN version. I personally like the
idea. Graham ?

I think that this comes down to a policy/philosophy distinction.

Either​:
 Socket is called Socket, not Socket4, and likewise NET​::*, such as
 IO​::Socket​::INET being that, not IO​::Socket​::INET4
 Hence they're not just about IPv4, so *they* should be made to support
 IPv6 too (and no new namespaces)

Or​:
 IPv6 is something new, and it is reasonable for programs to need to load
 new/different modules to support it.

Personally, I prefer the former. I'm not sure how hard it is to get there.
This means that I am disagreeing with the specific proposal to integrate
Socket6 and IO;​:Socket​::INET6 into the code.

Partly this is because I believe that it is viable (and not that hard)
make this work in the core modules, without breaking the existing IPv6
specific modules on CPAN, such that existing code that loads them will
continue working, but new or updated code can be cleaner.

--
* What system had proved more effective?
* Indirect suggestion implicating selfinterest.
  -- Ulysses

[p5pRT]

From zefram@fysh.org

Nicholas Clark wrote​:

Either​:
Socket is called Socket, not Socket4, and likewise NET​::*, such as
IO​::Socket​::INET being that, not IO​::Socket​::INET4
Hence they're not just about IPv4, so *they* should be made to support
IPv6 too (and no new namespaces)

This is not quite right, but nearly so. What the C level APIs do is​:

* The term "socket" is just "socket", and applies not only to IPv4 and
  IPv4 but also to Unix-domain sockets and all other kinds of socket,
  including ones not yet invented. Hence "socket4" or "socket6" would
  be a misnomer.

* The protocol/address family for IPv4 is labelled "INET". Not "INET4";
  there is no "INET4". This is for historical reasons, because the IPv4
  socket API predates us having to make that distinction.

* The protocol/address family for IPv6 is labelled "INET6".

I suggest we stick to that. IO​::Socket​::INET is about IPv4 sockets,
and IO​::Socket​::INET6 is about IPv6 sockets. If you want to use both
IPv4 and IPv6 together through one socket, you do that through an INET6
socket with an option flag saying that that's what you want to do, and
you end up seeing v4-mapped IPv6 addresses. (This flag is standard and
was recently mentioned.)

-zefram

[p5pRT]

From @jkeenan

On Mon Jun 14 09​:39​:22 2010, sullr@​cpan.org wrote​:

This is a bug report for perl from sullr@​cpan.org,
generated with the help of perlbug 1.39 running under perl 5.10.1.

-----------------------------------------------------------------
[Please describe your issue here]

Hi,

It's 2010, everybody talks about IPv6 but current perl CORE is missing
any useful support for it.
I've talked to this last year at the german perl workshop and touched
the topic this year again because the situation did not change.
Marc Overmeer recommended that I file a bug about it.

This is not only a bug report.
It contains suggestions how the problem can be solved and I don't
think
it is too much hassle.

What's there​:
- Socket exports AF_INET6

What's missing in the CORE​:
- getaddrinfo (gethostbyname gives only IPv4)
- inet_pton, inet_ntop (similar to inet_aton, inet_ntoa but also for
IPv6)
- support for IPv6 in Net​::* Modules (Net​::SMTP, Net​::FTP.. are bound
to
use IO​::Socket​::INET which does not do IPv6)
- comfortable use of sockets similar to IO​::Socket​::INET6

What help could CPAN provide​:
- Socket6 - which provides getaddrinfo, inet_ntop, inet_pton..
- IO​::Socket​::INET6 which is similar to IO​::Socket​::INET but supports
also IPv6
- Net​::INET6Glue, which is a hack to provide IPv6 functionality in the
Net​::* Modules, LWP...

So what could be done?
I think it's not that hard​:
- integrate Socket6 and IO​::Socket​::INET6 into CORE, complementing
Socket and IO​::Socket​::INET
- integrate IPv6 in the Net​::* CORE modules, thus making a lot of
Net​::INET6Glue obsolete. This is not hard, it's mostly using
IO​::Socket​::INET6 instead of IO​::Socket​::INET if available. I did
this
with IO​::Socket​::SSL already, which is automatically IPv6 aware if
IO​::Socket​::INET6 is available.
The added functionality needed for Net​::FTP can be used from
Net​::INET6Glue​::FTP.

Who can do it?
- I could definitly help with the Net​::* Modules because I have
already
most of the code from writing Net​::INET6Glue
- From my experience the maintainer of IO​::Socket​::INET6 seems to be
a
nice and responsive guy so he might help to move the module to CORE.
It has no dependencies on non CORE except Socket6.
- I don't know about the Socket6 maintainer, but the module is stable
for years and has not dependencies to non CORE modules.

When can it be done?
As soon as possible. I think it's not hard to fix.

Regards,
Steffen

Discussion in this RT petered out approximately 3-1/2 years ago. The versions of Perl 5 referenced in the ticket's description are out of support.

Would it be possible to get a review of the issues in this ticket with respect to the current state of our support for IPv6?

Thank you very much.
Jim Keenan

[p5pRT]

From @leonerd

On Sat, 1 Feb 2014 16​:38​:43 -0800
"James E Keenan via RT" <perlbug-followup@​perl.org> wrote​:

What help could CPAN provide​:
- Socket6 - which provides getaddrinfo, inet_ntop, inet_pton..

Socket6 was a horrible end-run around core. These are all present in
Socket now.

- IO​::Socket​::INET6 which is similar to IO​::Socket​::INET but
supports also IPv6

INET6 is no better than INET was. The proper solution is
IO​::Socket​::IP, which we're in the process of en-coring now.

Would it be possible to get a review of the issues in this ticket
with respect to the current state of our support for IPv6?

Simply awaiting on getting IO​::Socket​::IP into core proper and then it
will be done, and finally we can claim core support for IPv6.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http​://www.leonerd.org.uk/

[p5pRT]

From coyote.frank@gmx.net

On 02/03/2014 12​:38 PM, Paul LeoNerd Evans via RT wrote​:

...
Simply awaiting on getting IO​::Socket​::IP into core proper and then it
will be done, and finally we can claim core support for IPv6.

I think having IO​::Socket​::IP is only the start for having IPv6 support in the
core. There are currently several modules in the core, which are hard-wired to
use IO​::Socket​::INET and thus can only do IPv4.
With Net​::SMTP, Net​::POP3, Net​::NNTP it should be enough to replace the
dependency from IO​::Socket​::INET to IO​::Socket​::IP, but for Net​::FTP you also
need transparent support for EPRT und EPSV commands. And then there are some
other modules I did not have a look at yet.

The necessary fixes are mostly there​: I implemented them years ago in
Net​::INET6Glue and they still work. So it could be a start to port pack the
fixes to Net​::FTP and replace IO​::Socket​::INET with IO​::Socket​::IP in the other
Net​::* modules.
Let me know if I should help.

Steffen

[p5pRT]

From @leonerd

On Mon, 03 Feb 2014 17​:45​:57 +0100
Steffen Ullrich <coyote.frank@​gmx.net> wrote​:

I think having IO​::Socket​::IP is only the start for having IPv6
support in the core. There are currently several modules in the core,
which are hard-wired to use IO​::Socket​::INET and thus can only do
IPv4. With Net​::SMTP, Net​::POP3, Net​::NNTP it should be enough to
replace the dependency from IO​::Socket​::INET to IO​::Socket​::IP, but
for Net​::FTP you also need transparent support for EPRT und EPSV
commands. And then there are some other modules I did not have a look
at yet.

The necessary fixes are mostly there​: I implemented them years ago in
Net​::INET6Glue and they still work. So it could be a start to port
pack the fixes to Net​::FTP and replace IO​::Socket​::INET with
IO​::Socket​::IP in the other Net​::* modules.
Let me know if I should help.

Well, 5.20 is now out, with IO​::Socket​::IP nicely in place.

I'd say now's as good a time as any to start going around further
modules, core or CPAN, and start the big swap to using :​:IP instead
of :​:INET. Hopefully it should be a dead-simple change in every case.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
http​://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS

[p5pRT]

From sullr@cpan.org

On Sat, May 31, 2014 at 03​:16​:25PM -0700, Paul LeoNerd Evans via RT <perlbug-followup@​perl.org> wrote​:

On Mon, 03 Feb 2014 17​:45​:57 +0100
Steffen Ullrich <coyote.frank@​gmx.net> wrote​:

I think having IO​::Socket​::IP is only the start for having IPv6
support in the core. There are currently several modules in the core,
which are hard-wired to use IO​::Socket​::INET and thus can only do
IPv4. With Net​::SMTP, Net​::POP3, Net​::NNTP it should be enough to
replace the dependency from IO​::Socket​::INET to IO​::Socket​::IP, but
for Net​::FTP you also need transparent support for EPRT und EPSV
commands. And then there are some other modules I did not have a look
at yet.

The necessary fixes are mostly there​: I implemented them years ago in
Net​::INET6Glue and they still work. So it could be a start to port
pack the fixes to Net​::FTP and replace IO​::Socket​::INET with
IO​::Socket​::IP in the other Net​::* modules.
Let me know if I should help.

Well, 5.20 is now out, with IO​::Socket​::IP nicely in place.

I'd say now's as good a time as any to start going around further
modules, core or CPAN, and start the big swap to using :​:IP instead
of :​:INET. Hopefully it should be a dead-simple change in every case.

Not completely trivial.
Protocols like FTP have special extensions for IPv6, which have to be
implemented, but it's not that hard and I've done it already when monkey
patching Net​::FTP in Net​::INET6Glue​::FTP.

Anyway, I am still waiting for any kind of response to RT#93823, where I
offered more than 2 month ago help with adding transparent IPv6 and SSL
support to these Net​::* libraries. I've also offered patches for part of the
problem (steve-m-hay/perl-libnet#4).
But, so far not even a tiny response from the perl-libnet maintainers.
So it might be less an implementation problem, but more a problem of
getting contact to the maintainers. Any help with this would be appreciated.

Regards,
Steffen

[p5pRT]

From @craigberry

On Sun, Jun 1, 2014 at 1​:47 AM, Steffen Ullrich <sullr@​cpan.org> wrote​:

Anyway, I am still waiting for any kind of response to RT#93823, where I
offered more than 2 month ago help with adding transparent IPv6 and SSL
support to these Net​::* libraries. I've also offered patches for part of the
problem (steve-m-hay/perl-libnet#4).
But, so far not even a tiny response from the perl-libnet maintainers.
So it might be less an implementation problem, but more a problem of
getting contact to the maintainers. Any help with this would be appreciated.

You may want to join the discussion starting at​:

http​://www.nntp.perl.org/group/perl.perl5.porters/2014/05/msg216090.html

[p5pRT]

From @steve-m-hay

On 1 June 2014 19​:11, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

On Sun, Jun 1, 2014 at 1​:47 AM, Steffen Ullrich <sullr@​cpan.org> wrote​:

Anyway, I am still waiting for any kind of response to RT#93823, where I
offered more than 2 month ago help with adding transparent IPv6 and SSL
support to these Net​::* libraries. I've also offered patches for part of the
problem (steve-m-hay/perl-libnet#4).
But, so far not even a tiny response from the perl-libnet maintainers.
So it might be less an implementation problem, but more a problem of
getting contact to the maintainers. Any help with this would be appreciated.

You may want to join the discussion starting at​:

http​://www.nntp.perl.org/group/perl.perl5.porters/2014/05/msg216090.html

Indeed :-)

My apologies, Steffen, for sitting on this for so long. I was
initially against the idea, but since it keeps coming up there must be
some demaned / expectation for it and I am now warming to the idea as
long as it's done in such a way as to allow non IPv6 / SSL usage to
seamlessly continue wokring with no changes.