Subject: one data point regarding native IPv6 support

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 14:24:45 -0400

I just called my ISP to ask about availability of IPv6 at my home.

Me:  "I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6."

First person: "Yes, we do support Internet.  We support DSL at 3 megabits and 6 megabits."

Me: "I understand that, but I'm asking about Internet Protocol version 6, IPv6.  The Internet has been using IP version 4 since the early 1980s, but that's running out.  IPv6 is the new version."

First person: "Let me transfer you to support."

Second person: "Hi, this is support.  How may I help you?"

Me: "I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6."

Second person: "IP version what?"

Me: "Internet protocol version 6".

Second person: "I have no idea.  Let me transfer you to someone else."

(places me on hold for 15 minutes)

Second person: "I'm sorry for the wait time.  I've been trying to find the answer to your question, but nobody here seems to know anything about it.  We're trying to get in touch with people who run the network to ask them.   Can I get your number and call you back?"

Granted, this is just one ISP.  The other ISP that offers service in my area put me on hold for an hour and a half *before anyone ever talked to me* when I tried to get a quote from them, so I concluded that they wouldn't be a good choice.  And these guys have been good about support in general.  They seem to know their stuff, which is more than I can say for some ISPs I've dealt with in the past.

I live in a well-settled urban area, three miles from the center of the city (and sadly, four miles from my CO, which means my DSL circuit gets around 380kbits/sec).  It's not a backwater, there's plenty of lit fiber running through town.  But when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon.

Meanwhile, 6to4 continues to work just fine for me.

So please explain again why it isn't premature to discourage a valuable transition mechanism?

Keith

---

From: james woodyatt <[email-masked]>
Date: Thu, 09 Jun 2011 11:56:00 -0700

On Jun 9, 2011, at 11:24 AM, Keith Moore wrote:
> 
> [...] But when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon.

I have another anecdote to relate.

When I contacted the support staff at the moderately sized regional ISP I use at home, to ask about whether they might move to providing native IPv6 service instead of their subscribers-only IPv6-in-IPv4 tunnel service, the support person was knowledgeable about IPv6, but unhelpful.

I explained who I am, and what I do at Apple, and tried very hard without disclosing Apple Confidential information to explain that it's not just a hobby for me... I need *native* IPv6 into my home in San Francisco for my day job, and that I want to stay with my current provider rather than move to one of its competitors, which I named, and which I know to be rolling out native IPv6 service in my area in the immediate future.  I hoped that might jog something loose.  I'm quite willing and able to help them conduct a native IPv6 trial.

The support person said, "Let me pass along your information to our chief of network operations."

A couple days later, I heard back from the support person.  "We have no plans to offer native IPv6."

Meanwhile, 6to4 works fine on their network so long as remote IPv6 destinations have a working return path route to 2002::/16, i.e. they are complying with I-D.ietf-v6ops-6to4-advisory now.

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

---

From: [email-masked]
Date: Thu, 09 Jun 2011 15:13:00 -0700 (PDT)

You folks have had it easy in your interactions with ISPs. When I tried not too
long ago with various ISPs in my area, I was unable to reach anyone at either
of the big ISPs who knew what "IPv6" even meant. Both promised callbacks,
neither did.

The more interesting response was from a small ISP. They knew exactly what I
was talking about, and told me (a) The IPv4 address shortage is nothing but a
"scare tactic", (b) They currently have no plans to offer IPv6, and (c) If they
ever did offer it "would only be with T1/T3 services, Colocation, and Managed
Servers and not DSL".

Those are verbatim quotes from their response.

And here's another data point, this time in the SOHO router space. My new
router is advertised as being "IPv6 ready", but the firmware it came with has
no IPv6 support whatsoever. When I contacted the vendor about this, I was
informed that I could get a special firmware build that supports IPv6, but it
would be an "as-is" thing based on an earlier release so there may be some loss
of functionality in other areas.

I then asked why they don't have support in their current product, I was told
it's because they are worried about their support staff being inundated with
questions and problems. Given the dearth of IPv6 support from other vendors in
this product area, I can't say I blame them.

Anyone who doesn't believe we have a major marketing problem here isn't paying
attention.

				Ned

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jun 2011 10:57:58 +1000

And from Optus a similar response to a recent request.

Subject IPv6 support
 
Discussion Thread Response Via Email (Russell)
07/02/2011 02.04 PM
Dear Mark, 
Thank you for your email.

IPv6 deployment within Optus has not been broadly discussed.

At this point in time Optus has no immediate plans for implementation. 

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

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 Jun 2011 10:47:28 +0900

james woodyatt wrote:

> I need *native* IPv6 into my home in San Francisco for my day job,

Really?

I wonder why some people are arguing against to kill 6to4 along
with IPv6.

						Masataka Ohta

---

From: "Michel Py" <[email-masked]>
Date: Thu, 9 Jun 2011 20:38:40 -0700

> Keith Moore wrote:
> ... when the support people for a fairly well-established telco
> haven't even heard of IPv6, it's hard to believe that it's going
> to be available anytime soon.

> [multiple people essentially reporting the same]
> At this point in time $ISP has no immediate plans for implementation.

I would say it's about time reality finally settles in.

> Keith Moore wrote:
> So please explain again why it isn't premature to
> discourage a valuable transition mechanism?

On that one I agree with Keith; where's the rush? Although imperfect,
6to4 was an obvious path and its demise would be the failure of the
IETF, following a long list of things that have been killed prematurely.

> Ned wrote:
> Anyone who doesn't believe we have a major marketing
> problem here isn't paying attention.

Hmm that is a point of view. You think you have a solution (IPv6) to
what you perceive to be a problem (shortage of IPv4 addresses).

However, some ISPs (and some other companies) do not consider it a
problem, but a blessing. What the IPv4 shortage does is that it prevents
new large players to enter the field, while allowing existing players to
continue to do business as usual.

As the shortage as been predicted for a decade, some (not all) have
stockpiled addresses and are now reaping the benefits. In business, this
situation is worth solid gold: it's called a monopoly. I'm fat and
happy, and I want it to continue. In this case, it's even better:
companies who benefit from it can argue that they are not the ones who
created the monopoly, it was a built-in limitation of the system as
created.

Some may not like the parallel, but we have failed the IPv6 migration
the same way we have failed the war on drugs. A while ago, there was
this thing called the Tier-1 cartel. As originally designed, a very
elusive club, with almost no way in and absolutely no tears when a
member gets de-peered.

Some have said that the cartel has failed as a system (due to a large
number of multilateral peering agreements and other factors). But now
what we have is a much larger number of largely unorganized but sharing
the same goals entities: those who already have IPv4 addresses. It's
even worse.

When a resource becomes scare or limited, the big picture is not how
much of it is available, or how much it costs. The big picture is how
much of the market one does control. Now we are in the situation where
everyone and their sister own a piece of the pie, and as long as the
price of the pie keeps going up, they're going to cling to it.

On top of the marketing problem you mentioned, you have a bigger one:
there are many, many organizations out there that, even if you paid them
to deploy IPv6, would not. Because IPv6 is a territorial threat to them.

While the new or wannabe players would like the extra address space, the
sad truth is that the already establish players don't like newly open
spaces and prefer the territory control that comes with owning a piece
of a limited land space.

Michel.

---

From: Hector Santos <[email-masked]>
Date: Fri, 10 Jun 2011 01:35:00 -0400

Unless you are elevated to higher level networking people who are 
normally not part of the support process, what 1st/2nd support feeds 
end-users should be taken very lightly.

This is all very simple - economics.  Its not just about end-users, 
but major operations who are IPv4 dependent and as scary it may sound, 
its going probably going to take some major conjones, i.e. arm 
twisting and an act by congress similar to HDTV to force "everyone" to 
switch by so and so date, which is the only way the IPS (Telecos) will 
break business contracts with their business tiers.  Its more 
complicated than people having legacy TVs and wires to it.  We are 
talking major operations for millions of companies, small to large, 
who simply can't "afford" to close the door on IPv4.

I personally understand the draft's attempt to begin "closing" the 
mentality of sticking with IPv4.  As long as there a fallback, the 
urgency to move towards IPv6 is minimized.   At some point, some hard 
decisions will need to be made. Which takes be back to the HDTV 
analogy - only a government mandate made that happen.   But its not 
the same because its not just a relative few networks or broadband 
providers, but there are many software vendors, free, commercial or 
otherwise that need to change their software across the board; SMTP, 
FTP, NNTP, IMAP, POP3 etc.

The bottom line: unless I am force to support IPv6, stack or no stack, 
the investment required isn't going to happen soon.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Keith Moore wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
> 
>

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 10 Jun 2011 08:15:15 +0200

On Fri, Jun 10, 2011 at 7:35 AM, Hector Santos <[email-masked]> wrote:
<snip>
> The bottom line: unless I am force to support IPv6, stack or no stack, the
> investment required isn't going to happen soon.

