Le 2014-04-29 22:04, Theo de Raadt a écrit :
measurements all over the world show that IPv4 is better
in every respect.
Not disagreeing, but I would like to have access to more data backing
this up. I'm not satisfied with what I found (see other post).
Change that, then we can talk.
Working
On 2014/04/29 23:12, Stuart Henderson wrote:
On 2014/04/29 22:25, Paul de Weerd wrote:
Disabling IPv6 should not be necessary: it shouldn't be enabled by
default, even link-local addresses.
If doing this, then we need a way to enable link-local, like the opposite
of ifconfig $if -inet6.
* Adam Thompson athom...@athompso.net [2014-04-29 04:37]:
On April 28, 2014 5:43:34 PM CDT, Kenneth Westerback kwesterb...@gmail.com
wrote:
On 28 April 2014 18:05, Simon Perreault si...@per.reau.lt wrote:
Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil
master plan:
make
On 2014/04/28 18:05, Simon Perreault wrote:
Tech,
Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil master plan:
make getaddrinfo() return IPv6 results first by default.
The diff below would be the end goal. I guess people will have valid
objections
to it. I'd like to
Le 2014-04-28 18:53, Chris Cappuccio a écrit :
Why is the burden on everyone to provide 'valid' objections? Should
not the burden be on you to at least hint at a point to this change?
Given the miniscule IPv6 usage out there, why should IPv6 come first?
I like how IPv6 support turns primary
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear picture of what the issues are,
and whether there's anything I can do to
On 29 April 2014 08:57, Simon Perreault si...@per.reau.lt wrote:
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear picture
* Simon Perreault si...@per.reau.lt [2014-04-29 14:58]:
I don't see how usage is relevant. If IPv6 provided 1000% performance
improvement with no downsides, we would want to use it even if global
usage was low.
however, it provides far worse performance with shitloads of downsides...
--
Em 29-04-2014 04:51, Stuart Henderson escreveu:
Too soon I think. Wait a little longer and more major ISPs will turn
IPv4 into the second class citizen as they fumble with their cgnat
deployments then this will make a lot more sense. Now that akamai have
their /10 taking ARIN into the final /8
* Simon Perreault si...@per.reau.lt [2014-04-29 14:41]:
Le 2014-04-28 18:53, Chris Cappuccio a écrit :
Why is the burden on everyone to provide 'valid' objections? Should
not the burden be on you to at least hint at a point to this change?
Given the miniscule IPv6 usage out there, why
Le 2014-04-28 18:54, Todd T. Fries a écrit :
IPv6 is a 2nd class netizen in terms of reliability and user
experience.
Here's the relevant data I know of:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Le 2014-04-29 09:44, Kenneth Westerback a écrit :
Why would having the IPv6 addresses come first in the returned list be
required to 'use' them? Please explain.
Well I thought this would be obvious, but applications using
getaddrinfo() typically try connecting to each of the addresses returned
On Tue, Apr 29, 2014 at 08:57, Simon Perreault wrote:
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear picture of what
Le 2014-04-29 09:55, Henning Brauer a écrit :
Wouldn't it be better if libasr would run A and requests in
parallel? Whichever response arrives first wins.
no, since that gives extremely unpredictable results.
How about this then:
- Run both requests in parallel.
- When one response is
On Tue, Apr 29, 2014 at 08:57:57AM -0400, Simon Perreault wrote:
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear
* Simon Perreault si...@per.reau.lt [2014-04-29 16:05]:
Le 2014-04-29 09:55, Henning Brauer a écrit :
Wouldn't it be better if libasr would run A and requests in
parallel? Whichever response arrives first wins.
no, since that gives extremely unpredictable results.
How about this
Le 2014-04-29 09:52, Giancarlo Razzolini a écrit :
I disable ipv6 across all my linux desktops installations because some
daemons aren't smart enough to not try it first. Postfix is one that
comes from the top of my mind.
That's why we needed AI_ADDRCONFIG. The point is that getaddrinfo()
On Tue, Apr 29, 2014 at 10:04:35AM -0400, Simon Perreault wrote:
Le 2014-04-29 09:55, Henning Brauer a ?crit :
Wouldn't it be better if libasr would run A and requests in
parallel? Whichever response arrives first wins.
no, since that gives extremely unpredictable results.
How
On 2014/04/29 10:52, Giancarlo Razzolini wrote:
Em 29-04-2014 04:51, Stuart Henderson escreveu:
Too soon I think. Wait a little longer and more major ISPs will turn
IPv4 into the second class citizen as they fumble with their cgnat
deployments then this will make a lot more sense. Now that
On Tue, Apr 29, 2014 at 10:04, Simon Perreault wrote:
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results as usual.
- Otherwise, kill the second
On 29 April 2014 09:59, Simon Perreault si...@per.reau.lt wrote:
Le 2014-04-29 09:44, Kenneth Westerback a écrit :
Why would having the IPv6 addresses come first in the returned list be
required to 'use' them? Please explain.
Well I thought this would be obvious, but applications using
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results as usual.
- Otherwise, kill the second request and
Penned by Kenneth Westerback on 20140429 8:44.16, we have:
| On 29 April 2014 08:57, Simon Perreault si...@per.reau.lt wrote:
| Le 2014-04-28 18:43, Kenneth Westerback a écrit :
| Why is the burden on everyone to provide 'valid' objections?
|
| I know that what I proposed cannot go in at the
Penned by Otto Moerbeek on 20140429 9:07.54, we have:
| On Tue, Apr 29, 2014 at 10:04:35AM -0400, Simon Perreault wrote:
|
| Le 2014-04-29 09:55, Henning Brauer a ?crit :
| Wouldn't it be better if libasr would run A and requests in
| parallel? Whichever response arrives first wins.
|
On 2014-04-29, Mark Kettenis mark.kette...@xs4all.nl wrote:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Isn't there a correlation between those countries and actual IPv6 usage?
According to
On 29 April 2014 12:57, Christian Weisgerber na...@mips.inka.de wrote:
On 2014-04-29, Mark Kettenis mark.kette...@xs4all.nl wrote:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Isn't there a
On Tue, Apr 29, 2014 at 04:57:28PM +, Christian Weisgerber wrote:
On 2014-04-29, Mark Kettenis mark.kette...@xs4all.nl wrote:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Isn't there a
On Tue, Apr 29, 2014 at 10:52:06AM -0300, Giancarlo Razzolini wrote:
| Em 29-04-2014 04:51, Stuart Henderson escreveu:
| Too soon I think. Wait a little longer and more major ISPs will turn
| IPv4 into the second class citizen as they fumble with their cgnat
| deployments then this will make a
Em 29-04-2014 17:25, Paul de Weerd escreveu:
Disabling IPv6 should not be necessary: it shouldn't be enabled by
default, even link-local addresses.
Exactly my point. Even with only link local addresses, some daemons bind
to tcp6 wildcard sockets and I can detect delays when using a linux with
On Tue, Apr 29, 2014 at 2:25 PM, Paul de Weerd we...@weirdnet.nl wrote:
Why oh why can I bring up an interface and have attackers probe me
over IPv6 on a default OpenBSD install while they cannot do so over
IPv4? Why is IPv6 more enabled than IPv4? IPv4 takes configuration
before it will
On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote:
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results
On 2014/04/29 22:25, Paul de Weerd wrote:
Disabling IPv6 should not be necessary: it shouldn't be enabled by
default, even link-local addresses.
If doing this, then we need a way to enable link-local, like the opposite
of ifconfig $if -inet6. Current process to re-enable just the link-local
is
previously on this list Stuart Henderson contributed:
My thinking is that *if* someone has taken steps to enable v6,
then programs should try to use it for comms where possible.
family inet6 inet4 is too blunt and affects people who don't want
to touch v6.
I'm used to seeing NOINET6 in
On 04/30/14 00:12, Ted Unangst wrote:
On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote:
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer
On 04/30/14 01:45, Alexander Hall wrote:
However, doing the requests in parallel, each geting the same treatment
as if done in sequence (timing out if need be, etc), and then sort them
by the family directive as per resolv.conf could in theory cut the
lookup time in half...
Not that this has
I know that what I proposed cannot go in at the moment. It's my end
goal.
The goal is ridiculous.
If anything, it should be sorted by the best addresses first. Today
the best addresses are IPv4. There is no dynamic method to determine
best, but measurements all over the world show that IPv4
Someone has to take the first/next step, and that's a very
traditional role for OpenBSD.
Apply these kinds of changes to your entire production network,
and report back in 6 months if you are still running them.
On Tue 29 Apr 2014 09:04:36 PM CDT, Theo de Raadt wrote:
I know that what I proposed cannot go in at the moment. It's my end
goal.
The goal is ridiculous.
If anything, it should be sorted by the best addresses first. Today
the best addresses are IPv4. There is no dynamic method to determine
However, based on available evidence, IPv4 is not better than IPv6 in
every respect for everyone.
You've written a long mail and completely missed the point.
This is not a conversation about your IPv6 connection.
It is about what the sensible default should be for everyone.
On 28 April 2014 18:05, Simon Perreault si...@per.reau.lt wrote:
Tech,
Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil master plan:
make getaddrinfo() return IPv6 results first by default.
Why is the burden on everyone to provide 'valid' objections? Should
not the burden be
Kenneth Westerback [kwesterb...@gmail.com] wrote:
Why is the burden on everyone to provide 'valid' objections? Should
not the burden be on you to at least hint at a point to this change?
Given the miniscule IPv6 usage out there, why should IPv6 come first?
I like how IPv6 support turns
You may not be aware of 'family inet4 inet6' default in resolv.conf that was
specifically changed to that for OpenBSD.
The reasoning given is .. IPv6 is a 2nd class netizen in terms of reliability
and user experience.
If you disagree, consider making the world more robust where IPv6 is
On April 28, 2014 5:43:34 PM CDT, Kenneth Westerback kwesterb...@gmail.com
wrote:
On 28 April 2014 18:05, Simon Perreault si...@per.reau.lt wrote:
Tech,
Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil
master plan:
make getaddrinfo() return IPv6 results first by default.
Why
On Tue, Apr 29, 2014 at 2:05 AM, Simon Perreault si...@per.reau.lt wrote:
Tech,
Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil master plan:
make getaddrinfo() return IPv6 results first by default.
The diff below would be the end goal. I guess people will have valid
44 matches
Mail list logo
