Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line..

From: George Michaelson <[email-masked]>
Date: Thu, 4 Aug 2011 18:44:15 +1000

In the spirit of full disclosure, I re-ran the tests.

I also added www.arin.net and some other nodes, including www.afrinic.net.

The new state of play, is that the three sites I tried 2 days ago now work on IPv6, and ARIN worked on IPv6 for about 6 reloads, and now preferences IPv4, and AfriNIC persists on preferring IPv6.

Secondly, I tested in two browsers. The state acquired from one Browser (chrome) appeared to me, to be carried into the other browser (Safari) So, to the extent this system is implemented 'below' the application

	IT WORKED.

Now, James, or anyone else is more than welcome to pull the rug from under me, And I won't complain. Maybe its all a big hoax. More fool me.

But right now:
	
1) its adaptive: just because yesterday it preferred V4 doesn't mean it prefers V4 today

2) its consistent: once it has a local preference in the kernel/userspace model, it appears to apply it properly across applications

3) its behaviour preferences the user experience over the network architect goals.

So, with no desire to be rancorous, or upset people, I just want to say

	I DONT SEE WHAT THE PROBLEM IS HERE.

As far as I am concerned, Apple have done a good thing (tm) and, it does what they say it does (tm) and I am happy.

End.

As Randy says "I wish my competitors would do something which drives traffic to me" and, in that respect, I am very sorry but Apple aren't playing. This is not a move which will force randys competitors customers to prefer Randy.

If you want IPv6 to take off, you have to do it so its INFRASTRUCTURE (which is what Internode has done) and you have to make its RTT/Bandwidth-delay follow IPv4 within some sigma of difference (which is what Internode has done) and if you do this, then Apple's code logically can decide that IPv6 is better, and use it.

It works guys.

Can we move on now?

-George

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 4 Aug 2011 11:20:31 +0200

On Thu, Aug 04, 2011 at 06:44:15PM +1000, George Michaelson wrote:
> If you want IPv6 to take off, you have to do it so its INFRASTRUCTURE
> (which is what Internode has done) and you have to make its
> RTT/Bandwidth-delay follow IPv4 within some sigma of difference
> (which is what Internode has done) and if you do this, then Apple's
> code logically can decide that IPv6 is better, and use it.

To reliably prefer IPv6, the IPv6 infrastructure has to have BETTER RTT
than IPv4. At least as far as I understand the reports and Apple's
comments/description as there is no headstart for IPv6.

Assuming the IPv4 topology is "as good as it gets" (within the
commercial bounds given), it's "hard" to be better in IPv6, ack?
So, you have to intentionally make IPv4 worse than it could be to bias
in favor of IPv6.

Just because you ran some samples which today preferred IPv6 by luck,
doesn't mean the equation resolves to that on grand scale.

Unless I'm missing something.

Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: George Michaelson <[email-masked]>
Date: Thu, 4 Aug 2011 20:03:14 +1000

> comments/description as there is no headstart for IPv6.

I am probably talking past you, and several other people.

I don't think its my mission in life to "reliably prefer IPv6".

Do you think this is a rational position to take, right now? Reliably? 

> So, you have to intentionally make IPv4 worse than it could be to bias

I have no intention of asking anyone to make IPv4 worse. That is silly. I said so, 3 posts ago.

I believe that coding systems to explore 4 and 6, and based on hysteresis, some heuristics, measurements and held state in a kernel or routing table or some other construct, decide a preference case-by-case is fine.

And, if it varies, thats fine too.

> doesn't mean the equation resolves to that on grand scale.

Just because I relay anecdotes, doesn't mean I believe they are statistics.

I have explored what *I* experience, as a user, @home on a true (native) IPv6 ADSL2+ service which is dual-homed.

I have explored what I experience, in OSX Lion and before that in Snow Leopard.

As a user, V4/V6 Agnostic: I think the Lion state is better.

> Unless I'm missing something.

Like I say. I think I'm probably talking past some people.

Maybe its time to Ask Fred.

Fred: with your WG chair hat on. Is it actually held, by V6OPS to be a FAIL if you find a system logically prefers IPv4 to IPv6? I think thats a bit silly, but maybe thats the ethos of the group. In Dual_Stack, isn't that actually a rational choice?

I figure a bunch of people might find that very very surprising.

-G

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Gert Doering <[email-masked]>
Date: Thu, 4 Aug 2011 12:11:05 +0200

Hi,

On Thu, Aug 04, 2011 at 08:03:14PM +1000, George Michaelson wrote:
> Fred: with your WG chair hat on. Is it actually held, by V6OPS
> to be a FAIL if you find a system logically prefers IPv4 to IPv6?
> I think thats a bit silly, but maybe thats the ethos of the group.
> In Dual_Stack, isn't that actually a rational choice?
> 

If we assume IPv4 is here to stay, then "take whatever works better"
is the right thing.