You got an options now, how, when and where you want to go with IPv6,
wait a few years until all you communicate with in Asia demand IPv6
connectivity, it's the only way to reach them.

and it isn't that hard, just make sure all equipment you buy/invest
into now can or have a plan to support IPv6, if you start with it now,
or started with it ~2-3 years ago you are pretty much safe.
(not all edge equipment are ready at that time but that's another story really)

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Stefan Winter <[email-masked]>
Date: Fri, 10 Jun 2011 08:32:51 +0200

Hi,

> I would say it's about time reality finally settles in.

My reality is that I switched to an ISP who openly announced native IPv6
support in their offering in 2007. Up and running since then, and when I
had trouble setting up the IPCP+IP6CP in the same PPP channel in IOS, I
wrote them an email on a Saturday, and got a config snippet back an hour
later, as part of their standard customer service. That ISP operates
nation-wide and uses IPv6 as a marketing instrument to get techies to
subscribe. For a price of converted 15 USD per month. That's in Germany
though. Apparently, realities differ depending on where you are.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 10 Jun 2011 08:48:57 +0100

The situation in the UK appears similar to the US, with the exception of some really tech-friendly, passionate and clueful ISPs: either flat-out denial that IPv6 is important, in the smaller and well-off case, or else complete cluelessness, in the larger case.  For larger ISPs, especially the resident cable pigopolist, you have to go to their user support forums to read the staff opinion, i.e., IPv6 is alarmist tripe and it'll wait, no plans to support, etc.  My personal opinion is that they are simply afraid; they have too much invested in a young market, and now they're overpowered by the changes required, but without progress made or anticipated, it's a vicious circle, with investors in the lead.

Cheers,
Sabahattin

---

From: otunte otueneh <[email-masked]>
Date: Fri, 10 Jun 2011 08:51:08 +0100

Hello all,

I visited *http://www.worldipv6day.org/* which is an Internet Society
website and clicked on *test* which took me to http://test-ipv6.com/# to do
a test online for IPv6.

When *http://test-ipv6.com/#*  opened for me to run a test, part of the
results says:
"You appear to be able to browse the IPv4 Internet only. You will not be
able to reach IPv6-only sites."

Please can some one visit http://test-ipv6.com/# and give me more
explanation on the displayed result?

Kind regards,

Otunte Otueneh
ISOC Nigeria Chapter

---

From: Stefan Winter <[email-masked]>
Date: Fri, 10 Jun 2011 11:09:15 +0200

Hello,

> "You appear to be able to browse the IPv4 Internet only. You will not
> be able to reach IPv6-only sites."
>

That message is quite clear, isn't it? You use an Internet Service
Provider which only supplies you with IPv4 connectivity. If you want to
visit a website which only supports IPv6, it will not work.

The test website can be reached on both IPv4 and IPv6. So it can tell
you: you came here via IPv4, and didn't manage to get here via IPv6. So
there is no working IPv6 for you.

Stefan

>
> Kind regards,
>
> Otunte Otueneh
> ISOC Nigeria Chapter
>
>
> On Fri, Jun 10, 2011 at 7:32 AM, Stefan Winter
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

Tel: +352 424409 1
Fax: +352 422473

---

From: otunte otueneh <[email-masked]>
Date: Fri, 10 Jun 2011 10:55:37 +0100

Dear Stefan,
Thank you for the reply.
I think there should be a platform where IPv4 users and IPv6 users can
interface. If this link is missing then there will be problem.

Otueneh

---

From: TJ <[email-masked]>
Date: Fri, 10 Jun 2011 07:36:37 -0400

> interface. If this link is missing then there will be problem.
That kind of thing can be done - Google NAT64/DNS64 or how proxies work.,
 However, this is *not* the ideal state.  Ideally, you would be provisioned
with both IPv4 and IPv6 ("dual stack")  and thus be able to connect to
content reachable over either.

Call your ISP, ask them when they will be entering the right decade (read:
How soon will they offer IPv6).  This may not be a "critical" feature right
now, but if your ISP hasn't even started they probably won't be ready when
you start to need it.  Or they will break things trying to get there
rapidly, that is fun.

/TJ

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 10 Jun 2011 09:04:06 -0400

Sadly this is more common than it should be these days. I've been begging Fairpoint for IPv6 for the past 3 years, from which people in NH/VT/ME now have been subjected to as Verizon sold off FIOS/dsl in those areas to them a while back. I have "business" service from them with static IPs and the whole 9 yards, and they still insist that I am mad when I call to ask for IPv6 siting the same reasons you are being given.

	--Tom

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 10 Jun 2011 15:10:50 +0200

I have a "Business service" from my ISP too. They told me that somewhere in 2012 they would look into IPv6.
So I have threatened to move to another provider. But we do not have much choice in NL at the moment
I believe. Although I have to re-checked recently.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jun 2011 01:34:51 +1200

Michel,

On 2011-06-10 15:38, Michel Py wrote:
...
> IETF, following a long list of things that have been killed prematurely.

Who's talking about its demise? Really all that the 6to4-historic draft
does is say that it should no longer be considered as a default solution
to the problem of ISPs that don't support IPv6. Changing the formal
status of the RFCs is a symbolic step, but the real point is that it's
now time for the reluctant ISPs to get their heads out of the sand.

You're correct that some ISPs will try to get monopoly rents out of
the IPv4 shortage, and use CGN to capture customers in walled gardens,
but fortunately capitalism provides a solution to such misbehaviour:
other ISPs can deploy IPv6 as a competitive advantage.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2011 09:49:26 -0400

On Jun 10, 2011, at 9:34 AM, Brian E Carpenter wrote:

> to the problem of ISPs that don't support IPv6.

Actually it says more than that.  For instance, it specifically says that new implementations shouldn't support 6to4.

That, and if passed, this would be the first time I can recall that IETF has taken the "symbolic" step of declaring something Historic that people actually use, and for which there is not a readily available replacement that works better.  Historic has historically been used for things that aren't used anymore, or for things for which there's an obvious and readily available replacement.

That, and the 'no compromise' position of this draft's proponents - their unwillingness to try to build a strong consensus position - makes this look suspiciously like a denial-of-service attack.

> Changing the formal status of the RFCs is a symbolic step, but the real point is that it's now time for the reluctant ISPs to get their heads out of the sand.

It's a step in the wrong direction.  Not only does this "symbolic step" bring with it the potential for harm to current users of 6to4, it actually takes away some of the incentive for ISPs to get their heads out of the sand.  Meanwhile, it discourages the development of IPv6-based applications.

> other ISPs can deploy IPv6 as a competitive advantage.

Last mile (kilometer?) problems limit the ability of other ISPs to compete with established players, especially for consumer services.  But IETF can't do much about that.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jun 2011 10:43:30 -0400

--On Saturday, June 11, 2011 01:34 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> You're correct that some ISPs will try to get monopoly rents
> out of the IPv4 shortage, and use CGN to capture customers in
> walled gardens, but fortunately capitalism provides a solution
> to such misbehaviour: other ISPs can deploy IPv6 as a
> competitive advantage.

Sure.  Assuming that there is realistic competition, or a
realistic possibility of competition, in the relevant market.
Keith, Ned, and others have described a situation in which there
are few realistic choices of ISPs and the attitude of all of
them toward getting IPv6 deployed to endpoints runs from bad to
worse.  In that marketplace situation, capitalism is as likely
to predict a "no one goes first" outcome as it is to predict
that one of the ISPs will suddenly decide that deploying IPv6
will give them a competitive advantage... and give that
competitive advantage even after the additional training costs
for their own staffs, support costs for customers, equipment and
software, etc., are considered.

That situation really isn't much different than it was several
years ago.  If I'm in an area where competition is permitted,
I'm a large enough customer to be talking about dedicated fiber
to my premises in the multiple DS3 range or above, and I call up
my ISP (or my router vendors, or...) and say "sell me IPv6 or
I'm going to find it somewhere else", the threat is credible and
I'll probably set either them or their competitors scrambling.
If I'm in a situation that is closer to a SOHO one, in much of
the world there is no effective competition, I'm not seen as
having much leverage, and the scenario for my getting native
IPv6 is a lot more dependent on internal strategic decisions (or
wishful thinking) in those ISPs and not on competition issues
except very indirectly or at all.

   john

     john

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 10 Jun 2011 09:03:50 -0700

Keith & John are hitting the crux of the issue here. The entire point of the
automated tunneling technologies was to enable application development and
deployment in the face of lethargic ISPs, that will refuse to move until
they see a set of credible applications running in the wild. None of them
will take the risk that the leap-of-faith requires without serious
competitive threat, and that simply doesn't exist. 

I am in the 'enviable' position where both ISP options available to me are
clueful and actually actively working on IPv6 deployments. That said, I am
still stuck with tunneling because the one option that could get me service
today can't keep their basic access network running (the other
work-from-home neighbors around me struggle with it regularly for IPv4), and
the one I use for service has decided to start their deployment of IPv6 in
larger markets (imagine that). 6to4 continues to serve me well for all but
the bone-headed places that have decided to boycott that prefix.

