Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Jun 2011 12:18:06 -0400 (EDT)

> From: Lorenzo Colitti <[email-masked]>

    > Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure
    > rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the
    > only change is to not use 6to4 by default.
    > ...
    > So the existence of 6to4 is in itself a significant barrier for IPv6
    > deployment

Surely you meant to say "the _incorrect configuration_ of 6to4 is in itself a
significant barrier"?

I get the impression that the problem comes in when 6to4 is configured on by
default, and too high in the priority list (as opposed to native, other
methods, etc). So fix the real issue, don't try and prematurely kill off
something that's being used by lots of people.

	Noel

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Jun 2011 09:38:34 -0700

> Surely you meant to say "the _incorrect configuration_ of 6to4 is in itself

You cannot expect something to be configured correctly if it is simply
turned on without a) being managed by someone or b) detection mechanisms to
see if it's working. Sadly, anycasted 6to4 meets neither of these
conditions.

> I get the impression that the problem comes in when 6to4 is configured on
> by default, and too high in the priority list (as opposed to native, other

I fundamentally disagree. I really don't think that 6to4 is used by "lots"
of people for applications that wouldn't just use (more reliable) IPv4 if
6to4 wasn't there.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jun 2011 11:15:39 -0700

You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions.
ISATAP meets both of these conditions:

http://tools.ietf.org/html/draft-templin-v6ops-isops

Fred

---

From: james woodyatt <[email-masked]>
Date: Tue, 14 Jun 2011 10:30:12 -0700

On Jun 10, 2011, at 09:38 , Lorenzo Colitti wrote:
> 
> I fundamentally disagree. I really don't think that 6to4 is used by "lots" of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there.

The same is often said about IPv6 in general.

That's not meant to be snarky quip.  When you limit the population under observation to just current IPv6 users and leave out the vast teeming masses of people who are routed IPv4-only, I suspect the data will show that a significant fraction of people are still using 6to4 as a general network-layer NAT-avoidance mechanism because it continues to work for them, setting up a manual tunnel-broker account takes an order of magnitude more effort, and who has time?  Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends.

The way to find these people is to crawl the BitTorrent networks.  What's that old maxim?  "You can't test what you don't measure."  Do you measure the BitTorrent networks?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Jun 2011 10:59:47 -0700

On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt <[email-masked]> wrote:
>
> Very few of the people using 6to4 in this way will show up in Google's user
> behavior analysis, of course, because Google doesn't run its own 6to4
> return-path relay as I-D.ietf-v6ops-6to4-advisory recommends.
>

We would not see these users even if we operated reverse path relays as
recommended in the draft - from the point of view of the server, in both
cases it's just a TCP connection to a 2002::/16 address, regardless of
whether the relay is inside the Google network or outside it.

Those users would become visible if we added AAAA records with 6to4
addresses, but that's a bad plan because it would likely lead to the
double-digit connection failure rates that Geoff observes. It would also
become visible if Google operated an open anycast relay, which we do not
plan to do.

> The way to find these people is to crawl the BitTorrent networks.  What's
> that old maxim?  "You can't test what you don't measure."  Do you measure
> the BitTorrent networks?

No, we don't. The measurements we conduct have the purpose of determining
the impact of adding AAAA records to web sites, so we don't measure the
population of users that has 6to4 but does not use it to make HTTP
connections to dual-stack websites. We do measure the impact of 6to4 on the
reliability of websites indirectly, e.g., by observing the difference
between OSes that prefer IPv4 over 6to4 and OSes that don't.

Also, is there a way we can put this debate to rest using real data? What if
we asked someone like Hurricane Electric how much traffic on their network
is native IPv6 vs. 6to4?

That said, I would argue that most or all 6to4 traffic could just as well
use IPv4, since both parties to the communication obviously have access to a
public IPv4 address. What is the advantage of using 6to4 over IPv4 that
makes it worth suffering an 80% failure rate?

---

From: Mark Smith <[email-masked]>
Date: Wed, 15 Jun 2011 08:10:50 +0930

On Tue, 14 Jun 2011 10:59:47 -0700

> become visible if Google operated an open anycast relay, which we do not

I don't know if it is intentional, however if I use Google's public
8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4
(via /etc/gai.conf under Linux/glibc), it seems that the video content
of all youtube videos is now being delivered over IPv6. The same thing
happens if I use my ISP's resolvers - I know they're doing IPv6 work
behind the scenes, however I don't know but dont think their
resolvers are Google whitelisted. That suggests that if there are hosts
out there that blindly prefer tunnelled IPv6 over native IPv4, and
have 6to4 available, there is a likelyhood that more people are using
6to4 now than there was before World IPv6 day.

I'm having no performance problems at all with any videos I
select, including 1080P ones.

> makes it worth suffering an 80% failure rate?

I'm having and have been having 100% success rate (or near enough to it
that I can remember) using 6to4 for a number of years, including with
an IPv6 MTU of as large as my PPPoE connection will support i.e. my
6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos
are coming over IPv6, I've paid a bit more attention to the "quality of
experience" I've had, and have not found any reasons to change my
preference back to native IPv4 instead of 6to4.

