search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.93k stars 551 forks source link

IPv6 support missing in perl5.10, perl5.12 #10439

Open p5pRT opened 14 years ago

p5pRT commented 14 years ago

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

Searchable as RT75740$

p5pRT commented 14 years ago

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 commented 14 years ago

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 commented 14 years ago

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

p5pRT commented 14 years ago

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 commented 14 years ago

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 commented 14 years ago

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 commented 14 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 (https://github.com/steve-m-hay/perl-libnet/pull/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 commented 10 years ago

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 (https://github.com/steve-m-hay/perl-libnet/pull/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 commented 10 years ago

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 (https://github.com/steve-m-hay/perl-libnet/pull/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.