If we assume IPv4 is coming with extra costs, and more interesting failure
modes, etc. (due to LSN/CGN, v4-over-v6 tunneling, ...), I'd like to see
a (small) bias towards IPv6.  HE with some 10-30ms initial delay for v4, 
or so.

It's not "just user experience today", it's also "moving the majority of
the network traffic towards v6" that should the goal, so that we can turn
off IPv4 eventually.  Which will only be done if most of the traffic has
moved - which will not happen if clients will continue to use it if it's
"as fast as IPv6".

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

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 4 Aug 2011 12:14:06 +0200

> Do you think this is a rational position to take, right now? Reliably? 

If there is no good reason (read: noticable[!] performance gain) to use
IPv4, yes.

> I have no intention of asking anyone to make IPv4 worse. That is silly.

You don't, but effectively operators will do so as there is significant
economic advantage to do if endpoints don't prefer IPv6 where reasonably
possible. So when you say that it's OK to have traffic go via IPv4 where
IPv6 could be used instead with reasonable quality, you also accept the
fact of senseless cost to operators (and thus in the end, for end
users). To mitigate that, operators are forced to actively intervene.

> And, if it varies, thats fine too.

No it's not, in the big picture. Technically it is (ignoring the NAT for
IPv4 vs non-NAT in IPv6), but economically it's not.

> Just because I relay anecdotes, doesn't mean I believe they are statistics.

OK.

Best regards,
Daniel

---

From: Philip Homburg <[email-masked]>
Date: Thu, 04 Aug 2011 12:17:31 +0200

>Do you think this is a rational position to take, right now? Reliably? 

Well, if you want to put it that way, I think it is my mission in life to
reliably avoid anything that includes NAT.

End-to-end IPv4, great. No reason to prefer IPv6 at all.

You can't really tell whether the far end has full IPv4, but just
prefering IPv6 when the local IPv4 address is not global will probably
already help a lot.

---

From: Sander Steffann <[email-masked]>
Date: Thu, 4 Aug 2011 12:22:29 +0200

Hi,

> If there is no good reason (read: noticable[!] performance gain) to use

So maybe we should be talking about percentages instead of '30 ms' or some other fixed number. Something like 'If IPv4 is ≥10% faster than IPv6 it's ok to prefer IPv4'. From a user's point of view I agree with what Apple is doing. From a long-term migration point of view (taking CGN costs into account etc) I agree that preferring IPv6 is important. So maybe we can find a middle ground here?

Sincerely,
Sander Steffann

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Aug 2011 07:52:54 -0400

> 	I DONT SEE WHAT THE PROBLEM IS HERE.

+1

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Aug 2011 07:55:31 -0400

> prefering IPv6 when the local IPv4 address is not global will probably

+1.

provided, of course, that there's a reliable way to determine if you're behind an LSN that doesn't happen to assign RFC 1918 addresses.

Keith

---

From: Ray Bellis <[email-masked]>
Date: Fri, 5 Aug 2011 10:28:47 +0000

On 4 Aug 2011, at 11:03, George Michaelson wrote:

Perhaps we should repurpose the IPv4 evil bit as an indication of a path that is not "end-to-end" transparent ;-)

i.e.:

"An IPv4 NATing device MUST set the evil bit on all packets to which it has applied NAT.  All else being equal, a client SHOULD prefer an IPv6 path over an IPv4 path that has the evil bit set."

[only half kidding]

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 5 Aug 2011 10:49:23 +0000

> "An IPv4 NATing device MUST set the evil bit on all packets to which it has applied NAT.  All else being equal, a client SHOULD prefer an IPv6 path over an IPv4 path that has the evil bit set."

Ah, I see RFC 3514 already said that the evil bit SHOULD be set by NAT boxes.

If we changed the rest of the RFC 3514 rules it _might_ just work, though ;-)

Ray

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 5 Aug 2011 14:44:17 +0200

On Fri, Aug 05, 2011 at 10:28:47AM +0000, Ray Bellis wrote:
> Perhaps we should repurpose the IPv4 evil bit as an indication
> of a path that is not "end-to-end" transparent ;-)

Actually, OSX could source packets with the evil bit set, so operators
can introduce additional biasing delay only for those packets and don't
impare users of less selfish, short-sighted networking stacks. :-)

> "An IPv4 NATing device MUST set the evil bit on all packets to which
> it has applied NAT.  All else being equal, a client SHOULD prefer an
> IPv6 path over an IPv4 path that has the evil bit set."
> 
> [only half kidding]

Indeed only half kidding. SYN-ACK marking in some magic way perhaps?

Best regards,
Daniel

---

From: Keith Moore <[email-masked]>
Date: Fri, 5 Aug 2011 08:52:46 -0400

> impare users of less selfish, short-sighted networking stacks. :-)

cast-iron pot.  stainless steel kettle.

Keith