guidelines for the operation of a shared IPv4/IPv6 Internet

headers Lorenzo Colitti | 1 Oct 2011 04:25

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

On 2011-10-01 15:25, Lorenzo Colitti wrote:
> On Tue, Sep 27, 2011 at 17:16, Brian E Carpenter <
> brian.e.carpenter@...> wrote:
> 
>> I agree; maybe on/off as a MUST and the ms of bias as a MAY?
>>
>> I don't see anybody opposing the general idea, anyway.
> 
> 
> I don't think it's useful.
> 
> What would you need such a feature for? If IPv6 is as fast as IPv4, then the
> implementation should just use IPv6 all the time. If IPv6 is broken,
> wouldn't you as a user want to use IPv4 instead of using something that's
> broken?

That's not for you to say. I might want to stand on my head all day, too.

Really - as someone else said, it might well be a useful tool for
certains types of diagnosis (e.g. a user who complains about poor
browsing response - let's switch off HE to see if that's relevant).
Or there might be other reasons that I'm not smart enough to think of
until the day comes.

It seems to me that making such a complex algorithm switch-offable
is just normal engineering.

> Personally, I think that if you want to find out if IPv6 is working, you
> should use network monitoring. It's much more reliable than users with
> browsers.

That depends entirely on the problem you're faced with.

> Also: I don't think that apps will pay much attention to what the IETF says
> in regard to what settings they provide and expose to the user. Putting MUST
> here could cause applications to be in violation of the RFC even if they're
> perfectly in compliance with the actual technical requirements that matter.

And why would that be a problem for the IETF? It would be a problem for
the user, perhaps, but then they can switch to a browser that does provide
the switch.

    Brian
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

I object MUST for configuration option, as for some class of hosts,
like embedded systems, it is not always feasible to have such settings
supported.

Teemu

Sent from my Windows Phone
From: Brian E Carpenter
Sent: 28.9.2011 3:16
To: Jeroen Massar
Cc: v6ops@...
Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs
WGLC]
Marc,

On 2011-09-28 02:57, Jeroen Massar wrote:
> On 2011-09-27 15:53 , Marc Blanchet wrote:
>> Le 2011-09-27 à 09:47, Marc Blanchet a écrit :
>>
>>>>> I would like to see a knob that would have the possible values as:
>>>>> - default  (HE no pref between v4 or v6)
>>>>> - v6 (HE does pref v6 by some minimal increment)
>>>>> - off  (disable HE)
>>>>>
>>>>> The way to implement this might be:
>>>>> - off: value = 65535
>>>>> - default: value = 0
>>>>> - v6: value = number of ms "advantage for ipv6"
> [..]
>
>> btw, I can provide text if there is support in wg for this idea.
>
> I would say that it is a great thing to add, but just an on/off is
> already good enough from my POV.

I agree; maybe on/off as a MUST and the ms of bias as a MAY?

I don't see anybody opposing the general idea, anyway.

   Brian

>
> The above proposal would give the advantage to be able to easily
> distribute a site-wide (given that one control all the hosts involved)
> bonus for IPv6 in case a site is connected over a tunnel or other
> mechanism which causes a bit more latency on the IPv6 side.
>
> The other way to counter that disadvantage is just delaying IPv4 packets
> at the moment, but that is far from a proper solution.
>
> Greets,
>  Jeroen
>
> _______________________________________________
> v6ops mailing list
> v6ops@...
> https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

A qualification there would be reasonable. "For systems where user
configuration is possible ..." or something more elegant. :)

That said I tend to agree with James Woodyatt that providing a knob to
turn it off is likely to lead to the results that he predicted. In
principle I really don't like the idea of "forcing it down the user's
throats," but I think that the only way it will actually be successful
is if they can't turn it off.

OTOH, there is (obviously) no way to prevent vendors from providing one,
so perhaps what is really needed is a discussion of the merits of both
options.

Doug