There is no real problem with 6to4, despite the BS being propagated about
failure rates. The fundamental problem is that those complaining have their
heads firmly stuck in IPv4-think, and are refusing to add a second 6to4
prefix to their service. If they would simply install their own 6to4 router
and be the tunnel endpoint, there would be no 3rd party in the path for
either direction. The technology is simply creating an opportunity. Those
complaining about it are refusing to take advantage of it because that would
be a different operational practice than they do for IPv4.

The herd mentality of kill-what-we-don't-like is not helping with
deployment. In fact the ability to document which ISPs have customers that
are trying to use IPv6 despite the edge lethargy is a very useful thing to
drive deployment through blame-&-shame. Put the 6to4-to-historic effort on
the shelf for at least 5 years. Then it will be time to talk.

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John C Klensin
> Sent: Friday, June 10, 2011 7:44 AM
> To: Brian E Carpenter
> Cc: IETF Discussion
> Subject: Re: one data point regarding native IPv6 support
> 
> 
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 10 Jun 2011 12:10:21 -0400

OTOH, my cable ISP provider has an "Expected IPv6 Transition Phases" chart, in which Phase 3 says, "Customer Premesis Equipment (CPE) IP addressing:  IPv6 only".  And they've started trials of IPv6 already.

Dale

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 10 Jun 2011 12:15:55 -0400

At the risk of piling on, I can't resist the opportunity to try to one-up Ned's story.

While in the UK this year, I had the misfortune to need to call BT for support on my broken home Internet connection.  In the middle of the usual mind-numbing "we will force you to walk through every idiotic step that you already know is irrelevant after thirty years in the business,"  the phone support guy told me to "Click on the pulldown for 'Configure one-pee-vee-six' and set it to Off."  Not only was this totally irrelevant, and not only did he routinely make me turn off the very protocol we want to enable, but he called that protocol "one pee v6" instead of "eye pee v6."   And when I was stupid enough to correct him, he wouldn't go any further until I admitted that he knew best, and that I should call it "one pee v6" rather than "eye pee v6."    Needless to say, I didn't bother asking about BT's plans to support IPv6 -- oops, I mean 1Pv6.

No need to ask.  If BT can't even spell IP, we are a11 d00med.  -- Nathaniel

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jun 2011 05:04:57 +1200

On 2011-06-11 04:03, Tony Hain wrote:
...
> failure rates. 

That's no BS, unfortunately. Have you studied the careful reports at
https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really
and http://www.potaroo.net/ispcol/2010-12/6to4fail.html ?

The operational fixes for 6to4 are also essential, and documented
in my draft, but how do you propose we get them implemented
by the 1PV6 deniers among ISPs?

   Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jun 2011 13:05:12 -0400

--On Friday, June 10, 2011 12:10 -0400 "Worley, Dale R (Dale)"
<[email-masked]> wrote:

> OTOH, my cable ISP provider has an "Expected IPv6 Transition
> Phases" chart, in which Phase 3 says, "Customer Premesis
> Equipment (CPE) IP addressing:  IPv6 only".  And they've
> started trials of IPv6 already.

Dale,

I think that is part of the (rather specific) point I was trying
to make.  When one gets to the SOHO and small business markets,
there are ISPs who have gotten with the program and are making
commitments or actually deploying.  Some have not, don't intend
to, and don't have a clue.   A few are issuing press releases
about their commitment to IPv6, but have no actual deployment
plan to end users.   In none of the cases that are moving
forward have I seen anything that can be best explained by a
desire for competitive advantage.

For several years, I went through the exercise that, every time
one particular ISP issued a press release or make a presentation
about their IPv6 efforts, I'd call their local office and say
"ok, I'd like IPv6 here.  What is the schedule for your turning
service on here and how do I get an order in?"   Despite all the
hype, the answers I got were a lot more similar to what Keith,
Ned, and Nathaniel have reported than they were to handing out
charts and making commitments.

YMMD... and obviously does.

I think the question for the IETF is whether it is desirable to
move 6to4 to historic at a time when it is the only path to IPv6
for some users in spite of whatever recognition there is that it
is no longer a mechanism we want to encourage people to design
into new installations or systems.  

Personally, I'd rather see us publish an A/S that just says
"generally Not Recommended any more because..." than have the
debate about the surface and deep semantics of "Historic".  Most
of the text for that document could be appropriated from the
current V6OPS WG draft.  Much of the rest could be drawn from
Tony Hain's recent note in this thread.  

But, to the extent to which the motivation for moving 6to4 to
Historic is what Tony describes as "kill-what-we-don't-like",
let me suggest that we need to realize that a good fraction of
the reason we have as little deployed and
used-routinely-in-production IPv6 as we do is not technical
issues but that the IETF and some related communities have
consistently gotten deployment scenarios, schedules, and plans
wrong... and then made promises based on those wrong guesses.  I
think a little modest realism about our predictive abilities and
a willingness to understand that different situations call for
different scenarios would help a lot.  It would help even more
if our documents ran a little more in the direction of
reflective and emotionally neutral scenario analysis and a
little less in the direction of "praise what you like and damn
what you don't".

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jun 2011 05:28:09 +1200

John,

On 2011-06-11 05:05, John C Klensin wrote:

...
> Historic is what Tony describes as "kill-what-we-don't-like",

Unfortunately, as I know from the enormous amount of technical
feedback I got from living, breathing operators while drafting
draft-ietf-v6ops-advisory, the motivation is "kill something
that is causing real operational problems and failure modes."
I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if
there wasn't a very sound operational argument for it.

I think nobody wants to kill the successful use of 6to4, but
we need to stop the operational problems getting worse. It
appears that the default help desk advice to disable 1PV6 is
generally an echo of problems caused by on-by-default 6to4.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Jun 2011 13:39:58 -0400

>>>>> "Tony" == Tony Hain <[email-masked]> writes:
    Tony> There is no real problem with 6to4, despite the BS being
    Tony> propagated about failure rates. The fundamental problem is
    Tony> that those complaining have their heads firmly stuck in
    Tony> IPv4-think, and are refusing to add a second 6to4 prefix to
    Tony> their service. If they would simply install their own 6to4
    Tony> router and be the tunnel endpoint, there would be no 3rd party
    Tony> in the path for either direction. The technology is simply
    Tony> creating an opportunity. Those complaining about it are
    Tony> refusing to take advantage of it because that would be a
    Tony> different operational practice than they do for IPv4.

+1
I have native IPv6 at home.
I have multiple other sites that I work with that can only get tunnels.
6to4 (on BSD. Linux has a design bug) lets me do this to shortcut things:
   route add -net -inet6 2001:4830:116e:: -prefixlen 48    2002:84d5:ee07::1
 
IPv4 is my NBMA LAN :-)

    Tony> The herd mentality of kill-what-we-don't-like is not helping
    Tony> with deployment. In fact the ability to document which ISPs
    Tony> have customers that are trying to use IPv6 despite the edge
    Tony> lethargy is a very useful thing to drive deployment through
    Tony> blame-&-shame. Put the 6to4-to-historic effort on the shelf
    Tony> for at least 5 years. Then it will be time to talk.

The funny part is that removing 6to4 won't reduce any code, as the 6rd
code is often identical...

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: james woodyatt <[email-masked]>
Date: Fri, 10 Jun 2011 11:25:41 -0700

>> I need *native* IPv6 into my home in San Francisco for my day job,

Very very very few people have day jobs that require native IPv6 service to their home network today.

I'm an exception because I have a requirement that IPv6 and IPv4 provide more or less *equivalent* performance characteristics.  The extra 20 milliseconds of queuing delay caused by the 6over4 tunnel endpoint should be acceptable to almost everyone else, but it's a deal-breaker for me.  For reasons I'm not going to discuss here, I need IPv6 to be at least as good if not better than IPv4-- today, not three years from now--- and I'm forced to leave my ISP over it.

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jun 2011 17:05:55 -0400

> generally an echo of problems caused by on-by-default 6to4.

Brian,

This is not in my primary area of expertise and I am painfully
aware that it has been almost a decade since I have been able to
look in on these things from the viewpoint of an ISP with
default-free backbone arrangements, small end-site customers,
and almost everything in between.

>From the above and other comments you have made, I don't think
we disagree very much on the substance here.  I'm certainly not
about to try to make the case that 6to4 is a wonderful option to
be widely preferred.  As a variation on your comment above, I
don't want to see the IETF denounce or kill the successful use
of 6to4 and don't believe anyone else does either (or at least
should).

Where we disagree is about a procedural matter and the stance
the IETF takes formally and, perhaps still, about where the
motivations to deploy IPv6 "for real" comes from.

Let me see if I can describe my position and recommendation in
another way:

Even among those of us who believe that IPv6 conversion has
ceased being optional and has to be considered the only option
at this stage, we really have few clues about what is going to
cause a given ISP, or a given end-node customer, to switch over.
Most of our arguments are faulty, at least for some particular
set of cases.  Your capitalism/competition one is an example --
there are places where it will work and places where it won't.
The applications support and availability of IPv6-capable (and
IPv6-native) servers is another -- sometimes ISPs are waiting
for customer demand and/or enough deployment on customer sites
before they think about making the switch and the customers are
waiting for more evidence that the applications issues are
sorted out and will work reliably.  We talk about the advantages
to the folks who switch early, but we are aware that some folks
don't want to be the first to switch.   And so on, for a rather
long list.

Part of this adds up to a conclusion that we are lots better at
protocol design than we are at predicting the future or gaming
out the decision processes under various circumstances.  We had
better be -- our track record for those predictions is bad
enough that, if our protocol design and engineering were worse,
we should all find other occupations.

At the same time, my very limited and quite anecdotal experience
suggests that the decision in several dual-stack setups to
automatically prefer IPv6 when it is available (following IETF
advice if I recall) combines with sometimes-sketchy IPv6
connections and routing to cause connectivity problems that can
overwhelm the sorts of folks who staff first-level help desks.
6to4 is certainly part of that problem --and a little worse if
it is set up without user or ISP knowledge-- but the implicit
argument in both ..-6to4-advice and 6to4-historic that 6to4 is
the dominant cause of those problems isn't convincing.  Maybe it
is the case, maybe it is the dominant case (and, again, I don't
have enough firsthand experience in recent years to claim to
know) but certainly it is not the only one.  

I accept the claim that it can easily be misconfigured, but that
may not be sufficient to demonize it.

I don't think the technical content of either
draft-ietf-v6ops-6to4-to-historic or
draft-ietf-v6ops-6to4-advisory is especially bad.   Indeed, the
analysis in ...-6to4-advisory seems quite good to me -- the sort
of thing the IETF should, IMO, be doing a lot more often.  I'm
just suggesting that we should not write off _any_ option that
has proven useful to folks in preparing to transition, planning
for transitions, or actually transitioning.    To that end, the
abstract of ...6to4-advisory is just the right think to do.
Advising that 6to4 is a really lousy default, that
implementations should allow it to be turned on only after
appropriate warnings and only if the advice in Section 4 of
..-6to4-advice is followed _really_ carefully may be entirely
appropriate.  Put differently, your analysis appears good enough
that I can see no argument against branding 6to4 as "really
dangerous -- use only if actually understood and needed, then
with great caution, and then only if there is some reason why
6rd is inappropriate or unavailable".

But "Historic" is a really blunt instrument, especially since we
use it primarily for protocols that are no longer in use and/or
that have been demonstrated to be of no redeeming value.  This
situation is, IMO, an almost perfect example of why 2026 permits
us to identify a protocol specification as "NOT RECOMMENDED"
(yes, I think 2119 is defective in listing the conformance
language (MUST/ SHOULD/ MAY/...) but not the recommendation
terminology, but that is another topic).

So my personal preference, in a more perfect world, would be to
fold these two drafts together, drop "Historic" and any even
slightly hyperbolic language, issue the combination as a
standards-track A/S that updates 3056 and 3068 and makes a clear
and carefully explained "NOT RECOMMENDED" statement.   If, in
conjunction with that move, you or others see value in
downgrading 3056 and 3068 to Experimental and including comments
to the effect that they are normally useful only for
exploratory/experimental use, I wouldn't have any problem with
that at all.

I actually don't feel very strongly about the above.  I probably
would not have said anything in this thread if you hadn't raised
the capitalism/competition argument.  But, if there is a
situation where 6to4 really is appropriate and the IETF makes
what appears to be a strong statement deprecating it, we either
convince someone to further defer thinking through and migrating
to IPv6 or we help contribute to the impression that the IETF is
out of touch with real world realities.  I don't consider either
of those outcomes desirable and presume you don't either.   On
the other hand, my impression from conversations with operations
is that it certainly would not be either the first or the most
extreme case in which we've shown the IETF to be out of touch
and at least some users and implementers who find value in 6to4
are likely to continue doing whatever they think it is
appropriate to do regardless of what labels the IETF decided to
put on the specs.

best,
   john

p.s. Editorial nit: I'd love to know what a "domestic customer"
in Sections 2 and 4.2.4 of ...-6to4-advice is.  The term is as
likely to be construed as "within a particular country" (New
Zealand?) as "residential" (which I'm guessing is what you
mean).  As far as I can tell from skimming the document
"residential, small office, or home office (SOHO)" would be more
appropriate and consistent with terminology in common use.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 10 Jun 2011 22:11:22 +0100

On Fri Jun 10 17:15:55 2011, Nathaniel Borenstein wrote:
> While in the UK this year, I had the misfortune to need to call BT  
> for support on my broken home Internet connection.  In the middle  
> of the usual mind-numbing "we will force you to walk through every  
> idiotic step that you already know is irrelevant after thirty years  
> in the business,"  the phone support guy told me to "Click on the  
> pulldown for 'Configure one-pee-vee-six' and set it to Off."  Not  
> only was this totally irrelevant, and not only did he routinely  
> make me turn off the very protocol we want to enable, but he called  
> that protocol "one pee v6" instead of "eye pee v6."   And when I  
> was stupid enough to correct him, he wouldn't go any further until  
> I admitted that he knew best, and that I should call it "one pee  
> v6" rather than "eye pee v6."    Needless to say, I didn't bother  
> asking about BT's plans to support IPv6 -- oops, I mean 1Pv6.
> 
Particularly poor as BT are actually quite clued up on IPv6:

http://www.ipv6.bt.com/