---

From: Erik Kline <[email-masked]>
Date: Tue, 14 Jun 2011 16:05:33 -0700

The youtube folks made the decision to leave the video-serving
hostnames available in blacklist-mode, meaning only very broken
networks won't get AAAAs.

This is being watched, and could easily change back.  The exact policy
for blacklisting has yet to be fully formalized.

But re: 6to4 in this case, it still gains you nothing you didn't
already have while risking randomly crappy performance.

---

From: Mark Smith <[email-masked]>
Date: Wed, 15 Jun 2011 09:00:02 +0930

On Tue, 14 Jun 2011 16:05:33 -0700

> already have while risking randomly crappy performance.

A less used content cache could give me better performance. Not that it
has happened recently, however in the past there have been IPv4
delivered performance issues with youtube here in .au. That's the
reason I've paid a bit more attention to the quality of IPv6 delivery
and tried 1080P videos when they've been available.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Jun 2011 15:04:24 -0700

On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith <
[email-masked]> wrote:

> of all youtube videos is now being delivered over IPv6.
>

Yes, YouTube videos are currently being served on dual-stack hostnames. The
percentage of YouTube users that uses 6to4 is less than 0.02%. The
percentage of YouTube users that uses native IPv6 is approximately 0.2% -
over 10x more.

> preference back to native IPv4 instead of 6to4.

Sure - you're one of the 80% for whom it works. But that wasn't my question
- my question was "what is the advantage?" You said that you have near
enough 100% success rate, but I bet that your IPv4 success rate is near
enough 100% as well. So what are you gaining by using 6to4 to talk to
YouTube?

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Jun 2011 18:58:41 -0400

On Jun 14, 2011, at 1:59 PM, Lorenzo Colitti wrote:

> That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate?

it can communicate with hosts that have only IPv6,
it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way,
it can be used to develop and test IPv6 applications without having to build a special-purpose network,
it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed,
it can be deployed on either a single host or a network

again, trying to judge how well 6to4 works by how well it works with web sites that also support IPv4 is entirely missing the point.

Keith

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Jun 2011 16:10:12 -0700

On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore <[email-masked]>wrote:

> it can communicate with hosts that are stuck behind a single IPv4 address
> (if the router acts as a 6to4 gateway) without a NAT being in the way,

... about 80% of the time.

I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using
configured tunnels, and that case 2 is today solved more reliably, and in
more cases (e.g., when no public IPv4 address is available at the border) by
the various NAT traversal mechanisms that are implemented in applications.
But I think we're just going around in circles here.

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Jun 2011 19:38:45 -0400

On Jun 15, 2011, at 7:10 PM, Lorenzo Colitti wrote:

> On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore <[email-masked]> wrote:

A single figure doesn't really describe the situation.   The successes/failures aren't independent of one another.  It's not that you get only an 80% probability of things working on every connection.  It's more like, it either works fairly well for what you need it to do, or it doesn't.

Again, don't assume that this is like the web and the connections are mostly client-to-server, or one source to large numbers of different destinations.

> I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels,

There are lots of different tunneling methods each with strengths and weaknesses.   What you probably do in practice is try one, and if that doesn't work for your purposes, try another.  6to4 is very easy to try, and it often works. 

Keith

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Jun 2011 11:21:40 +1000

In message <BANLkTi=[email-masked]>
> ... about 80% of the time.

Or 99.999% of the time once you get it setup.  The problem isn't 6to4, it's
*automatic* 6to4.
 
> But I think we're just going around in circles here.
 
Which often times requires special software to be installed.  Tunnels
are a lot more hassle to setup and yes I've used both so I know.

6to4 historic is throwing the baby out with the bath water.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Jun 2011 18:43:23 -0700

> Or 99.999% of the time once you get it setup.  The problem isn't 6to4, it's

No, because you often end up being dependent on the whims of BGP and
third-party relays for your return path. Sure, if you have enough control
over routing in a closed network, you can make sure the right relays are
used. But in that case, why not use configured tunnels?

> 6to4 historic is throwing the baby out with the bath water.

On this we know we disagree.

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jun 2011 12:15:17 +0930