On 09/30/2011 22:25, Teemu Savolainen wrote:
> I object MUST for configuration option, as for some class of hosts,
> like embedded systems, it is not always feasible to have such settings
> supported.
> 
> Teemu
> 
> Sent from my Windows Phone
> From: Brian E Carpenter
> Sent: 28.9.2011 3:16
> To: Jeroen Massar
> Cc: v6ops@...
> Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs
> WGLC]
> Marc,
> 
> On 2011-09-28 02:57, Jeroen Massar wrote:
>> On 2011-09-27 15:53 , Marc Blanchet wrote:
>>> Le 2011-09-27 à 09:47, Marc Blanchet a écrit :
>>>
>>>>>> I would like to see a knob that would have the possible values as:
>>>>>> - default  (HE no pref between v4 or v6)
>>>>>> - v6 (HE does pref v6 by some minimal increment)
>>>>>> - off  (disable HE)
>>>>>>
>>>>>> The way to implement this might be:
>>>>>> - off: value = 65535
>>>>>> - default: value = 0
>>>>>> - v6: value = number of ms "advantage for ipv6"
>> [..]
>>
>>> btw, I can provide text if there is support in wg for this idea.
>>
>> I would say that it is a great thing to add, but just an on/off is
>> already good enough from my POV.
> 
> I agree; maybe on/off as a MUST and the ms of bias as a MAY?
> 
> I don't see anybody opposing the general idea, anyway.
> 
>    Brian
> 
>>
>> The above proposal would give the advantage to be able to easily
>> distribute a site-wide (given that one control all the hosts involved)
>> bonus for IPv6 in case a site is connected over a tunnel or other
>> mechanism which causes a bit more latency on the IPv6 side.
>>
>> The other way to counter that disadvantage is just delaying IPv4 packets
>> at the moment, but that is far from a proper solution.
>>
>> Greets,
>>  Jeroen

--

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

I won't focus on the MUST/MAY selection, but i see a point in Lorenzo's comment about 
non-deterministic behavior when there is no preference between IPv4 and IPv6.
So, if there is going to be an option/knob/switch, it should probably provide just two 
options : disable (use system's preference policy), enable (if system's policy prefers 
IPv6, give X preference to IPv6 vs IPv4).
Nevertheless, i'm wondering...There is already an option to disable IPv6 in Chrome and 
Firefox (and probably other applications). Would a HE switch make any useful difference to 
users (besides troubleshooting IPv6)?
Do we expect to abandon the IPv6 switch in the future and use the HE switch only?
btw, is the application IPv6 switch described somewhere as a MUST/MAY/etc?

--
Tassos

Teemu Savolainen wrote on 1/10/2011 08:25:
> I object MUST for configuration option, as for some class of hosts,
> like embedded systems, it is not always feasible to have such settings
> supported.
>
> Teemu
>
> Sent from my Windows Phone
> From: Brian E Carpenter
> Sent: 28.9.2011 3:16
> To: Jeroen Massar
> Cc: v6ops <at> ietf.org
> Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs
> WGLC]
> Marc,
>
> On 2011-09-28 02:57, Jeroen Massar wrote:
>> On 2011-09-27 15:53 , Marc Blanchet wrote:
>>> Le 2011-09-27 à 09:47, Marc Blanchet a écrit :
>>>
>>>>>> I would like to see a knob that would have the possible values as:
>>>>>> - default  (HE no pref between v4 or v6)
>>>>>> - v6 (HE does pref v6 by some minimal increment)
>>>>>> - off  (disable HE)
>>>>>>
>>>>>> The way to implement this might be:
>>>>>> - off: value = 65535
>>>>>> - default: value = 0
>>>>>> - v6: value = number of ms "advantage for ipv6"
>> [..]
>>
>>> btw, I can provide text if there is support in wg for this idea.
>> I would say that it is a great thing to add, but just an on/off is
>> already good enough from my POV.
> I agree; maybe on/off as a MUST and the ms of bias as a MAY?
>
> I don't see anybody opposing the general idea, anyway.
>
>     Brian
>
>> The above proposal would give the advantage to be able to easily
>> distribute a site-wide (given that one control all the hosts involved)
>> bonus for IPv6 in case a site is connected over a tunnel or other
>> mechanism which causes a bit more latency on the IPv6 side.
>>
>> The other way to counter that disadvantage is just delaying IPv4 packets
>> at the moment, but that is far from a proper solution.
>>
>> Greets,
>>   Jeroen
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> v6ops <at> ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops <at> ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

On Fri, Sep 30, 2011 at 01:57:26PM -0700, Lorenzo Colitti wrote:
> To those who say that the algorithm shouldn't prefer IPv6, I disagree. I
> think we all agree that IPv6 is the right way forward in the long term. Our
> problem now is that enabling IPv6 causes lots of pain to a small amount of
> users, and we can't move forward. However, if the maximum impact is 300ms
> additional latency on the first TCP connection to 0.1% of users, then a case
> can be made that it's worth it.