(And I don't work for BT, have never worked for BT, have been in  
competition with BT, and I don't use their service)

I would *never* judge an ISP by the clueless nature of their scripted  
first-line suppor, at least not beyond their existence. (The ISP I  
use does not have clueless script monkeys, but smart and helpful  
people who craft their response to fit your ability, not theirs).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jun 2011 09:32:04 +1200

John,

On one specific point:

>> fold these two drafts together, 

I specifically pushed for the -advisory draft to be kept separate
and Informational in order to get it out ASAP (in my dreams, before
IPv6 Day, but that didn't prove possible). I still think that is the
correct approach - decouple the practical advice from the admittedly
political debate.

I'm not dismissing the rest of your points - clearly there are
varied opinions and "Historic" is, as you say, a blunt instrument.

Regards
   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Jun 2011 06:43:44 +0900

james woodyatt wrote:

> I'm an exception because I have a requirement that IPv6 and IPv4
> provide more or less *equivalent* performance characteristics.

Use 4 over 4 in addition to 6 over 4.

I think you are not saying mobile IPv4 with 4 over 4 is not
acceptable IPv4.

PS

If you mind performance, you should better learn how to type
e-mails not to use lines longer than 72 characters.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 10 Jun 2011 15:10:48 -0700

> there wasn't a very sound operational argument for it.

I'm a content provider. I'm am prepared to turn on more ipv6 services that are visible to consumers. 6to4 is a visible and measurable source of collateral damage. If consenting adults want to use it that's fine, I would greatly appreciate it if the facility were: 

* off by default

* considered harmful when not deliberately used.

The gradually declining determinism that we fully expect to experience from ipv4 access networks and mobile broadband in particular we expect to be hard enough to manage without those users riding in over 6to4.

I think the two documents at present encourage: 

* vendors an implementors to consider not using or a least disabling by default 6to4 auto-tunneling in existing and future implementations.

* the deployment of additional 6to4 anycast relays which if done would help address issue that existing users of 6to4 who will be with us for a while as well as those who would prefer to use it would benefit from.

---

From: james woodyatt <[email-masked]>
Date: Fri, 10 Jun 2011 15:33:38 -0700

> * the deployment of additional 6to4 anycast relays which if done would help address issue that existing users of 6to4 who will be with us for a while as well as those who would prefer to use it wou…

I would say that I-D.ietf-v6ops-6to4-advisory suffices to encourage both those things with more precision and clarity than I-D.ietf-v6ops-6to4-to-historic does.

In fact, I-D.ietf-v6ops-6to4-to-historic makes a more aggressive point on the first item, and sends, at best, a very mixed message about the second.

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jun 2011 18:42:48 -0400

--On Friday, June 10, 2011 15:10 -0700 Joel Jaeggli
<[email-masked]> wrote:

> I'm a content provider. I'm am prepared to turn on more ipv6
> services that are visible to consumers. 6to4 is a visible and
> measurable source of collateral damage. If consenting adults
> want to use it that's fine, I would greatly appreciate it if
> the facility were: 
> 
> * off by default
> 

ok

> The gradually declining determinism that we fully expect to
> experience from ipv4 access networks and mobile broadband in
> particular we expect to be hard enough to manage without those
> users riding in over 6to4.
> 
> * vendors an implementors to consider not using or a least
> disabling by default 6to4 auto-tunneling in existing and
> future implementations.
> 
> * the deployment of additional 6to4 anycast relays which if
> done would help address issue that existing users of 6to4 who
> will be with us for a while as well as those who would prefer
> to use it would benefit from. 

Actually not.  That is certainly what the "advice" document
encourages.  But "Historic" is a sufficiently blunt instrument
that moving the base 6to4 specs to Historic could be interpreted
by either vendors or operators as "if you had a transition
strategy based on using 6to4, or are using it today, 6to4 is
sufficiently bad news that it is reasonable to just disable it,
and IPv6 along with it, instead until some unspecified magical
event occurs".  I know that isn't what you intend or how you
would read it, but it is a reading of "Historic" that is
perfectly consistent with things we have used Historic for in
the past.

   john

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Jun 2011 09:40:44 +1000

As for Geoff figures.  No one as far as I know has done measurements
of 6to4 failure of explictly enabled 6to4.  Yes Geoff figures seem
scary but if vendors were to make 6to4 users do something to turn
it on I truly think the failure rate would be in the noise.

Lots of the perceived issues with broken 6to4 go away with reasonable
application support for multi-homed servers.  Just yesterday I had
a dual homed site that was reachable over IPv4 but not over IPv6,
routing SNAFU in Canada.  Safari made me wait 30 odd seconds to
connect.  With Chrome I couldn't tell the site was not reachable
over IPv6.  This wasn't a 6to4 issue as neither end was running
6to4.

However it is this delay, which is completely avoidable on the
applications part, that is partially driving this push to move 6to4
to historic.

Also the kill 6to4 crowd push back on anything that would make 6to4
work better for those that can't get native IPv6, whether there is
a technical problem in the proposal or not.  If there is not a
technical problem then shut up.  You may not want to work on it but
others might.

Making 6to4 historic will also stop us working on things that make
6to4 behave better.  Whenever something is proposed in the future
you will hear the kill 6to4 crowd say "6to4 is historic, we can't
work on that."

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Jun 2011 09:51:22 +1000

In message <[email-masked]>, Joel Jaeggli write
s:
> I'm a content provider. I'm am prepared to turn on more ipv6 services that ar
> e visible to consumers. 6to4 is a visible and measurable source of collateral
>  damage. If consenting adults want to use it that's fine, I would greatly app
> reciate it if the facility were: 
> 
> * off by default
> 

You don't need to make the protocol historic to achieve this.
 
> The gradually declining determinism that we fully expect to experience from i
> pv4 access networks and mobile broadband in particular we expect to be hard e
> nough to manage without those users riding in over 6to4.
> 

There are at least 4 documents that address aspects of this issue.

You need to add "happy eyeballs" to the mix (which works, see Google
Chrome) and my 6to4 DHCP option draft.

> * vendors an implementors to consider not using or a least disabling by defau
> lt 6to4 auto-tunneling in existing and future implementations.

We don't need vendors to stop implementing (historic).  We just need it
turned off by default (advisary).

> * the deployment of additional 6to4 anycast relays which if done would help a
> ddress issue that existing users of 6to4 who will be with us for a while as w
> ell as those who would prefer to use it would benefit from. 

* the ability to signal that 6to4 will not work with the address you are
  being give.

* the ability to signal that there is a managed 6to4 relay at this address.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Jun 2011 09:44:23 +0900

Mark Andrews wrote:

> application support for multi-homed servers.

True.

A major design flaw of IPv6 is half hearted support for multihoming
with multiple addresses by broken address selection architecture,
which causes a lot of operational problems, which is partly why
IPv6 is unusable.

Disabling 6to4 and/or improving applications may work for some
faulty cases, but it's not enough at all.

							Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Jun 2011 11:06:51 +1000

> faulty cases, but it's not enough at all.

The next step is to make multi-homed clients also work well.

Mark

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2011 03:31:04 -0000

>I would say it's about time reality finally settles in.

The reality is that for now and for the next several years, anyone who
wants to communicate with "the Internet" had better figure out how to
get their packets back and forth to the IPv4 Internet.  This is
totally unfair to new entrants who don't have a source of cheap IPv4
space.  Tough.

I'm all in favor of doing IPv6 experiments and opportunistically using
it when you notice that a remote party supports it, but the urgency of
doing so has been greatly overstated.

R's,
John

---

From: "Michel Py" <[email-masked]>
Date: Fri, 10 Jun 2011 20:40:28 -0700

Brian,

>> Michel Py wrote:
>> On that one I agree with Keith; where's the rush? Although
>> imperfect, 6to4 was an obvious path and its demise would be
>> the failure of the IETF, following a long list of things
>> that have been killed prematurely.

> Brian E Carpenter wrote:
> Who's talking about its demise? Really all that the 6to4
> historic draft does is say that it should no longer be
> considered as a default solution to the problem of ISPs
> that don't support IPv6.

I'm not qualified to debate procedural issues, but I will say that, from
a distance, this does smell like a kill-what-we-don't-like. As you have
undoubtedly felt the irony of me defending Keith on this kind of issue,
I will confess that there is a little part of me that did not mind a bit
seeing him getting a taste of his own food in that matter, but I still
think this is premature.

> but the real point is that it's now time for the
> reluctant ISPs to get their heads out of the sand.

I don't think making 6-to-4 historic will change anything in that
regard, which is why I said above that it did look like a
kill-what-we-don't-like.

> You're correct that some ISPs will try to get monopoly
> rents out of the IPv4 shortage, and use CGN to capture
> customers in walled gardens, but fortunately capitalism
> provides a solution to such misbehaviour: other ISPs can
> deploy IPv6 as a competitive advantage.

It does not matter, as long as the core of the "haves" don't do anything
about it, as they command a big enough market share. Besides, you have
not convinced me and not many ISPs either.

I understand what you are trying to do here; nevertheless, 1Pv6 has not
reached critical mass; although I do understand the "disable 1Pv6" issue
(probably better than most) and I do indeed recognize that some of the
brokenness comes from 6to4, it does not change the fact that deprecating
6to4 will reduce the sub-critical mass before it starts chain reaction,
if it ever does.

Michel.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Jun 2011 19:41:39 +0900

> The next step is to make multi-homed clients also work well.

A problem is that RFC2374 was thrown away and the current address
assignment procedure is broken to promote multihoming with routing,
which means people won't use multihoming with multiple IPv6
addresses.

Thus, you can't expect proper support for hosts with two (IPv4 and
IPv6) addresses.

						Masataka Ohta

---

From: [email-masked]
Date: Sat, 11 Jun 2011 12:26:40 -0700 (PDT)

> people who craft their response to fit your ability, not theirs).

That rather depends on whether or not it's possible to get past the
cluelessness, doesn't it? If it isn't pssible it seems not only reasonable to
judge on this basis, but pretty silly not to.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Sat, 11 Jun 2011 15:36:48 -0400

> judge on this basis, but pretty silly not to.

If we want IPv6 to be available to the average user, I think it's fair to assume that the average user won't get past the cluelessness.

Then again, I fully suspect that the first line sales/support people will be the last to know when an ISP is ready to support IPv6.  They won't know until they're forced to watch a training video that says so.

Keith

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2011 20:54:47 -0000

>If we want IPv6 to be available to the average user, I think it's
>fair to assume that the average user won't get past the cluelessness.

The average user is never going to call up and ask "can I get IPv6 as
part of my bundle along with the Home Shopping Network" so the first
level cluelessness doesn't matter.

It's going to be available to the average user when the average cable
or DSL modem autoconfigures itself to offer IPv6, and SLAAC and DHCPv6
work well enough on average consumer PCs and other wifi devices that
they set themselves up without any manual intervention.  You know,
like they do with IPv4.

I realize all these pieces work in theory, and often in practice if
you know what button to tweak.  But Grandma is unlikely to tweak any
network buttons at all.

R's,
John

---

From: Hamza GHARSALLAH <[email-masked]>
Date: Sat, 11 Jun 2011 21:58:27 +0100

Hi! All!

Why don't we run it the opposite way:
-IPv6 by default, else:
-Legacy: just run IPv4 with some kind of NAT.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Jun 2011 19:33:24 -0400

>>>>> "John" == John Levine <[email-masked]> writes:

    John> The average user is never going to call up and ask "can I get IPv6 as
    John> part of my bundle along with the Home Shopping Network" so the first
    John> level cluelessness doesn't matter.

...

    John> you know what button to tweak.  But Grandma is unlikely to tweak any
    John> network buttons at all.

"I want that Internet that George down the street has, that let's his
daughter get the scoop on what groceries he needs"  

(by talking directly to his fridge)

---

From: "John R. Levine" <[email-masked]>
Date: 11 Jun 2011 21:22:26 -0400

> -Legacy: just run IPv4 with some kind of NAT.

If the answer to that question isn't obvious, I don't think I can help.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Keith Moore <[email-masked]>
Date: Sat, 11 Jun 2011 21:28:59 -0400