On Wed, 15 Jun 2011 18:43:23 -0700
Lorenzo Colitti <[email-masked]> wrote:

> third-party relays for your return path.

If you generalise that statement a bit,

"No, because you often end up being dependent on the whims of BGP and
third-party routers for your return path."

you're describing the trust inherent in the operation of the Internet,
both for IPv4 and IPv6.

Yes there are some incompetent operators out there, but most of them
aren't - they wouldn't keep their jobs otherwise, and the Internet
would break more often than it does. I can only remember one instance
of 6to4 relay breakage in the last 5 years, and IIRC that was fixed
within 24 hours.

People seem to be using a very coarse "less than absolute 100% success
means total technology failure" to state that 6to4 as a whole is
unreliable. Where is the data to back this up? Did Geoff Huston do any
more detailed analysis of the 6to4 data, other than measuring success
verses failure rates for 6to4 connections? Could I, for example, have
warped his 6to4 failure rates during the test if I used all my 2^16 x
2^64 IPv6 6to4 addresses to purposely create excessive failed 6to4
connections apparently from many different hosts? I'm certainly not
saying that exists in Geoff's data, rather asking how do we know that
it doesn't?

I have a vested interest in anycast 6to4 continuing to exist, because it
has been as reliable as any other Internet technology I use. I also
think it has some latency advantages over configured tunnels because my
IPv6 traffic enters the IPv6 Internet where ever the closest 6to4 relay
reachable via IPv4 is. That used to be in Europe (around 14000 Km from
me) when I first started using 6to4, now it is only around 3000 Km,
and as my ISP is going to deploy a 6to4 relay in the near future,
will be around 8Km away. These changes have and will continue to be
transparent on my end. I'd also get these latency benefits if I was
changing my IPv4 Internet points of attachment, such as if I were
travelling internationally.

Anycast 6to4 also tends to distribute the IPv6 traffic load better
across all the 6to4 globally gateways, instead of concentrating it at
likely lower number of configured tunnel entry/exit points. Over time,
increased IPv6 traffic will become a disincentive to running a
configured tunnel entry/exit point because people will continue to use
it even if there is a more local configured tunnel or 6to4 relay they
could be using. If people use anycast 6to4, then they inherently get
lower latency as a closer one becomes available, and 6to4 relay
operators will see lower traffic load without intervention as more 6to4
relays are deployed.

> Sure, if you have enough control

---

From: Gert Doering <[email-masked]>
Date: Thu, 16 Jun 2011 08:51:26 +0200

Hi,

On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote:
> I have a vested interest in anycast 6to4 continuing to exist, 

This actually brings up a good argument:

  are you going to pay for us to run our 6to4 relay?

not that the cost of it is high, but there is cost to it - to make sure
it keeps working, to monitor the system for overload, etc.

Our customers don't really need it (because we have native IPv6), we're
offering this for free to benefit users on the other side that do not
have native IPv6, but insist on not using IPv4.

And this also points out why anycasted 6to4 is necessarily(!) less 
reliable than those other Internet technologies that you have mentioned -
because those that run the relays usually have no financial interest in
doing so.  So if it breaks, it will take longer to notice and even longer
to fix than for something that directly affects paying customers.

Gert Doering
        -- NetMaster
-- 
did you enable 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: Mark Smith <[email-masked]>
Date: Thu, 16 Jun 2011 17:05:45 +0930

Hi Gert,

On Thu, 16 Jun 2011 08:51:26 +0200

> it keeps working, to monitor the system for overload, etc.

It was a conscious decision of yours to announce it globally, so you've
made a conscious decision to provide it to people for free and to take
on the operational responsibilities of doing so. If you become unhappy
with accepting those costs without corresponding compensation, withdraw
the 6to4 anycast IPv4 address from the global route table, and people
like me would move onto another 6to4 relay automatically.

I certainly don't take for granted people's generosity in providing them
to global users, however I think that if you choose to do something
charitable, you have then created an obligation on yourself to do it
well and reliably. Most people both understand and deliver on that
obligation.

I've actually become more conscious of this lack of financial incentive
since I've noticed that youtube videos are coming to me over IPv6.
That's what prompted me to ask if my ISP was planning to deploy a 6to4
relay soon as an interim step towards their native service.

> to fix than for something that directly affects paying customers.

Actually, a broken local 6to4 relay is likely to be impacting your
paying customers too as it is their local 6to4 relay.

Your arguments are not specific to 6to4 though - I think they apply to
anybody providing a free configured tunnel service too. In some cases
they apply more so - the administrative effort to support automated
provisioning of configured tunnels is greater than that involved in
setting up an anycast 6to4 relay.

Regards,
Mark.