Can't agree more. And I disagree with Marc Blanchet's suggestion to not
bias in favor of IPv6 by default - that's from my PoV the wrong path to
travel. If IPv6 usage is viable, we really really shall use it and avoid
IPv4. This requires the mentioned bias/head-start for IPv6.

> As the draft correctly observes, it's hard to make IPv6 faster than IPv4 if
> everything is running on the same infrastructure (which is the only sane way
> to transition); if you do everything right, you'll get parity. So algorithms
> that try to pick the fastest connection every time will just end up choosing
> one or the other non-deterministically, or - worse - in the arbitrary order
> that they end up doing DNS lookups.

Indeed, and I'm pretty sure operators will look into ways to enforce
bias, e.g. by introducing artificial delays to IPv4 on NATs.

Best regards,
Daniel

--

-- 
CLUE-RIPE -- Jabber: dr@... -- dr <at> IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

On 2011-10-01 20:02, Tassos Chatzithomaoglou wrote:
> I won't focus on the MUST/MAY selection, but i see a point in Lorenzo's

I can see the argument for a SHOULD, since some low end systems might
find such a switch to be a burden (but they might find the whole
of HE to be a burden, too).

> comment about non-deterministic behavior when there is no preference
> between IPv4 and IPv6.
> So, if there is going to be an option/knob/switch, it should probably
> provide just two options : disable (use system's preference policy),
> enable (if system's policy prefers IPv6, give X preference to IPv6 vs
> IPv4).
> Nevertheless, i'm wondering...There is already an option to disable IPv6
> in Chrome and Firefox (and probably other applications). Would a HE
> switch make any useful difference to users (besides troubleshooting IPv6)?

We would be very arrogant to answer that question; users are entitled
to decide what's useful to them. An HE switch is quite orthogonal to
an "ignore IPv6" switch; both are needed (and there should be an
"ignore IPv4" switch too, for completeness).

> Do we expect to abandon the IPv6 switch in the future and use the HE
> switch only?

Why do we care what users choose to do? It's their business.

> btw, is the application IPv6 switch described somewhere as a MUST/MAY/etc?

Not that I'm aware of. I assume it was implemented to help users
who were impacted by IPv6 connectivity issues. I've used it myself for
exactly that reason, in both Firefox and Thunderbird.

I wonder how many people on this list are running a dual stack desktop
or laptop device continuously?

    Brian

> 
> -- 
> Tassos
> 
> 
> Teemu Savolainen wrote on 1/10/2011 08:25:
>> I object MUST for configuration option, as for some class of hosts,
>> like embedded systems, it is not always feasible to have such settings
>> supported.
>>
>> Teemu
>>
>> Sent from my Windows Phone
>> From: Brian E Carpenter
>> Sent: 28.9.2011 3:16
>> To: Jeroen Massar
>> Cc: v6ops <at> ietf.org
>> Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs
>> WGLC]
>> Marc,
>>
>> On 2011-09-28 02:57, Jeroen Massar wrote:
>>> On 2011-09-27 15:53 , Marc Blanchet wrote:
>>>> Le 2011-09-27 à 09:47, Marc Blanchet a écrit :
>>>>
>>>>>>> I would like to see a knob that would have the possible values as:
>>>>>>> - default  (HE no pref between v4 or v6)
>>>>>>> - v6 (HE does pref v6 by some minimal increment)
>>>>>>> - off  (disable HE)
>>>>>>>
>>>>>>> The way to implement this might be:
>>>>>>> - off: value = 65535
>>>>>>> - default: value = 0
>>>>>>> - v6: value = number of ms "advantage for ipv6"
>>> [..]
>>>
>>>> btw, I can provide text if there is support in wg for this idea.
>>> I would say that it is a great thing to add, but just an on/off is
>>> already good enough from my POV.
>> I agree; maybe on/off as a MUST and the ms of bias as a MAY?
>>
>> I don't see anybody opposing the general idea, anyway.
>>
>>     Brian
>>
>>> The above proposal would give the advantage to be able to easily
>>> distribute a site-wide (given that one control all the hosts involved)
>>> bonus for IPv6 in case a site is connected over a tunnel or other
>>> mechanism which causes a bit more latency on the IPv6 side.
>>>
>>> The other way to counter that disadvantage is just delaying IPv4 packets
>>> at the moment, but that is far from a proper solution.
>>>
>>> Greets,
>>>   Jeroen
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> v6ops <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
> _______________________________________________
> v6ops mailing list
> v6ops <at> ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Hi,

On Sun, Oct 02, 2011 at 08:01:10AM +1300, Brian E Carpenter wrote:
> I wonder how many people on this list are running a dual stack desktop
> or laptop device continuously?