> you know what button to tweak.  But Grandma is unlikely to tweak any

agree.  So when we're trying to evaluate whether IPv6 is widely available, it's not sufficient for it to be widely available to clueful users who can badger their way past first tier support.  It has to be available to Grandma.

Keith

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 12 Jun 2011 14:49:25 -0400

Just for the record:

-- I don't believe that my single experience with first line tech support at BT says much about BT's broader role, or its relative sophistication and service quality as an ISP.  For all I know it's the best ISP in the world, and has a lone bozo at tech support to qualify for a "jobs for bozos" tax credit.  I was simply relating an experience that I found rather extreme.

-- I do believe that a world in which any tech support person at any major ISP doesn't know how to spell IP -- whether he's telling you to turn off IPv6 or not -- is a world in which it is very challenging to expect positive outcomes in the major technical transition we are trying to effect.

-- I don't believe that I know what to do about it.  I'm almost sorry I mentioned it -- we still have a long way to go before we need to start worrying about Grandma configuring IPv6 at home.  -- Nathaniel

---

From: "Michel Py" <[email-masked]>
Date: Sun, 12 Jun 2011 12:24:03 -0700

According to this:
http://blogs.cisco.com/sp/france-is-famous-for-fine-wine-cheese-and-now-
ipv6/
and some more recent direct talks in French, about half of worldwide
IPv6 traffic is French.

The bulk of it comes from a single ISP (Free, AS12322) and their IPv6 is
6RD (RFC5569, RFC5969), a variant of 6to4. Given the constant references
in 6RD to 6to4, I will point out that making 6to4 historic somehow
reduces the likeliness of another extremely successful ISP
implementation based on it.

Although Google (in
http://www.pam2010.ethz.ch/papers/full-length/15.pdf) and other
measurements classify AS12322's traffic as native, it is 6RD behind the
scenes.

If the argument is that IPv6 "native" should be the preferred solution
over "tunneled", it does not hold water. If you were to remove 6to4 and
6RD from the picture, that would set us back 10 years ago in terms of
IPv6 adoption.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Sun, 12 Jun 2011 12:33:32 -0700

Oops, copy/paste casualty, sorry. Read below instead.

According to this: http://tinyurl.com/5u3eorn and some
more recent direct talks in French, about half of
worldwide IPv6 traffic is French.

The bulk of it comes from a single ISP (Free, AS12322) and
their IPv6 is 6RD (RFC5569, RFC5969), a variant of 6to4.
Given the constant references in 6RD to 6to4, I will point
out that making 6to4 historic somehow reduces the likeliness
of another extremely successful ISP implementation based on it.

Although Google (in
http://www.pam2010.ethz.ch/papers/full-length/15.pdf) and other
measurements classify AS12322's traffic as native, it is 6RD
behind the scenes.

If the argument is that IPv6 "native" should be the preferred
Solution over "tunneled", it does not hold water. If you were
to remove 6to4 and 6RD from the picture, that would set us back
10 years ago in terms of IPv6 adoption.

Michel.

---

From: Doug Barton <[email-masked]>
Date: Sun, 12 Jun 2011 12:45:15 -0700

> 10 years ago in terms of IPv6 adoption.

Can you explain the exact mechanism by which what you're concerned about 
will occur? I don't see anything in the draft which prevents an ISP from 
deploying 6rd.

Doug (but I might have missed something)

-- 

	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/

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Jun 2011 15:54:18 -0400

On Jun 12, 2011, at 3:33 PM, Michel Py wrote:

> Solution over "tunneled", it does not hold water.

To be fair, I think the argument is more that "ISP managed" IPv6 is preferred over "IPv6 tunneled by end-users through relay routers set up on an ad hoc basis".  And I can't really disagree with that.

I don't think there's any doubt that native > 6rd > 6to4 (where ">" is "a better way to deploy IPv6").  But you have to use whatever you can get.

For ISPs that are still looking at native v6 as a target to be deployed to consumers in a few years or longer, I really wish they'd consider 6rd as an interim step.
And for those rolling out LSN, I really wish they'd at least roll out 6rd along with it.  That way, application developers that currently use PnP or NAT-PMP to get through NATs would have the option of using IPv6, instead of having to support yet another NAT traversal hack in their code (and supporting different NAT hacks for different customers).

Keith

---

From: "Michel Py" <[email-masked]>
Date: Sun, 12 Jun 2011 18:18:22 -0700

>> Michel Py wrote:
>> If you were to remove 6to4 and 6RD from the
>> picture, that would set us back 10 years
>> ago in terms of IPv6 adoption.

> Doug Barton wrote:
> Can you explain the exact mechanism by which what you're
> concerned about will occur? I don't see anything in the
> draft which prevents an ISP from deploying 6rd.

There is not. OTOH, I am not aware of any sizeable deployment of 6RD
outside of AS12322; 6RD may not be for everyone, and what making 6to4
historic may prevent is: someone else using 6to4, finding out that there
are some issues, and coining another highly successful 6to4 variant that
would fit their needs better.

Michel.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 12 Jun 2011 18:58:37 -0700

> would fit their needs better.

The faint promise of yet another transition mechanism is hardly a motivation
to keep 6to4 around.

The data (ripe ...) overwhelming proves default-on 6to4 clients + thinly
deployed relays = unreliable ipv6 and ipv6 deployment obstacle.
Cb

---

From: "Michel Py" <[email-masked]>
Date: Sun, 12 Jun 2011 23:26:40 -0700

> Cameron Byrne wrote:
> The faint promise of yet another transition mechanism is hardly
> a motivation to keep 6to4 around.  The data (ripe ...)
> overwhelming proves default-on 6to4 clients + thinly deployed
> relays = unreliable ipv6 and ipv6 deployment obstacle.  

That's the difference between a fait promise and a proven failure. The promise of "IPv6 native IPv6 is going to be deployed next year" has failed for 10+ years in a row. Nobody believes in it anymore; your choices are to believe in yet another transition mechanism or switch to the post-mortem camp.

Get a life.

Michel.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Jun 2011 11:07:25 +0300

I have a general point and then a couple of my own stories to tell.

The general point is that you should NOT read too much into this. Tech 
support or sales on any consumer service is very dumb. Most often they 
do not even understand their own current business, let alone new 
features or trends. As an example, in cellular data networking the 
concept of an APN (Access Point Name) is crucial to the operation of the 
networks and the user configurations. A few years ago I had some 
connectivity trouble and called the operator's help desk to see if I had 
the right APN. I had to progress FOUR LEVELS through their technical 
support layers before I even got someone who understood the term APN. 
And this was for something about their current networks. Had I asked 
about rolling out (N+1)G I probably would have had to go through even 
more levels.

And then to my other story. Its a happy IPv6 story, I think. As a test 
case, I  called my ISP this morning. For background, my previous ISP 
merged with this ISP last week. I'm talking to their first level support 
guy.

Me: Can you enable IPv6 for my ADSL?
Agent: We do have that service. Can I get your address?
Me: <my address>
Agent: You are one of the customers moved from the other ISP last week
Me: Yes
Agent: I would normally just turn IPv6 for you here, but for these 
accounts its not possible yet.
Agent: You can get the IPv6 service but let us call you back after some 
investigation. You may need to change your account type.
Me: Ok

(The ISP is Nebula, by the way, http://www.nebula.fi. Other people have 
had good IPv6 experience with them.)

Jari

---

From: "t.petch" <[email-masked]>
Date: Mon, 13 Jun 2011 14:16:02 +0200

Another data point from a different and large ISP (and mobile company).

Mobile supplier calls.  We have this great new broadband offer for you with all
these irresistible features.

Tom. Does it support IPv6, Internet Protocol version six?

Mobile supplier.  I will check with my supervisor.

.... {long pause}

Mobile supplier.  We support 95, 98, 2000, XP, Vista and 7.

Tom.  Thank you, but not today.

(This is one of four major suppliers in my country of whom zero have announced
IPv6 support or have any hits on their web sites last time I looked at them)

Tom Petch

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "IETF Discussion" <[email-masked]>
Sent: Thursday, June 09, 2011 8:24 PM
Subject: one data point regarding native IPv6 support

> Me: "I understand that, but I'm asking about Internet Protocol version 6,
IPv6.  The Internet has been using IP version 4 since the early 1980s, but
that's running out.  IPv6 is the new version."
> Second person: "I'm sorry for the wait time.  I've been trying to find the
answer to your question, but nobody here seems to know anything about it.  We're
trying to get in touch with people who run the network to ask them.   Can I get
your number and call you back?"
>
> Granted, this is just one ISP.  The other ISP that offers service in my area
put me on hold for an hour and a half *before anyone ever talked to me* when I
tried to get a quote from them, so I concluded that they wouldn't be a good
choice.  And these guys have been good about support in general.  They seem to
know their stuff, which is more than I can say for some ISPs I've dealt with in
the past.
>
> I live in a well-settled urban area, three miles from the center of the city
(and sadly, four miles from my CO, which means my DSL circuit gets around
380kbits/sec).  It's not a backwater, there's plenty of lit fiber running
through town.  But when the support people for a fairly well-established telco
haven't even heard of IPv6, it's hard to believe that it's going to be available
anytime soon.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 13 Jun 2011 06:34:58 -0700

On Jun 12, 2011 11:26 PM, "Michel Py" <[email-masked]>
wrote:
> That's the difference between a fait promise and a proven failure. The
promise of "IPv6 native IPv6 is going to be deployed next year" has failed
for 10+ years in a row. Nobody believes in it anymore; your choices are to
believe in yet another transition mechanism or switch to the post-mortem
camp.

I believe there is data to show this time is different (iana and apnic are
exhausted, successful v6day, docsis 3.0 and LTE deployment ...)

> Get a life.

Thanks

Cb

---

From: "t.petch" <[email-masked]>
Date: Mon, 13 Jun 2011 14:52:20 +0200

----- Original Message -----
From: "Nathaniel Borenstein" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: "John Levine" <[email-masked]>; <[email-masked]>
Sent: Sunday, June 12, 2011 8:49 PM

> Just for the record:
>
> -- I don't believe that my single experience with first line tech support at
BT says much about BT's broader role, or its relative sophistication and service
quality as an ISP.  For all I know it's the best ISP in the world, and has a
lone bozo at tech support to qualify for a "jobs for bozos" tax credit.  I was
simply relating an experience that I found rather extreme.

In a similar but different vein, I asked BT marketing whether or not they
supported FTP (as in File Transfer Program).  I got escalated to Third line
support before I came across anyone who understood the question.

For me, the underlying point is that for the vast mass of Internet users and
Internet traffic, what we talk about in the IETF is mostly an irrelevance; the
ISPs (and content providers) are responding to the reality of the market.
Coming back to the original issue (should this I-D go forward?) I note that an
individual (and we are all of course participating as individuals), who
co-incidentally has google in his credentials, states that the failings of 6to4
are causing him big support problems.  For me, that is a powerful reason why
this I-D should advance, ideally before 8th June (sigh), regardless of whether
or not anyone can spell 1Pv6.

Tom Petch

>
> -- I do believe that a world in which any tech support person at any major ISP
doesn't know how to spell IP -- whether he's telling you to turn off IPv6 or
not -- is a world in which it is very challenging to expect positive outcomes in
the major technical transition we are trying to effect.
>
> -- I don't believe that I know what to do about it.  I'm almost sorry I
mentioned it -- we still have a long way to go before we need to start worrying
about Grandma configuring IPv6 at home.  -- Nathaniel
> > agree.  So when we're trying to evaluate whether IPv6 is widely available,
it's not sufficient for it to be widely available to clueful users who can
badger their way past first tier support.  It has to be available to Grandma.

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 13 Jun 2011 09:15:27 -0700

> implementation based on it.

That's doesn't follow. 6rd borrows a mechanism used in 6to4, 6rd has no dependance on host 6to4 implementations or the 6to4 any-cast address.

---

From: Ofer Inbar <[email-masked]>
Date: Mon, 13 Jun 2011 12:24:40 -0400

I've never been able to get first level tech support at my ISP to
understand "latency" or "packet loss".  They only understand "can you
load a web page?"  This does not mean their ISP doesn't provide packet
loss and latency, standard with their service :)

More to the point, when I've been at hotels or conference centers or
similar places and found that I could connect to their wireless
network but not get an IP, it's been rare for their tech support to
recognize the term "DHCP", know what an auto-configured IP looks like,
or even understand the distinction between getting on the local
wireless and having routability to the Internet.  Yet their systems
clearly provide and depend on these things, and always have.  Their
lack of clue says nothing about the level of support for things like
basic IP routing, or DHCP, in hotel and conference center networks.

I wouldn't take what first level support has heard of to be a
systematic indication of anything other than that company's hiring
and training practices for first level support.
  -- Cos

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 13 Jun 2011 12:50:27 -0400

> loss and latency, standard with their service :)

