public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/11469] No IPv6 option in glibc
Date: Mon, 30 Jun 2014 18:19:00 -0000 [thread overview]
Message-ID: <bug-11469-131-U6LltdJM8L@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-11469-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=11469
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--- Comment #2 from martin barrowcliff <martinbarrowcliff at gmail dot com> ---
Subject: Re: No IPv6 option in glibc
drepper at redhat dot com wrote:
> ------- Additional Comments From drepper at redhat dot com 2010-04-05 18:30 -------
> IPv6 is needed. It's trivial to disable any use of it so there is no need at
> all to do anything in glibc.
>
>
I appreciate your fast reply, and certainly respect your opinion, but
the issue extends
far beyond glibs. It is viral code.
Indeed, a few people do need ipV6 for corporate networks, however
Internet use is
very low, and there is doubt if that protocol will ever be accepted
mainstream.
It is NOT trivial to disable ipv6, and you of all people should know that.
It is stuck in every linux dist because they all use that same resolver
library.
Many applications are built with IPv6 enabled if the code is available
in the libs.
Some have options to disable, some don't. But it is NEVER a requirement.
Being able to choose to enable it should be an option, and not forced on
the builder.
I certainly didn't mean to insult your code or intelligence. We are
still friends, please.
I never had a ipv6 network. Never will.
I have run authoritative DNS servers and resolvers on ipv4 and set them
to ignore
AAAA requests because I got a lot of that junk and it is just noise if
you don't need it.
I have methodically disabled all the IPv6 resolver lib functions in my
hand built OS and I can
assure you; ipv6 is NOT needed by me, or by any packages I have ever
built.
I also have considerably faster local networking because of my hacks.
So saying ipv6 is needed does not address this issue properly.
Having read every line of that code, I know the resolver libs are way
old and need to
be rewritten with an option for IPv6.
I am 60 yrs old but don't for a minute think I can't fix this issue to
the gratitude
of millions. But you could do it easier. The ipv6 issue IS a problem
for ipv4 networks.
Best regards,
Marty B.
--
You are receiving this mail because:
You are on the CC list for the bug.
next parent reply other threads:[~2014-06-30 18:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-11469-131@http.sourceware.org/bugzilla/>
2014-06-30 18:19 ` fweimer at redhat dot com [this message]
2010-04-05 18:28 [Bug libc/11469] New: " martinbarrowcliff at gmail dot com
2010-04-05 18:30 ` [Bug libc/11469] " drepper at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-11469-131-U6LltdJM8L@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=glibc-bugs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).