All our corporate desktops and all my home machines are dual-stack all
the time.  (They need to do IPv6, and the alternatives are dual-stack or
NAT64 - and NAT64 does not yet make sense *for us*).

My laptop takes what it's fed - right now I'm typing this on an IPv4 only
3G link, and it has encountered IPv6-only networks, but most of the time 
it has dual-stack as well...

Gert Doering
        -- NetMaster
--

-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

On 2011-10-02 09:42, Lorenzo Colitti wrote:
> On Sat, Oct 1, 2011 at 12:01, Brian E Carpenter
<brian.e.carpenter@... wrote:
...
>> I wonder how many people on this list are running a dual stack desktop
>> or laptop device continuously?
> 
> 
> What do you mean by continuously? 

I guess "normally" instead of "continuously" would be a better question, but
I have found situations (see below) where switching off IPv6 is better.

> I have IPv6 at work, I have it at home,
> and I have it when I go to conferences. I don't have it when I attach to the
> shuttle wifi network, but if I don't work on the shuttle then I suppose it's
> continuous. Why do you ask?

Genuine curiosity. Here we all are giving strong opinions about v6 operations,
so I was wondering how many of us actually use it daily. I was quite sure that
you (Lorenzo) did. I do, but I have to use a tunnel from home and have found that
when on travel in IPv4-only land, the performance penalty for the tunnel is
usually unacceptable. So my suggestion that HE should be biased towards IPv6
but not too much, and the suggestion that it should have an on/off switch, are
both based on personal experience.

On 2011-10-02 21:59, Gert Doering wrote:
...
> All our corporate desktops and all my home machines are dual-stack all
> the time.  (They need to do IPv6, and the alternatives are dual-stack or
> NAT64 - and NAT64 does not yet make sense *for us*).
> 
> My laptop takes what it's fed - right now I'm typing this on an IPv4 only
> 3G link, and it has encountered IPv6-only networks, but most of the time 
> it has dual-stack as well...

Would you want HE by default *always*?

   Brian
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

346	June 2013
211	May 2013
85	April 2013
762	March 2013
402	February 2013
161	January 2013
54	December 2012
166	November 2012
218	October 2012
342	September 2012
453	August 2012
231	July 2012
116	June 2012
433	May 2012
249	April 2012
368	March 2012
264	February 2012
137	January 2012
266	December 2011
569	November 2011
386	October 2011
96	September 2011
375	August 2011
500	July 2011
207	June 2011
444	May 2011
547	April 2011
312	March 2011
604	February 2011
279	January 2011
580	December 2010
327	November 2010
421	October 2010
208	September 2010
175	August 2010
80	July 2010
34	June 2010
9	May 2010
223	April 2010
278	March 2010
63	February 2010
135	January 2010
24	December 2009
44	November 2009
47	October 2009
41	September 2009
91	August 2009
163	July 2009
28	June 2009
55	May 2009
57	April 2009
216	March 2009
27	February 2009
27	January 2009
36	December 2008
114	November 2008
68	October 2008
58	September 2008
134	August 2008
489	July 2008
91	June 2008
61	May 2008
284	April 2008
130	March 2008
141	February 2008
186	January 2008
127	December 2007
128	November 2007
138	October 2007
79	September 2007
70	August 2007
237	July 2007
32	June 2007
76	May 2007
145	April 2007
163	March 2007
29	February 2007
27	January 2007
33	December 2006
43	November 2006
37	October 2006
20	September 2006
30	August 2006
123	July 2006
78	June 2006
83	May 2006
53	April 2006
80	March 2006
34	February 2006
48	January 2006
25	December 2005
51	November 2005
65	October 2005
42	September 2005
159	August 2005
48	July 2005
29	June 2005
45	May 2005
100	April 2005
74	March 2005
30	February 2005
68	January 2005
44	December 2004
308	November 2004
131	October 2004
108	September 2004
236	August 2004
172	July 2004
177	June 2004
187	May 2004
179	April 2004
283	March 2004
135	February 2004
40	January 2004
32	December 2003
409	November 2003
194	October 2003
167	September 2003
124	August 2003
237	July 2003
53	June 2003
91	May 2003
24	April 2003
199	March 2003
154	February 2003
128	January 2003
139	December 2002
288	November 2002
123	October 2002
480	September 2002
4	August 2002

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

Re: draft-ietf-v6ops-happy-eyeballs WGLC

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

Re: On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

IPv6-ness

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31