Oh yeah...  Many years ago, I was experiencing 5-15% packet loss and 5-90%
packet duplication.  Tier 1 told me to clear my browser cache, and besides
5% packet loss was normal.  I demurred; he told me he handled 20-25
performance calls/day and his advice fixed them.  I asked to speak to a
supervisor.  He and his supervisor apparently took offense; since my
connectivity was via a deal with my employer, they passed it up their
management chain to complain to my management that I didn't believe their
technicians.  Some VP on their side AltaVistaed me, though, at which
point my complaint got routed straight to engineering and the story got
passed on to my management...

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: "t.petch" <[email-masked]>
Date: Mon, 13 Jun 2011 18:06:35 +0200

----- Original Message -----
From: "Joel Jaeggli" <[email-masked]>
To: "Michel Py" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; "IETF-Discussion"
<[email-masked]>
Sent: Monday, June 13, 2011 6:15 PM
> > implementation based on it.

To quote from the draft (anyone read it?:-)

"   6rd [RFC5969] utilizes the same encapsulation and base mechanism as
   6to4, and could be viewed as a superset of 6to4 (6to4 could be
   achieved by setting the 6rd prefix to 2002::/16).  However, the
   deployment model is such that 6rd can avoid the problems described
   here.  In this sense, 6rd can be viewed as superseding 6to4 as
   described in section 4.2.4 of [RFC2026]"

6rd good; 6to4 {as described in section 4.2.4 of [RFC2026]} bad.

Tom Petch

> That's doesn't follow. 6rd borrows a mechanism used in 6to4, 6rd has no
dependance on host 6to4 implementations or the 6to4 any-cast address.

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2011 00:08:32 -0400

>   described in section 4.2.4 of [RFC2026]"

yes, but that part of the draft is false.  6to4 and 6rd have different use cases.  It's not as if I can install 6rd on my laptop and be able to talk to IPv6 hosts.

> 6rd good; 6to4 {as described in section 4.2.4 of [RFC2026]} bad.

6to4 awesome.  it's those BGP advertisements for broken relay routers, and those ISPs that filter protocol 41 that are bad.

Keith

---

From: "Michel Py" <[email-masked]>
Date: Mon, 13 Jun 2011 21:57:39 -0700

> Keith Moore wrote:
> 6to4 awesome.  it's those BGP advertisements for broken relay
> routers, and those ISPs that filter protocol 41 that are bad.

I won't go as far as supporting you on this one. Anything that makes the network work, good. Anything that breaks the network, bad.

<troll>
Please consider a new version of 6to4 over HTTPS, with a supplemental DPI layer to filter unwanted BGP announcements :P
</troll>

More seriously: if 6to4 is declared historic, someone will hire a brilliant attorney and file for 1Pv6 as a whole to go historic as well, on the same grounds: "disable 1Pv6" has become SOP for the script monkeys, and therefore 1Pv6 is detrimental for the Internet as a whole.

Everyone, careful what you are wishing for; the clock to IPv4 exhaustion as come and gone; it should be clear by now that if shortage of IPv4 was a valid concern, everyone would be scrambling to deploy 1Pv6 while the last crumbs of the last /8 given to the RIRs remains.

It is not the case. Warning: fecal matter impact on air turbine predicted.

Michel.

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2011 01:37:01 -0400

> I won't go as far as supporting you on this one. Anything that makes the network work, good. Anything that breaks the network, bad.

There are several problems with that logic:

One problem is that the network doesn't entirely break or not break in the presence of feature X; it works for some people and breaks for some others.

Another is that it doesn't address tussles.  If feature X and feature Y are mutually incompatible, in that use of feature X breaks feature Y and vice versa, who is to say which feature is good and which is "breaking" the network? 

Another is that when (some) network operators configure their network in such a way as to break feature X, others use that breakage as an excuse to justify breaking even more things.

Keith

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Jun 2011 18:43:10 +0100

Michel,

making 6to4 historic does not affect 6rd. I think the draft says that much too.
I don't think we are saying that native necessarily is better than tunnels.
we are saying unmanaged tunnels crossing the Internet is bad.
6rd is managed and contained within a single SP's network.

cheers,
Ole

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2011 13:55:57 -0400

> we are saying unmanaged tunnels crossing the Internet is bad.

I think this misses the point.  Most internet traffic is "unmanged".  The fact that in the case of 6to4 the traffic is protocol 41 doesn't affect this.  

The real problem here is that there are relay routers that advertise connectivity to one or both anycast addresses via BGP, that aren't properly managed.

A related problem, I suppose, is that to a user, 6to4 looks like "the network".  And if there's a problem, the user will blame "the network" and ask "the network" support people to fix it.  And quite often the problem is not in the access network but in another network.  But (and please forgive my ignorance of operational issues) I don't see how that's inherently different from any case where there's a BGP advertisement to somewhere that blackholes traffic.  Except maybe that there are a growing number of 6to4 users who can complain, and that all 6to4-related problems tend to get lumped together in the minds of support people even if they're caused by different networks and routers.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 14 Jun 2011 11:16:40 -0700

Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that would take a direct
connection from the customer. 

