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 -
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.
Workin
> 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 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 determin
> 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.
> 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
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 a
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
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 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
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
On Tue, Apr 29, 2014 at 2:25 PM, Paul de Weerd 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 work, IPv6 wo
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
t
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
On Tue, Apr 29, 2014 at 04:57:28PM +, Christian Weisgerber wrote:
> On 2014-04-29, Mark Kettenis 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 be
On 29 April 2014 12:57, Christian Weisgerber wrote:
> On 2014-04-29, Mark Kettenis 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 a
On 2014-04-29, Mark Kettenis 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 "Akamai's State of the I
> Date: Tue, 29 Apr 2014 09:55:58 -0400
> From: Simon Perreault
>
> 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].
Isn't there a correlation between those count
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 "w
Penned by Kenneth Westerback on 20140429 8:44.16, we have:
| On 29 April 2014 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
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 reque
On 29 April 2014 09:59, Simon Perreault 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
> getaddrinfo() t
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 secon
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
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.
>
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()
sh
* Simon Perreault [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 then:
>
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 p
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
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 wh
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
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].
* Simon Perreault [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 should IPv6 c
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
* Simon Perreault [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...
--
Henning Brauer, h
On 29 April 2014 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 the
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 hel
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 p
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 lik
* Adam Thompson [2014-04-29 04:37]:
> On April 28, 2014 5:43:34 PM CDT, Kenneth Westerback
> wrote:
> >On 28 April 2014 18:05, Simon Perreault wrote:
> >> Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil
> >master plan:
> >> make getaddrinfo() return IPv6 results first by defau
On Tue, Apr 29, 2014 at 2:05 AM, 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
On April 28, 2014 5:43:34 PM CDT, Kenneth Westerback
wrote:
>On 28 April 2014 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.
>
>Why is the burden on everyone
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 concerned,
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
On 28 April 2014 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.
Why is the burden on everyone to provide 'valid' objections? Should
not the burden be on you to at l
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 know what they are.
Would it be necessary/desirable to
46 matches
Mail list logo