6to4 direct between the content and consumer is still an 'unmanaged' tunnel
which takes exactly the same path as IPv4 would, so the 'badness' is not due
to managed vs. not. In the grand scheme of things, the last thing the
content providers want is for the network to wrest control over streams into
a walled-garden model. Unfortunately they are not thinking this through,
they are just whining because the deployment of a second prefix on their
content servers does not conform to their IPv4-think dream world. 

Tony

> Keith Moore
> Sent: Tuesday, June 14, 2011 10:56 AM
> To: Ole Troan
> Cc: Michel Py; IETF-Discussion
> I think this misses the point.  Most internet traffic is "unmanged".
> The fact that in the case of 6to4 the traffic is protocol 41 doesn't
> affect this.
> 
> The real problem here is that there are relay routers that advertise
> connectivity to one or both anycast addresses via BGP, that aren't
> properly managed.
> 
> A related problem, I suppose, is that to a user, 6to4 looks like "the
> network".  And if there's a problem, the user will blame "the network"
> and ask "the network" support people to fix it.  And quite often the
> problem is not in the access network but in another network.  But (and
> please forgive my ignorance of operational issues) I don't see how
> that's inherently different from any case where there's a BGP
> advertisement to somewhere that blackholes traffic.  Except maybe that
> there are a growing number of 6to4 users who can complain, and that all
> 6to4-related problems tend to get lumped together in the minds of
> support people even if they're caused by different networks and
> routers.
> 
> Keith
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2011 14:33:00 -0400

> connection from the customer. 

Well, to be fair, they weren't supposed to have to get involved with 6to4 if they didn't want to.  To the extent that 6to4 causes pain for operators that don't provide relay routers, this is a mostly-unanticipated and unintended consequence.  (Operators weren't expected to *like* 6to4, because at the time 6to4 was written there was a general dislike for tunnels in general.  But neither was it expected to cause them as much pain as it apparently does.)

> content servers does not conform to their IPv4-think dream world. 

Though it's clear that some operators want to impose the walled garden, I think 6to4 can cause some pain even for those that don't.  I'm hopeful that this pain will be short-lived and will be remedied in the short term by (a) relay router operators acting more responsibly, (b) content-providers providing their own 6to4 addresses, their own 6to4 gateways for return traffic, and/or (c) (less ideally) DNS tricks to minimize IPv6 exposure to networks known to have trouble with 6to4.  In the not-so-much-longer term I hope the pain is relieved by widespread adoption of native IPv6 or at least "managed" transition schemes such as 6rd. 

But did we really expect there to not be growing pains associated with IPv6 transition and deployment?   We certainly had them with IPv4 transition and deployment.  After all, 6to4 is pretty much the ARPAnet/MILnet to Internet transition revisited; that's where I got the idea.

Keith

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 14 Jun 2011 11:36:05 -0700

On Jun 14, 2011, at 11:16 AM, Tony Hain wrote:

> to managed vs. not.

And the breakage still exists even if you do that.

> In the grand scheme of things, the last thing the

Really? More ip addresses on load balancers has never been a problem.

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2011 14:46:54 -0400

> And the breakage still exists even if you do that.

do "what"?

As I understand it, the breakage mostly happens when the traffic doesn't  take exactly the same path as IPv4 would, but rather when the traffic moves between the IPv4 world and the IPv6 world (or vice versa) via a relay router that's advertising a route to a network that it can't actually get traffic to.

Though of course there are other sources of breakage:  ISPs that filter protocol 41 (thus violating the "best effort" model); and NATs, including LSNs.  Neither of these is 6to4's fault.  The IPv4 network is supposed to make a best effort to convey traffic from source to destination, regardless of protocol type, without altering it other than the TTL field.   If ISPs break 6to4 traffic by filtering protocol 41, that's clearly their fault.  Likewise, if ISPs break 6to4 traffic by imposing NAT on their customers, that's also quite clearly their fault.  It's not like we haven't known FOR TWENTY YEARS NOW (remember Kobe?) that the Internet was running out of addresses and had a standardized replacement in place FOR OVER FIFTEEN YEARS.

If an ISP that has aggressively deployed IPv6 wants to whine about 6to4 support issues, I guess they have a legitimate gripe.

Keith

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 14 Jun 2011 11:52:43 -0700

>> And the breakage still exists even if you do that.

deploy your own relay, as observed by geoff and others that does not rehabilitate (by which I mean make it usable for those customers) 6to4.

> Though of course there are other sources of breakage:  ISPs that filter protocol 41 (thus violating the "best effort" model); and NATs, including LSNs.  Neither of these is 6to4's fault.

it results in a failure from the vantage point of the customer. you're splitting hairs pretty fine if you not willing to ascribe that to 6to4.

>  The IPv4 network is supposed to make a best effort to convey traffic from source to destination, regardless of protocol type, without altering it other than the TTL field.   If ISPs break 6to4 traffic by filtering protocol 41, that's clearly their fault.  Likewise, if ISPs break 6to4 traffic by imposing NAT on their customers, that's also quite clearly their fault.  It's not like we haven't known FOR TWENTY YEARS NOW (remember Kobe?) that the Internet was running out of addresses and had a standardized replacement in place FOR OVER FIFTEEN YEARS.
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2011 14:59:41 -0400

> deploy your own relay, as observed by geoff and others that does not rehabilitate (by which I mean make it usable for those customers) 6to4.

Ah yes.  This reduces but does not eliminate the potential for breakage.  Native IPv4 will still work better, and should generally be preferred over 6to4, for the cases where both endpoints have v4 addresses and the application can tolerate any NATs in the signal path.

> it results in a failure from the vantage point of the customer. you're splitting hairs pretty fine if you not willing to ascribe that to 6to4.

Admittedly, to the customer's point-of-view the problems are associated with 6to4, or (more likely) IPv6 in general.  But the problems can't be fixed by looking only at the vantage point of the customer.  

When network operators are the major cause of the problems, and they want to blame 6to4 for it... well, there's a word for that.  Bottom line, that kind of attitude is not going to get the problem fixed either for 6to4 specifically or IPv6 in general.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 14 Jun 2011 13:37:54 -0700

I did not say deploy you own relay ... that is braindead and doesn't even
come close to understanding how the technology works. A 6to4 router at the
content end is not a relay because it is strictly dealing with 2002:: on
both sides. The only time a relay is required is to transit between the
2002:: prefix and the RIR prefixes. There is no reason to go there, but
people insist because their IPv4-think myopia refuses to allow them to
realize that their content server can simultaneously have an RIR prefix and
a 2002:: prefix.

Tony

From: Joel Jaeggli [mailto:[email-masked]] 
Sent: Tuesday, June 14, 2011 11:53 AM
To: Keith Moore
Cc: Tony Hain; 'Ole Troan'; 'Michel Py'; 'IETF-Discussion'
Subject: Re: one data point regarding native IPv6 support

to managed vs. not.

do "what"?

deploy your own relay, as observed by geoff and others that does not
rehabilitate (by which I mean make it usable for those customers) 6to4.

As I understand it, the breakage mostly happens when the traffic doesn't
take exactly the same path as IPv4 would, but rather when the traffic moves
between the IPv4 world and the IPv6 world (or vice versa) via a relay router
that's advertising a route to a network that it can't actually get traffic
to.

Though of course there are other sources of breakage:  ISPs that filter
protocol 41 (thus violating the "best effort" model); and NATs, including
LSNs.  Neither of these is 6to4's fault. 

it results in a failure from the vantage point of the customer. you're
splitting hairs pretty fine if you not willing to ascribe that to 6to4.

 The IPv4 network is supposed to make a best effort to convey traffic from
source to destination, regardless of protocol type, without altering it
other than the TTL field.   If ISPs break 6to4 traffic by filtering protocol
41, that's clearly their fault.  Likewise, if ISPs break 6to4 traffic by
imposing NAT on their customers, that's also quite clearly their fault.
It's not like we haven't known FOR TWENTY YEARS NOW (remember Kobe?) that
the Internet was running out of addresses and had a standardized replacement
in place FOR OVER FIFTEEN YEARS.

If an ISP that has aggressively deployed IPv6 wants to whine about 6to4
support issues, I guess they have a legitimate gripe.

Keith

---

From: "Michel Py" <[email-masked]>
Date: Thu, 23 Jun 2011 12:46:33 -0700

Ole,

> Ole Troan wrote:
> making 6to4 historic does not affect 6rd. I think the draft
> says that much too. I don't think we are saying that native
> necessarily is better than tunnels. we are saying unmanaged
> tunnels crossing the Internet is bad.

That was bad wording from me indeed; instead of "constant references in
6RD to 6to4" I should have said "constant references in RFC5569 to
6to4".

I am curious about one thing though, why didn't you make RFC5969 to
obsolete RFC5569?

Michel.