Subject: Re: [v6ops] I-D Action:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Oct 2010 10:35:46 +1300

Not to beat about the bush, I think this is a horrible idea.

6to4 is a temporary transition tool, which was actually designed
specifically to bypass ISPs that were not providing any form of
IPv6 service. I fully agree that ISPs should be managing transition,
but doing that by adding a NAT kludge to a temporary transition
tool is truly not the way to do this.

What would be good would be to detail carefully the failure scenarios
for 6to4 (and Teredo) and then recommend mitigations, for both ISPs
and content providers. At this point, it's clearly in the interests
of ISPs and content providers to do so.

Regards
   Brian Carpenter

---

From: "Armstrong, Bill R" <[email-masked]>
Date: Tue, 19 Oct 2010 18:04:21 -0500

So now we are forced to either pine for yet another non-existent bigger-and-better transition technology that's based on a world view where market factors don't drive the adoption of new technologies or write yet another list of things we know are broken (or will be) with the existing technologies(perhaps such and exercise was the impetus for this draft?)? 

6to4 is one of the few transition technologies that, due to its prevalence in a good deal of EXISTING devices could allow for a more seamless transition to the IPv6 internet as well as act as a signal to both Internet and Content providers that PEOPLE are using the v6 internet. However due to the complete lack of any traffic engineering capabilities the user experience is FAR from ideal. All the while the addition of Stateless NAT on the provider network (+1 for no consumer side changes\purchases) could allow for wider adoption of potentially LESS-broken IPv6 overnight(literally a maintenance window to enable the NAT in front of a given 6to4 relay).

-Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, October 19, 2010 4:36 PM
To: [email-masked]; IPv6 Operations
Subject: Re: [v6ops] I-D Action:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

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

E-MAIL CONFIDENTIALITY NOTICE: 

The contents of this e-mail message and 
any attachments are intended solely for the 
addressee(s) and may contain confidential 
and/or legally privileged information. If you 
are not the intended recipient of this message 
or if this message has been addressed to you 
in error, please immediately alert the sender
 by reply e-mail and then delete this message 
and any attachments. If you are not the 
intended recipient, you are notified that 
any use, dissemination, distribution, copying, 
or storage of this message or any attachment 
is strictly prohibited.

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Oct 2010 16:19:42 -0700

> 6to4 is one of the few transition technologies that, due to its prevalence in a good deal of EXISTING devices could allow for a more seamless transition to the IPv6 internet as well as act as a sig…

</chair>
Personally, I think the issues that make 6to4 service less than wonderful are far more related to draft-ietf-v6ops-tunnel-loops and  than they are to traffic engineering capabilities. 6to4 encapsulates IPv6 in IPv4, which means that in today's predominantly IPv4 network 6to4 enjoys the same traffic engineering that IPv4 traffic encounters.

---

From: Erik Kline <[email-masked]>
Date: Tue, 19 Oct 2010 16:31:35 -0700

> Personally, I think the issues that make 6to4 service less than wonderful are far more related to draft-ietf-v6ops-tunnel-loops and  than they are to traffic engineering capabilities. 6to4 encapsul…

Also, this may basically be too late.  Some operating systems already
de-pref 6to4 when rfc1918 is available, and as other OSes pick this up
apps won't use 6to4 (yay) except to reach an IPv6-only destination
(fair enough).

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Oct 2010 16:45:07 -0700

On Oct 19, 2010, at 4:31 PM, Victor Kuarsingh wrote:

> I cannot stop 6to4, but can try and make it better as experienced by a customer (who has no knowledge, of IP and is just trying to "do" something on the web).  

No doubt.

</chair>
My humble perspective, speaking strictly for myself here, is that any ISP (not just your employer, but any ISP) that is really concerned about consumer experience of IPv6 would do better to deploy IPv6 and manage it the same way it manages IPv4 traffic than to try to manage the way its customers work around the lack of native support.

---

From: "Victor Kuarsingh" <[email-masked]>
Date: Tue, 19 Oct 2010 17:48:51 -0400

Brian,

Valid input.

On a side note then, I am happy to entertain additional input as to what an "operator" can do for the following use case.

- Post IPv6 ramp up / IPv4 runout
- consumer is on IPv4-only (based on access network, home CPE etc)
- IPv6 only (AAAA) is now a possibility

This idea was not intended as a "transition tool" but more of a catch all.  It works with what's 'out there'.  I agree other mechanisms are better (i.e. Native, 6RD, 6a44 etc), but that all assumes an upgraded CPE/host.  this intended to be used as part of the tool kit, not a sole option.

Was trying to solve an issue we have in provider environments where we cannot get equipment changed out for so many reasons 

regards,

Victor

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Tue 10/19/2010 5:35 PM
To: [email-masked]; IPv6 Operations
Subject: Re: I-D Action:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

Regards
   Brian Carpenter

This e-mail (and attachment(s)) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived. If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this e-mail or any of its content is strictly prohibited and may be unlawful. All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business. E-mails are not secure and you are deemed to have accepted any risk if you communicate with us by e-mail. If received in error, please notify us immediately and delete the e-mail (and any attachments) from any computer or any storage medium without printing a copy.

Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et peut faire l’objet de droit d’auteur et de privilège juridique; aucun droit connexe n’est exclu. Si vous n’êtes pas le destinataire visé ou son représentant, toute étude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est strictement interdite et peut être illégale. Tous les messages peuvent être surveillés, selon les lois et règlements applicables et les politiques de protection de notre entreprise. Les courriels ne sont pas sécurisés et vous êtes réputés avoir accepté tous les risques qui y sont liés si vous choisissez de communiquer avec nous par ce moyen. Si vous avez reçu ce message par erreur, veuillez nous en aviser immédiatement et supprimer ce courriel (ainsi que toutes ses pièces jointes) de tout ordinateur ou support de données sans en imprimer une copie.

---

From: "Victor Kuarsingh" <[email-masked]>
Date: Tue, 19 Oct 2010 19:31:56 -0400

Fred/others,

I think Bill was eluding to the issue of 6to4 return path (my guess).  When we (operators) put in BRs for 6to4 to help create a "better" 6to4 service, we cannot control the return path.  I know this was not the original intent of 6to4, but if the return path was not subject to less then optimal (sometime long) return paths, it is not bad as a catch all (it's widely deployed in OSs and equipment).

Our IPv4 environment follows (for the most part) our IPv4 route advertisement policy (i.e traffic comes back in a manner related to how we announce routes).  As for 6to4, the IPv6 return (which is vetted by relay on IPv6 side) it does not share our route "policy" attributes.

Victor

-----Original Message-----
From: Fred Baker [mailto:[email-masked]]
Sent: Tue 10/19/2010 7:19 PM
To: Armstrong, Bill R
Cc: Brian E Carpenter; [email-masked]; IPv6 Operations
Subject: Re: [v6ops] I-D	Action:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

</chair>

---

From: Xing Li <[email-masked]>
Date: Wed, 20 Oct 2010 08:36:04 +0800

> My humble perspective, speaking strictly for myself here, is that any ISP (not just your employer, but any ISP) that is really concerned about consumer experience of IPv6 would do better to deploy…

Fully agree with Fred.

xing

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Oct 2010 14:17:39 +1300

> I think Bill was eluding to the issue of 6to4 return path (my guess).  When we (operators) put in BRs for 6to4 to help create a "better" 6to4 service, we cannot control the return path.  I know thi…

Sure. So if every ISP that has customers operating servers with IPv6 connectivity
provided a 6to4 relay and a route for 2002::/16, the return path for 6to4
would end up being the same as the return path for IPv4. That was the design
point, and it seem to me that there is a strong incentive for those ISPs
to make it happen. Maybe this needs to be publicised.

   Brian

> ------------------------------------------------------------------------
> 
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 20 Oct 2010 03:23:25 +0000

Hi Brian,

Fully agree. In practice, how to coordinate all the ISPs to deploy 6to4 Relay is a real challenge. However, using this technique can improve the customer experience day one. As Victor pointed out, this isn't a transition tech. We merely want to provide a better experience to the existing 6to4 users without changing anything. No new CPE or host upgrade. The relay will sunset as soon as people change their CPE to native v6 or 6rd.

Regards,
Yiu

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Oct 2010 22:41:08 -0700

> My humble perspective, speaking strictly for myself here, is that any
> ISP (not just your employer, but any ISP) that is really concerned
> about consumer experience of IPv6 would do better to deploy IPv6 and
> manage it the same way it manages IPv4 traffic than to try to manage
> the way its customers work around the lack of native support.

yesssssssssss!  

bleeping brilliantly said.  thank you.

randy

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 19 Oct 2010 23:52:09 -0700

Fred,

I do agree with your position, but that is predicated on the ISP "managing"
the CPE.  In many cases, the ISP just provides "access" to IP which means
the customer equipment and it's capabilities are what determines what is
feasible at that site.

All the IPv6 enablement I do cannot change that (again, short of changing an
entire business model for a company, this is running state for many ISPs).
IPv4 service worked well since the equipment acquired by customers had a
baseline of functionality which for the most part worked with the provider
upstream systems.  IPv6 poses new challenges since the existing and deployed
gear in many cases dose not support IPv6. ISPs will try to get this
corrected but cannot control the entire deployment base.

But I do find that many see this transition challenge as an "either/or"
where we (many ISPs) see it as a combination of strategies.  I can work to
provide IPv6 native connectivity, while providing a better service for
endpoints that cannot support IPv6 day 1.  This was targeted as a part of
the "mix" to keep things going while the real work of IPv6 deployment is
carried out (again, not either/or, but parallel streams where this is not
compromising the IPv6 deployment).

This option is very easy to put in place (like 6to4 relays) and is low
touch.  I would not consume many resources and engineering effort.

I do see the argument if this was the sole strategy for a provider (which
makes little sense), but do not fully see everyone's position if it's part
of a bigger mix of technologies (of which IPv6 native is one) that supply
services to the large cross-section of customers with varying degrees of
functionality.  I can push for IPv6 and have this running on the side.

Regards,

Victor

---

From: "Armstrong, Bill R" <[email-masked]>
Date: Wed, 20 Oct 2010 01:53:47 -0500

I also agree with Fred, Native is the win and is undoubtedly the goal. Sorry if I was bit confrontational earlier, but let's be honest at present there are very few customers asking for IPv6, the vast majority of IP enabled consumer electronics (non-PCs) are IPv4 only, and the lack of US-based IPv6 content doesn't exactly foster the kind of "rah-rah-lets-go-spend-a-fortune-to-replace-N-million-IPv4-only-CPE" attitude, engineer types would hope to see from the business. So if there is a relatively quick and cost effective way for an ISP to provide an improved IPv6 experience right out of the gate, despite it not being Native, shouldn't it, at the very least be considered? Particularly when the alternative is simply waiting for 6rd\DS-lite\Native capable CPE or taking no action whatsoever(time is of the essence, no?). 

Another thing that I think needs to be considered is that every day for a subset of IPv6 internet users, legitimately impaired IPv6 service exists, and some fraction of those users has their crummy IPv6 experience recorded and reported on. These metrics and others like them are the same metrics that will influence the data used in the decision making process by countless organizations, be they Enterprises, ISPs or Content Providers to help determine when they feel they should take the IPv6 plunge. And for those organization that are perfectly happy with their single /24 and gobs of NAT what reason, based on those underperforming IPv6 metrics, would they have to even request\enable Dual-Stacked or Native service from their provider? I'm not trying to say that 6to4 relay users influence the lions-share of the IPv6 internet use statistics, I'm sure their far from it, what I am saying is that from a purely altruistic-geek perspective, isn't anything that will help signal and allow for the adoption of v6 on a broader scale as well as help to provide improved internet performance what we're all after?

-Bill

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Tuesday, October 19, 2010 7:36 PM
To: Fred Baker
Cc: Victor Kuarsingh; IPv6 Operations; [email-masked]; Armstrong, Bill R
Subject: Re: [v6ops] I-D Action:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

Fully agree with Fred.

xing

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Oct 2010 10:20:27 +0200

Le 20 oct. 2010 à 05:23, Lee, Yiu a écrit :

> ... However, using this technique can improve the customer experience day one.

To some extent, it might (and, from a strictly technical point of view, the idea is neat), but:
- Providers that would support it would, for their customers, BREAK the e2e transparency (that IPv6 has so far restored in the Internet, and that is IMHO a great progress not to be lost).
- Unless I misunderstand, the draft doesn't completely describe what happens to 6to4 addresses that have non 0 SLA-ID after their embedded IPv4 addresses. 
- The requirement of a Customer opt-out introduces significant complexity. 

Regards,
RD

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Oct 2010 04:07:28 -0700

> there are very few customers asking for IPv6

and there are very few customers asking for ipv4.  they just want their
mtv.

very few customers walk into the car sales showroom and ask about the
wheel bearings.

randy

---

From: [email-masked]
Date: Wed, 20 Oct 2010 09:43:20 -0400

> - Providers that would support it would, for their customers, BREAK the 
> e2e transparency (that IPv6 has so far restored in the Internet, and 
that 
> is IMHO a great progress not to be lost).
> - Unless I misunderstand, the draft doesn't completely describe what 
happens 
> to 6to4 addresses that have non 0 SLA-ID after their embedded IPv4 
addresses. 

Remi, 
On this regards, please have a look at the following draft, it describes 
in 
more details how the addressing is affected (this draft is not available 
as

> - The requirement of a Customer opt-out introduces significant 
complexity. 

JFT

---

From: [email-masked]
Date: Wed, 20 Oct 2010 10:13:33 -0400

> bleeping brilliantly said.  thank you.

Right, we are all in violent agreement that native IPv6 is the way to go. 

All the ISPs who support 6to4-PMT also strive to deploy native 
IPv6 in their network in a timely fashion. However, the hard reality 
is that vendor support is often lacking and/or prohibitivly 
expensive (like replacing the equipment with the latest one). 

So let me return the question to my favorite vendor (first poster in
this mail). When can I get the IPv6 features I need to deploy 
IPv6 natively? Oh, and btw, I need that to be cheap, no hardware 
upgrades please. 
The bottom line is that most vendors support for real-life deployment 
is late and we have to live with 6to4 being deployed now with 
a sub-optimal number of relays. Even if 6to4-PMT breaks e2e, it 
still provides IMHO for a better user experience in many cases, 
until native is available at every doorstep. (or 6RD as a temporary 
step toward native). 

We've all heard several times complaints about the lack of 
operator participation at the the IETF. Well, the last posts 
from Victor, Lee and Bill were real feedback from operators
feeling the pain of pushing IPv6 deployement on a daily basis
and trying to come up with actual implementable solutions. 

/JFT

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 20 Oct 2010 07:24:14 -0700

On Tue, Oct 19, 2010 at 11:53 PM, Armstrong, Bill R
<[email-masked]> wrote:
> I also agree with Fred, Native is the win and is undoubtedly the goal. Sorry if I was bit confrontational earlier, but let's be honest at present there are very few customers asking for IPv6, the vast majority of IP enabled consumer electronics (non-PCs) are IPv4 only, and the lack of US-based IPv6 content doesn't exactly foster the kind of "rah-rah-lets-go-spend-a-fortune-to-replace-N-million-IPv4-only-CPE" attitude, engineer types would hope to see from the business.

 -> I have said it several times on this list, but it keeps coming up.
 There is a lot of "potential" IPv6 traffic on your network.  Take all
the Google, Youtube, Facebook, Netflix traffic.  Add those all
together and tell me what percent bandwidth they are on your network.
That is IPv6 content available today.  Now add in the IPv6 "saber
rattlers" like Yahoo and the US Gov't.  Reach a tipping point yet?  I
have.

So if there is a relatively quick and cost effective way for an ISP to
provide an improved IPv6 experience right out of the gate, despite it
not being Native, shouldn't it, at the very least be considered?
Particularly when the alternative is simply waiting for
6rd\DS-lite\Native capable CPE or taking no action whatsoever(time is
of the essence, no?).
>
> Another thing that I think needs to be considered is that every day for a subset of IPv6 internet users, legitimately impaired IPv6 service exists, and some fraction of those users has their crummy IPv6 experience recorded and reported on. These metrics and others

->FUD.  I have 6RD at home (thanks Comcast), ISATAP at work (thanks
MSFT for making this easy) and IPv6-only 3G + NAT64 on my mobile
(thanks T-Mobile USA).  I have IPv6 everywhere, and i have NEVER had
an IPv6 related network issue.  NEVER.  I hear people on Macs
sometimes have issues, i don't have a Mac.  Most people don't have
Macs.

 like them are the same metrics that will influence the data used in
the decision making process by countless organizations, be they
Enterprises, ISPs or Content Providers to help determine when they
feel they should take the IPv6 plunge. And for those organization that
are perfectly happy with their single /24 and gobs of NAT what reason,
based on those underperforming IPv6 metrics, would they have to even
request\enable Dual-Stacked or Native service from their provider? I'm
not trying to say that 6to4 relay users influence the lions-share of
the IPv6 internet use statistics, I'm sure their far from it, what I
am saying is that from a purely altruistic-geek perspective, isn't
anything that will help signal and allow for the adoption of v6 on a
broader scale as well as help to provide improved internet performance
what we're all after?

We all agree that customers dont care about ipv4 or ipv6, right?  So
why bother with these hacks that don't actually help you grow your
edge or deploy real IPv6?  It all seems like just a distraction to me.
 Is it just trying to be a good citizen to help get the community some
more short-term mileage out of the (too little, too late) dual-stack
transition strategy for the Internet?

If you have business case for user experience with IPv6 ... then you
should be doing dual-stack.  If you are running out of addersses, you
should do DS-lite. If you don't have a business case ....

Cameron

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 08:08:04 -0700

Remi,

Yes, the e2e transparency loss is of consideration (subject to further test
on impact).

In our testing we found that most in the wild equipment which turns on 6to4
sets the SLA-ID to "0".  Therefore the opt-in is not doing anything (6to4
has just turned itself on automatically).

The opt-out would be setting the SLA-ID to anything by "0" or perhaps "1"
(since 1 is found as the SLA-ID on a few other defaults).

This is only targeted at people of have default settings on their equipment
and no knowledge of IPv4, IPv6 etc.

In the use case where a provider may have turned on NAT44/LSN (NAT444) and
used public IP space (which now breaks auto 6to4), the loss of e2e may not
be as bad as broken 6to4.

Again, I would like to stress, this is just an option to complete the whole
strategy (which is put out IPv6).

Victor

On 20/10/10 1:20 AM, "Rémi Després" <[email-masked]> wrote:

> - Providers that would support it would, for their customers, BREAK the e2e
> transparency (that IPv6 has so far restored in the Internet, and that is IMHO
> a great progress not to be lost).
> - Unless I misunderstand, the draft doesn't completely describe what happens
> to 6to4 addresses that have non 0 SLA-ID after their embedded IPv4 addresses.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 08:14:52 -0700

Cameron,

I agree, we will push out IPv6 native... But the ability to push it out
depends on the access network type, business model etc.  In our mobile
network, it's much easier since we influence (to some extent) what
phones/devices go out there.  The work you have done in this area is great
and we like the path that has been set forth.  I would however argue that
most of the phones in my network do not currently support IPv6 (so that a
bit challenge for us.. But a separate topic)

On the other hand, Wireline access is a different kettle of fish.  Not all
endpoints are managed (which means we don't control what on it and what
functions it has).  I am playing poker with the cards I am delta.  I can't
play for a full house with three different suits.

Yes, this is stop gap measure, which is easy to put in, and very low touch.
I can put it out there fast, cheap and without changing much in the network
(some routes).  We continue to dedicate the lion share of our resources to
IPv6 deployment.  This again is not an either or situation.. It's a part of
the big mix.

Regards,

On 20/10/10 7:24 AM, "Cameron Byrne" <[email-masked]> wrote:

>> I also agree with Fred, Native is the win and is undoubtedly the goal. Sorry
>> if I was bit confrontational earlier, but let's be honest at present there
>> are very few customers asking for IPv6, the vast majority of IP enabled
>> consumer electronics (non-PCs) are IPv4 only, and the lack of US-based IPv6
>> content doesn't exactly foster the kind of
>> "rah-rah-lets-go-spend-a-fortune-to-replace-N-million-IPv4-only-CPE"
>> attitude, engineer types would hope to see from the business.
> 
>> Another thing that I think needs to be considered is that every day for a
>> subset of IPv6 internet users, legitimately impaired IPv6 service exists, and
>> some fraction of those users has their crummy IPv6 experience recorded and
>> reported on. These metrics and others
>

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 20 Oct 2010 08:18:24 -0700

> IPv6 natively? Oh, and btw, I need that to be cheap, no hardware

Maybe your favorite vendor is my favorite vendor

http://www.ietf.org/mail-archive/web/v4tov6transition/current/msg00319.html

Nothing back in 2 weeks ....

Cameron

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 20 Oct 2010 11:25:00 -0400

Is it impossible to agree with both opinions?

Fred/Randy:  Operators should devote scarce resources to deploying 
native IPv6 and managing it well, rather than spinning more complicated 
webs of IPv4 accommodation.

Victor:  The ISP cannot dictate all updates to CPE, must provide access 
to all legacy customers, not just eager IPv6 adopters, so an interim 
mechanism that minimizes their inconvenience is needed.

There are around 100 RFCs and drafts about aspects of coexistence and 
transition flying around*, I sure hope they are not all going to be 
"standardized" because 100 standards for the same thing is about as good 
as none (IMHO).   Some of these are being generated by folks in the 
operator community, not just ivory tower solutions, so they should be 
motivated by real problems that need to be solved.  One size will never 
fit all, so some solutions may be a good fit for one ISP, and not for 
others.  Our job here is to provide engineering opinions on all these 
alternatives, to permit things that will help, and prevent things that 
will harm.

There should be something like "The laws of robotics" for 
transition/coexistence mechanisms:

1.  First, do no harm (to your legacy IPv4 customers, to your eager IPv6 
customers, to the larger community)
2.  Keep it simple (solve particular problems with targeted mechanisms) 
but no simpler than necessary to avoid harm
3.  Design and deploy your interim solution(s) with a clear path to 
eventually render them redundant:  enable, promote and encourage 
transition to native IPv6 (do not install any new equipment that does 
not support IPv6; sunset IPv4 access - without harming legacy customers)

I think these allow an operator complete freedom to manage their own 
network and to chose and operate any coexistence mechanism as long as 
they need to for supporting their customers, except where those choices 
cause harm to someone else.  Of course, there is no universal definition 
of "harm" so reasonable people can disagree, e.g. if a mechanism in use 
on the access side causes additional delay, content providers may see 
that as "harming" their users' experience.  That's why mailing lists and 
WG meetings are just so much fun.

On reflection, these are just corollary to the Robustness Principle or 
Postel's Law [RFC 793] .  "Be conservative in what you do, be liberal in 
what you accept from others."

Ed J

*shameless self-promotion:  take a look at 
http://tools.ietf.org/html/draft-jankiewicz-v6ops-v4v6biblio-02 
something I started to organize my own reading, but posted in case it 
helps anyone.  It tries to take a snapshot of the current work, so if I 
missed or mischaracterized anything, happy to take comments off-list to 
correct before Oct 25 update deadline.

On 10/20/2010 2:52 AM, Victor Kuarsingh wrote:
> On 19/10/10 10:41 PM, "Randy Bush"<[email-masked]>  wrote:
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Oct 2010 17:30:19 +0200

Le 20 oct. 2010 à 16:24, Cameron Byrne a écrit :

> ...

I have a MAC and I have happily used IPv6 since 2008, with Google and IETF servers in particular.

In my understanding, IETF has been so far mistaken in its way to promote IPv6.
By insisting that, to offer IPv6 SERVICE, ISP should first upgrade their networks to DUAL-SATCK ROUTING, it has blocked the process.

One should not ignore that some ISP networks need hardware changes to support dual-stack routing (i.e. time and money).

But, fortunately, what is needed ASAP is the IPv6 SERVICE (real service, i.e. with native addresses, not 6to4 or Teredo addresses which have connectivity problems).

If the IPV6 SERVICE is offered with DUAL-SATCK ROUTING, very fine, but if it is done with 6rd to save time and money, very fine too. 

Regards,
RD

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 20 Oct 2010 15:34:39 +0000

Hi Remi,

Three points: 

(1) This is a 00 draft. We would like to hear more from the group and put
the updates in 01.

(2) For the e2e transparency, this only affects those who rely on the
external initiated connections (like web-server, ssh-server, etc). We
assume most 6to4 users don't rely on e2e transparency.

(3) Some small population will like to have e2e transparency on 6to4. We
want to find a more automatic way to enable them to bypass the 6to4-PMT.
Worst case it may require manual opt-out. This is still under discussion.

Thanks,
Yiu

On 10/20/10 11:08 AM, "Victor Kuarsingh" <[email-masked]>
wrote:

>>> ... However, using this technique can improve the customer experience
>>>day
>>> one.
>> 
>> To some extent, it might (and, from a strictly technical point of view,
>>the
>> idea is neat), but:
>>e2e

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Oct 2010 17:40:35 +0200

> Yes, the e2e transparency loss is of consideration (subject to further test

A short time test cannot show which potentialities of e2e transparence restoration will be lost if, before really restoring e2e transparency we kill it.

> has just turned itself on automatically).

We need IMHO solutions that work in ALL cases of their scope, not only MOST cases.

> strategy (which is put out IPv6).

Deploy IPv6, indeed, but no by destroying part of its value from the outset.

Regards,
RD

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 20 Oct 2010 15:41:28 +0000

Hi Remi,

I agree that 6rd is a very nice solution. The catch for 6rd is CPE
upgrade. This isn't easy for some operators which millions of unmanaged
CPEs.

Regards,
Yiu

On 10/20/10 11:30 AM, "Rémi Després" <[email-masked]> wrote:

>By insisting that, to offer IPv6 SERVICE, ISP should first upgrade their
>networks to DUAL-SATCK ROUTING, it has blocked the process.
>
>One should not ignore that some ISP networks need hardware changes to
>support dual-stack routing (i.e. time and money).
>
>But, fortunately, what is needed ASAP is the IPv6 SERVICE (real service,
>i.e. with native addresses, not 6to4 or Teredo addresses which have
>connectivity problems).
>
>If the IPV6 SERVICE is offered with DUAL-SATCK ROUTING, very fine, but if
>it is done with 6rd to save time and money, very fine too.
>
>Regards,
>RD 
>
>
>
>

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Oct 2010 17:51:54 +0200

Hi,

> - consumer is on IPv4-only (based on access network, home CPE etc)

"enable IPv6 there"

If that's not viable, offer 6rd or configured tunnels.

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: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 09:19:10 -0700

Gert,

IPv6 is not possible everywhere immediately (vendors have been selling us
IPv4-only upto this day).  I can go to the local store and maybe find one or
two boxes that do native IPv6 (the world we live in).

6RD is good, but again, I cannot force an unmanaged device to support
something.  Where I can, I would do this...  For all others, IPv4 (based on
what was sold and what people picked up at their local best buy) with
existing capabilities IS what we have in the near future.

On a side point:

Having customers configure something themselves... we are talking about a
customer base with varying degrees of capabilities (some have trouble
logging on).  I do not think comparing "our" (IETFers and like technical
folks) capabilities to make something work as a template to what can be done
in a production network.. I assume (based on experience) that most customers
will do nothing other the plug it in and turn it on.

Victor

On 20/10/10 8:51 AM, "Gert Doering" <[email-masked]> wrote:

>> On a side note then, I am happy to entertain additional input as to what an
>> "operator" can do for the following use case.
>>

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Oct 2010 18:22:58 +0200

Hi,

On Wed, Oct 20, 2010 at 09:15:58AM -0700, Victor Kuarsingh wrote:
> IPv4-only upto this day).  

Why are you buying IPv4-only products?

> I can go to the local store and maybe find one or

CPEs are a somewhat tricky matter, but even there, things are changing
(see Marco's work on labs.ripe.net).

As an ISP, you always have the option to use some generic and cheap
CPE hardware, and install your own custom firmware.  Or even get someone
to build specific CPEs for you (which is what free.fr did, if I understand
that right - and so they built in 6rd from the start).

> I do not think comparing "our" (IETFers and like technical

Over here, most times end users change to a new DSL provider, they get a
router with the offering for a very good price - and most of the time, 
they just take it, because it offers additional functionality to what
they have, or because they want to have something that is known to work.

Sending out IPv6-capable CPEs at that point will give customers working
IPv6 without having to do anything but "plug it in and turn it on".

If you use an AVM Fritz!Box with some of the (smaller) german DSL networks 
today, this is exactly what happens: SLAAC + DHCP-PD, ISP delegates a /56 
to the CPE, CPE assigns /64 onto its LAN, voila, automatic IPv6.

Gert Doering
        -- NetMaster

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 09:15:58 -0700

Gert,

On a side point:

Victor

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Oct 2010 09:41:03 -0700

On Oct 19, 2010, at 14:35, Brian E Carpenter wrote:

> Not to beat about the bush, I think [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] is a horrible idea.

I'm horrified too.

> to make it happen. Maybe this needs to be publicised.

This is the only other sensible comment I've seen in this thread.  I predict as the v6ops community grows, the blight caused by the presence of unmanaged 6to4 subscriber gateways will only grow more vexing over time.  Content delivery networks are another place where 6to4 is sure to cause headaches.

Not sure IETF is the correct organ to publicizing the problem.  Maybe somebody should bend the ear of a trade magazine reporter.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: [email-masked]
Date: Wed, 20 Oct 2010 12:44:08 -0400

> Why are you buying IPv4-only products?

Gert, 
I have to concur with Victor here, not on buying IPv4-only products, 
but on the fact that IPv6 feature-parity with IPv4 or near feature-
parity is rarely if not ever seen in vendors, even for those touting
IPv6 support. The lack of IPv6 features really hinders production 
deployments. 

>(see Marco's work on labs.ripe.net).

If off-the-shelf IPv6 CPEs become the standard offering as early as
2012, it still leaves years to deal with IPv4-only customers CPEs. 
That's far from the 'instant IPv6' turn-on some posts on this list
seem to be suggesting. Something that works with current CPEs is
required, at least for a few years. That means NAT444 is unavoidable
for many providers. 

> that right - and so they built in 6rd from the start).

For those who provide a CPE maybe. Otherwise you're stuck with whatever 
your clients purchased at the local store. And you can bet that doesn't
support IPv6 yet. 

> IPv6 without having to do anything but "plug it in and turn it on".

Unfortunately, this is rarely the case for cable providers, at least in 
North-America. Most users get their own CPE device and will hold it 
for several years until a major technology change (perceived or real)
will force them to go get another one (for example 802.11n). 
JFT

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 10:20:56 -0700

James,

I agree, if we can get 6to4 relays out there in mass, then the challenges go
away or are subsided.  Unfortunately this is a theoretical position at this
point (having everyone do something for the good of all), and one cannot
build a real network on the notion that "I hope everyone does this".

Also, we are concerned about how long it would take to document, communicate
this concept and have ISPs and content providers implement it.  I have
offered to help Brian document this position as an effort to make it right.

Based on our track record on IPv6 communication and implementation, I would
suggest that it may take a long time to effect this change.. But it's worth
a try.

Regards,

Victor

On 20/10/10 9:41 AM, "james woodyatt" <[email-masked]> wrote:

>> Not to beat about the bush, I think
>> [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] is a horrible idea.
> 
> I'm horrified too.
> 
> This is the only other sensible comment I've seen in this thread.  I predict
> as the v6ops community grows, the blight caused by the presence of unmanaged
> 6to4 subscriber gateways will only grow more vexing over time.  Content
> delivery networks are another place where 6to4 is sure to cause headaches.
> 
> Not sure IETF is the correct organ to publicizing the problem.  Maybe somebody
> should bend the ear of a trade magazine reporter.
> 
> 
> --

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Oct 2010 19:47:02 +0200

>> Not to beat about the bush, I think [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] is a horrible idea.

Breaking e2e transparency in IPv6 should indeed be loudly dissuaded.

> This is the only other sensible comment I've seen in this thread.  I predict as the v6ops community grows, the blight caused by the presence of unmanaged 6to4 subscriber gateways will only grow mor…

The point that if each ISP would operate its own 6to4 relay there would be no IPv4 connectivity problem is right, but this is unlikely to happen.

Consequently, an incentive to spend money to just reduce adverse effects of 6to4 intrinsic limitations, is IMHO a bad advice.
What is needed is good quality IPv6 asap (be it with dual-stack routing and CPEs, with 6rd BRs and CPEs, 6a44 BRs for hosts that eventually support it, or whatever easily operated solution. 

BTW, 6to4 is precisely something that will become impossible as ISPs start assigning RFC1918 addresses to customers (a problem that neither 6rd nor 6a44 have).

Regards,
RD

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 Oct 2010 20:27:34 +0200

In your letter dated Wed, 20 Oct 2010 09:41:03 -0700 you wrote:
>Content delivery
> networks are another place where 6to4 is sure to cause headaches.

Why is that? If a content provider interally just routes 2002::/16 traffic
to a relay box, then it becomes just IPv4 traffic that can be routed to its
destination.

In fact, every content provider can serve 6to4 users better by doing this
themselves instead of relying on the 2002::/16 BGP routes.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 Oct 2010 20:31:23 +0200

>build a real network on the notion that "I hope everyone does this".

A simple hack to get the return traffic is for an ISP that has for example an
IPv4 /16, to put 2002:xxyy::/32 in the IPv6 routing table. This causes all of
the return traffic for that ISP's 6to4 customers to take the right route
back over the IPv6 backbone.

Of course, everybody will officially hate you for doing that because it causes
more entries in the IPv6 routing table. But is a purely local solution that
you can use to get your customers IPv6 connected.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 11:42:24 -0700

Phillip,

Correct, but if people filter the routes, then it would not work.  To be
clear, this was something that was talked about before PMT and it was
suggested that poisoning the IPv6 table with IPv4 routes was a non-starter.

Regards,

Victor

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 Oct 2010 20:47:29 +0200

>suggested that poisoning the IPv6 table with IPv4 routes was a non-starter.

Given the amount of junk in the IPv4 routing table, does it really make sense
to break a relatively clean transition technique by being overly conservative
when it comes to the routing table?

Fortunately, it is not my call.

But it does suggest that the idea that IPv4 space is running out and that we
have to act now is not universally accepted, not even by people running
IPv6.

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Oct 2010 11:58:07 -0700

On Oct 20, 2010, at 11:27, Philip Homburg wrote:
>> Content delivery networks are another place where 6to4 is sure to cause headaches.
> 
> Why is that? If a content provider interally just routes 2002::/16 traffic to a relay box, then it becomes just IPv4 traffic that can be routed to its destination.

A 6to4 relay router needs to be inserted into the optimized paths between every IPv6 content distribution server and its potentially 6to4-located clients.  That's a headache all by itself.

Then there's the more terrifying problem of how your CDN chooses the optimal content server for the client [based on $MAGICK_FAERIE_DUST, which I'm going to leave for other-- more polite-- participants to describe, but trust me: 6to4 can throw any of *several* different giant spanners into those works, depending on how their particular tribe of faeries are organized].

> In fact, every content provider can serve 6to4 users better by doing this themselves instead of relying on the 2002::/16 BGP routes.

What they *can* do, and what they will judge *worth* doing, might be pretty far apart.

p.s. All of the above applies just as well to Teredo, but Teredo has better sunsetting than 6to4.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 12:00:07 -0700

Phillip,

Perhaps the community would accept a "time limited" acceptance of longer
then 2002::/16 set of routes would work.

We would need to get people to agree to not drop them.  And of course, how
would we deal with the "removal" process?  How would we twilight this? This
may be another challenging item which requires a bunch of providers agreeing
to something to do globally.

I am not as concerned about longer then /16s as others.

Regards,

Victor

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Oct 2010 21:10:48 +0200

> I am not as concerned about longer then /16s as others.

or would the community accept:
ip route 192.88.99.1/32 Null0

alternatively and slightly more friendly redirect http 6to4 traffic to a local web server giving instructions for how to disable 6to4 (and use the ISP's native IPv6 service.)

cheers,
Ole

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 12:18:31 -0700

Ole, 

Just as point of reference, there are some "boxes" out there that have auto
6to4 (CPE/Gateways) which cannot be turned off (no option in config).  And
filtering the anycast IPv4 address does not turn it off either (so broken
IPv6).

Regards,

Victor

On 20/10/10 12:10 PM, "Ole Troan" <[email-masked]> wrote:

> alternatively and slightly more friendly redirect http 6to4 traffic to a local
> web server giving instructions for how to disable 6to4 (and use the ISP's
> native IPv6 service.)
> 
> cheers,
> Ole

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Oct 2010 12:22:59 -0700

> alternatively and slightly more friendly redirect http 6to4 traffic to a local web server giving instructions for how to disable 6to4 (and use the ISP's native IPv6 service.)

Again, if the client elevates RFC1918 local addresses to global scope
for 3484 purposes, thereby de-prefing 6to4 when doing addr selection
for dualstack destinations, doesn't this whole thing just become
irrelevant as far as /transition/ is concerned?  You'd only be
concerning yourself with traffic to IPv6-only destinations.

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Oct 2010 21:28:25 +0200

Victor,

> filtering the anycast IPv4 address does not turn it off either (so broken

interesting. would you be able to share with the list (or privately) which CPEs do this?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Oct 2010 21:28:49 +0200

Erik,

> concerning yourself with traffic to IPv6-only destinations.

agree, but I think for a complete host based solutions we need happy eyeballs.

cheers,
Ole

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 12:46:10 -0700

Erik,

I do appreciate everyone's input on this, but I think I still have not been
clear as to how we see this fit into the big picture.

PMT is not "the" option, it only addresses part of a bigger issue.  For the
specific use case we are talking about, yes, we are concerning ourselves
with IPv6 only if IPv4-only access with unmanaged CPEs are used.

Here is example of what some ISPs may see.

1. IPv6 Native (stuff we can get to native IPv6 based on available
hardware/software in the access network and CPE supports IPv6)
2. IPv6 over Managed Tunneled/CPE.  (we can control the CPE and get it IPv6
via technologies like 6RD).
3. (*KEY ISSUE FOR PMT*) IPv4 only access (i.e. DOCSIS 2.0 which cannot be
upgraded to IPv6) with unmanaged CPEs.

It is the third use case we are concerned with if IPv6 only is out there
(again, we are all guessing as to if this may happened in any specific
timeframe).

I need to deal with all three situations.  I will need a mix of
technologies, there is no one-size-fits-all for IPv6 transition (not matter
how much I want it).

Again, vendors have been pumping our customer base with IPv4 only, non-IPv6
CPEs for years and continue to do so.  I am not buying them.. Customers are,
who pay for the entire system which pays all of us (through various channels
and business models)

Regards,

Victor

On 20/10/10 12:22 PM, "Erik Kline" <[email-masked]> wrote:

>> alternatively and slightly more friendly redirect http 6to4 traffic to a
>> local web server giving instructions for how to disable 6to4 (and use the
>> ISP's native IPv6 service.)
>

---

From: "Scott Beuker" <[email-masked]>
Date: Wed, 20 Oct 2010 13:52:25 -0600

> local web server giving instructions for how to disable 6to4 (and use
> the ISP's native IPv6 service.)
> 
> cheers,
> Ole

Ole,

6to4 is not a transition mechanism. It's a band aid to provide users
stuck on an IPv4-only network access to IPv6-only content. Therefore,
bringing up native IPv6 service as a better alternative using 6to4 is
like saying that brushing your teeth twice a day is better than having
to get a brain tumor removed; while the statement is true, the
comparison is totally irrelevant.

The use of 6to4 implies that, for whatever reason, native IPv6 is
unavailable for that user. IPv4 will be preferred over IPv6 on a host
running native IPv4 and IPv6 over 6to4, so 6to4 is only there as a last
resort for IPv6 only content for a user temporarily waiting for native
IPv6 service.

6to4-PMT is a good idea, as are more specific 2002::/16 routes, because
both improve upon a solution with flaws (6to4) which will be utilized no
matter what you say or do. You can either have the better version, or
the existing inferior version, your pick.

You were lucky enough not to have issues with vendors and hardware life
cycles that prevented you from getting native 6to4 deployed in time?
Great! Congratulations! I'm happy for you! Unfortunately, not all of us
are that lucky and we have to deal with vendors dragging their feet on
complete and stable implementations, despite our incessant hounding the
past 2+ years. This is sometimes how things go in the real world, and
that's why we have "Plan C" type measures like 6to4 to temporarily plug
holes and, as such, smooth the transition to IPv6.

Blocking these improvements via this draft will not make 6to4 go away. I
guarantee it.

- Scott

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Oct 2010 22:07:28 +0200

Scott,

> comparison is totally irrelevant.

6to4 is a mechanism created to bypass your local non IPv6 supporting ISP.
that's not the case here and I don't quite see why 6to4 should be the first choice of tool to use.

cheers,
Ole

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 13:15:26 -0700

Ole,

The suggestion was based on the fact that it's out there.  We take what we
have and try and use it for good.  Again, we were given lemons... So we are
making lemonade.

I know that 6to4 was not created for this purpose, but I think as in the
past with other technologies, we can re-purpose or leverage something if it
fits the bill and can help solve a problem.

Regards,

Victor

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Oct 2010 22:25:32 +0200 (CEST)

> then 2002::/16 set of routes would work.

Let's NOT open that can of worms, mmmkay?

Let people do 6RD or something else instead of trying to do more work on 
6to4. 6to4 in its present state is what it is, if people want to deploy 
more relays, fine, but let's not change it, it won't help.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Scott Beuker" <[email-masked]>
Date: Wed, 20 Oct 2010 14:25:37 -0600

Ole,

> first choice of tool to use.

You're getting distracted by things which are moot.

The bottom line is that 6to4 only comes into play when IPv4 is not
available. It's not lifting eyeballs away from IPv4 and towards IPv6. It
is NOT the "first choice of tool to use", it's in fact by definition the
last choice. It's there to provide the consumer a seamless Internet
experience while the Internet is in its transition state.

I'll reiterate what I said prior: trying to blockade improvements to
6to4 will NOT speed the deployment of native IPv6. ISPs that recognize
they may end up utilizing 6to4-PMT *briefly* are already doing
everything they can to deploy native IPv6, but want to improve the
customer experience in the interim for those using 6to4, in the scenario
where IPv6-only content comes faster than we are ready for it.

Attempting to improve upon "Plan C" (6to4) does not imply anything about
a lack of commitment on our part to "Plan A" (native IPv6) or "Plan B"
(better tunnels like 6RD).

I hope for the best, but I plan for the worst.

Thanks,
Scott

---

From: "Armstrong, Bill R" <[email-masked]>
Date: Wed, 20 Oct 2010 15:30:36 -0500

Scott hit the nail on the head. 

-Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Beuker
Sent: Wednesday, October 20, 2010 2:52 PM
To: Ole Troan; IETF V6OPS WG
Subject: Re: [v6ops] I-DAction:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

Ole,

- Scott

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 13:30:44 -0700

Mikael,

We are not changing 6to4... It's status quo.. We are just adding an new
layer to improve created a deterministic path (with loss of e2e).

The longer then /16 route is not a mod either, it's a global agreement issue
(will we accept longer then /16 for 2002::).

Regards,

Victor

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Oct 2010 22:35:29 +0200

Scott,

> I hope for the best, but I plan for the worst.

I'm sure you can provide some better numbers, but am I correct in assuming that:
 - you have an huge set of CPEs that are IPv4 only
 - you have a small set of CPEs supporting 6to4
 - you have a tiny set of those CPEs doing 6to4 by default
 - you have a small set of CPEs supporting 6rd and native IPv6

what I don't quite understand is why the focus on plan C for a presumably tiny set of customers. when the big elephant in the room is the IPv4 only CPEs.

offer a patch for the 6to4 by default CPEs, encourage the users to upgrade to 6rd/native IPv6 CPEs, which is something I would think has to happen anyway...

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Oct 2010 22:47:31 +0200

Hi,

> (will we accept longer then /16 for 2002::).

We're not going to accept 300.000 IPv4 routes coming back as 2002:<ipv4>
spill.  Don't go there.

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Oct 2010 22:52:10 +0200 (CEST)

> layer to improve created a deterministic path (with loss of e2e).

No, 6to4 specifically prohibits more specifics in 2002::/16, to quote 
RFC3056:

"6to4 prefixes more specific than 2002::/16 must not be propagated in
    native IPv6 routing, to prevent pollution of the IPv6 routing table
    by elements of the IPv4 routing table. "

> (will we accept longer then /16 for 2002::).

The RFC prohibits this, so what you're asking for is a change of the RFC.

We're not going there, period.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 13:53:58 -0700

Gert,

That way it was off the table... Based on this position. I agree, it's a
non-starter for many.

Regards,

Victor

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 13:57:21 -0700

Mikael,

Fair enough.. As noted to Gert, it was "an" idea, and it's already off the
table.. It was just a discussion point.

I agree, I don't think anyone is going there (it seems to be a well
understood principle).  But as you said, since the RFC comments on it, it
would in fact be an RFC update.

Regards,

Victor

---

From: "Scott Beuker" <[email-masked]>
Date: Wed, 20 Oct 2010 15:09:56 -0600

>  - you have an huge set of CPEs that are IPv4 only

Correct.

>  - you have a small set of CPEs supporting 6to4

Correct, and this number continues to grow.

>  - you have a tiny set of those CPEs doing 6to4 by default

I'm not sure "tiny" is accurate; we're not entirely sure yet. We know
there's "some", and this number continues to grow.

>  - you have a small set of CPEs supporting 6rd and native IPv6

Incorrect.

By my estimation, we have approximately 0 CPEs support 6RD. Of course,
this number will grow, which is why we plan to support 6RD and would
prefer it over any form of 6to4. But that doesn't mean we don't have a
use case for 6to4.

I could guess and hope that this wouldn't happen, because we'd get
native IPv6 out to 100% of our customers before any of them want/need
it, but doing so and being wrong could get me fired. And when we are
able to get native IPv6 to our customers is indeed beyond my control,
and beyond the company I work for's control too.

I'm truly unsure of where we're at with native IPv6 support in CPE
gateways, but I hope we can agree it's worryingly low today, and it's
not something consumers are apt to replace every 12 months.

> 
> what I don't quite understand is why the focus on plan C for a
> presumably tiny set of customers. when the big elephant in the room is
> the IPv4 only CPEs.

Because where I work we worry about 100% of our customers. Trying to
improve upon 6to4 does not impede in any way my work towards deploying
native IPv6 nor 6RD. Not even slightly. As Victor has pointed out,
though this solution is applicable for a small subset of customers, it
also requires a small amount of work to get up and running, very small
in fact. So it's worthwhile.

On the other hand, who knows how many 6to4 CPEs will be out there a year
from now? We know this number is growing, because we know 6to4 enabled
CPE devices continue to sit on store shelves. Until they're gone, a
reasonable person expects this number to grow as consumers continue to
replace their CPEs through the natural life cycle (aka power surges and
dust).

> 
> offer a patch for the 6to4 by default CPEs, encourage the users to
> upgrade to 6rd/native IPv6 CPEs, which is something I would think has
to
> happen anyway...

I'm just going to assume this paragraph was written tongue-in-cheek.

Thanks,
Scott

---

From: Tina Tsou <[email-masked]>
Date: Wed, 20 Oct 2010 14:40:12 -0700

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Victor Kuarsingh
Sent: Wednesday, October 20, 2010 9:16 AM
To: Gert Doering; Victor Kuarsingh
Cc: IPv6 Operations;
[email-masked]
Subject: Re: [v6ops] I-D
Action:draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt

Gert,

6RD is good, but again, I cannot force an unmanaged device to support
something.  
[Then you may consider using this 
draft-tsou-softwire-gwinit-6rd-00  "Gateway-Initiated" 6rd]

Where I can, I would do this...  For all others, IPv4 (based on
what was sold and what people picked up at their local best buy) with
existing capabilities IS what we have in the near future.

On a side point:

Victor

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2010 11:54:30 +1300

On 2010-10-21 06:20, Victor Kuarsingh wrote:
> point (having everyone do something for the good of all),

No. An ISP operating a 6to4 relay and advertising a 2002::/16 route to it
is acting entirely in the interests of that ISP's native IPv6 customers,
especially if they are content providers. The economic incentive in this
case is not misplaced.

Our confusion comes from thinking of the placement of the IPv4 side of the
relays as important. It isn't; it's the placement of the IPv6 side of
the relays that affects the return path from servers to 6to4 clients.

The paradoxical moral is that all ISPs operating IPv6 services have an
incentive to operate a 6to4 relay, even though they have no 6to4 customers.
This is the message we have failed to convey.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2010 11:57:57 +1300

> you can use to get your customers IPv6 connected.

I remember the authors of 6to4 being severely roasted by an Ops Area
Director (a certain Mr R. Bush) to ensure that RFC 3056 declared this
illegal, immoral and fattening. But I guess it could be used locally,
as long as it never appears in BGP4.

Regards
   Brian Carpenter

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 20 Oct 2010 23:01:15 +0000

+1 except for the IPv4 comments.  From what we are seeing, operators should
not announce their relays publicly over IPv4.  Open 6to4 relays seem to
yield undesirable behavior.  I agree, from experience, that operators should
offer 6to4 relays especially if they have users attempting to use the same.

John

> This is the message we have failed to convey.

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 20 Oct 2010 16:29:07 -0700

Brian,

Thanks for the background.  Now that was a long time ago (in IP years) and
since times have changed and we are looking at solving problems of today, do
you think this position may open to further debate?  As noted in your
example, an ISP can guide traffic for blocks upto a [IPv4]/16 or shorter
with routes in the IPv6 space which are upto [IPv6]/32s. (although this does
not help those who have blocks smaller then /16s - say a small ISP with a
/19, /20 etc)

Just asking.. I think this tangent conversation is very contentious.. But
new problems (i.e. IPv4 run out, lagging CPE capabilities, IPv6 only
endpoint threat) require new idea...

Don't shoot me.. just a question.. I will go hide now..

Regards,

Victor

---

From: [email-masked]
Date: Wed, 20 Oct 2010 20:09:53 -0400

> especially if they are content providers. The economic incentive in this

Brian, I am not sure I fully agree with you here. It might be true if 
2002::/16 is densely advertised, but if it is sparsely like it is now, 
announcing 2002::/16 will attrack return traffic from neighboring ASes. 

The resulting IPv4 traffic is very likely not destined to my own AS. If 
that traffic is through transit (paying) rather than peering (as in free), 

it means I'm actually paying *twice* to send it over my transit links, 
not counting the impact of the additional bandwitdth usage. 

Arguably, 6to4 traffic is not large enough to affect any large ISP's 
bottom line. But I'll have a hard time convincing my management to 
advertise a relay that cost us twice the usual transit fee. The 
"for the better good of the Internet" argument will probably not fly 
here. On the other side, local advertisement is easily justifiable. 

-> Flames here if I got my BGP-fu wrong... 

JF

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2010 13:27:55 +1300

> announcing 2002::/16 will attrack return traffic from neighboring ASes. 

I wouldn't advocate announcing it in BGP4, for that reason. Just announce
it in the ISP's IGP, for its own customers.

OK, this needs a draft, but that won't happen until after Beijing.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2010 13:31:22 +1300

John,

I agree. The 6to4 client will try to find a benevolent relay as close
as possible; if they fail to find one, they will never show up
as 6to4 users anyway. "Destination unreachable" for 192.88.99.1
would kill the problem at source.

Regards
   Brian Carpenter

---

From: [email-masked]
Date: Wed, 20 Oct 2010 20:57:27 -0400

> what I don't quite understand is why the focus on plan C for a 
presumably tiny 
> set of customers. when the big elephant in the room is the IPv4 only 
CPEs.

Ole, 

The larger elephant in the room might be the set of Windows 7 and 
Vista hosts connected to their provider directly behing a modem. Given 
a public IPv4 address and no v6, I understand these will do 6to4 by 
default 
(somebody correct me if this is no longer true). 

According to statistics heard at some point (can't find a reference now), 
directly connected users account for about 15 to 19% of users. Out of that 

percentage, roughly 30% are Win7 or Vista users 
(http://www.netmarketshare.com/os-market-share.aspx?qprid=11). 

Even if this is less than 5% of a provider's users, these hosts probably 
represent a much larger set than item 3 above. I know no sane ISP who 
would take the risk of having 5% of their clients call support because 
"Internet is slow" on the day google.com turns on AAAAs at large. This 
is why fixing 6to4 return path makes operational sense. 

<flame-suit-on>

JF

On a side note, I like your idea of redirecting HTTP 6to4 traffic to 
a page explaining how to disable it and to null-route the rest.

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Oct 2010 18:15:02 -0700

On 20 October 2010 17:57,  <[email-masked]> wrote:
>> what I don't quite understand is why the focus on plan C for a presumably
>> tiny
>> set of customers. when the big elephant in the room is the IPv4 only CPEs.
>
> Ole,
>
> a public IPv4 address and no v6, I understand these will do 6to4 by default

I don't know if these numbers are relevant to anybody but me, but
here's the latest:

    - of the clients in one of our experiments that connect to a
dualstack hostname, 0.2% (up from 0.04% 2 years ago!) connect with
native (or apparently native) IPv6, and an additional 0.1% connect
with 6to4.

Also, the extra contribution from 6to4 has been steadily dwindling:

    - 2 years ago 6to4 users were 3x as numerous as native.  Now
they're only half as numerous.

>From this I would conclude that 6to4 is steadily dwindling as a factor
(for dualstack HTTP destinations, etc etc, caveat caveat).  Of course,
someone else might drawn some other conclusion.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 20 Oct 2010 22:41:16 -0700

> with IPv6 only if IPv4-only access with unmanaged CPEs are used.

ipv4 unmanaged cpe which support 6to4 which it should be noted is a more
limited set of the total devices.

> CPEs for years and continue to do so. 

and they don't likely recently do 6to4 either.

> I am not buying them.. Customers are,

---

From: Gert Doering <[email-masked]>
Date: Thu, 21 Oct 2010 09:33:38 +0200

Hi,

On Wed, Oct 20, 2010 at 08:57:27PM -0400, [email-masked] wrote:
> default (somebody correct me if this is no longer true). 

True, but...

> is why fixing 6to4 return path makes operational sense. 

... Vista and Win7 will prefer IPv4 to 6to4.  So when connecting to 
dual-stacked hosts, they will not use IPv6.  No problem here.

6to4 will only be used connecting to IPv6-only hosts.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 21 Oct 2010 10:44:53 +0200

Hi,

> announcing 2002::/16 will attrack return traffic from neighboring ASes. 

So don't announce it to anyone but your paying customers.  Good return
connectivity for your native IPv6 servers --> 6to4 clients, no extra
cost.

Gert Doering
        -- NetMaster

---

From: Tore Anderson <[email-masked]>
Date: Thu, 21 Oct 2010 10:51:19 +0200

Brian, John,

* Brian E Carpenter

> The 6to4 client will try to find a benevolent relay as close as 
> possible; if they fail to find one, they will never show up as 6to4 
> users anyway. "Destination unreachable" for 192.88.99.1 would kill 
> the problem at source.

Null-routing the anycast address is counter-productive as it will not
prevent 6to4 implementations from setting up the tunnel interface, even
if the null-route produces ICMPv4 unreachables.  So you end up ensuring
that any application that attempts to use the 6to4 tunnel for
connectivity is blackholed.

This is true for Windows 7's default-on 6to4 adapter, at least.  Couple
this with software that prefers 6to4 to IPv4, such as Opera <10.50 or
Mac OS X (if Windows Internet Connection Sharing is active), and you've
just created another «broken user» and made it even more difficult than
it already is for content providers out there to get approval for
publishing quad As.  We _really_ don't need that...

It's much better, then, to let the user have a decent shot at using 6to4
successfully, even if that means the outbound traffic has to trampoline
off a third party relay somewhere.  The best would be if the SP has
relays on-net (like Comcast has), but if they don't it's actually much
better for the end users if there's as many open relays as possible
available.  That would improve the chances that the closest relay is
actually fairly close and won't cause the latencies to suffer too badly.

* John Brzozowksi

> From what we are seeing, operators should not announce their relays 
> publicly over IPv4.  Open 6to4 relays seem to yield undesirable 
> behavior.

The undesirable behaviour is really that 6to4 is being used as much as
it is and in preference to IPv4.  Unfortunately, that cat is out of the
bag.  Shutting down the open relays won't help, it will just worsen the
whole ordeal.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 21 Oct 2010 12:53:12 +0000

> publishing quad As.  We _really_ don't need that...
[jjmb] I concur with your points above.  Black-holing the 6to4 IPv4 anycast
is not recommended and will make matters worse.
> actually fairly close and won't cause the latencies to suffer too badly.
[jjmb] The point I would like to reinforce is that operators really should
seriously consider deploying their own 6to4 relays.
> bag.  Shutting down the open relays won't help, it will just worsen the
[jjmb] indeed, my main point here was to ensure that moving forward
operators deploy relays for use by their subscriber base and not announced
them openly.

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Oct 2010 08:19:36 +0200

> upgrade. This isn't easy for some operators which millions of unmanaged

It has always been very clear.
We all agree that one size doesn't fit all!

As you know, that' why some 6a44 should also be useful: to deal with CPE cannot be modified (without ignoring that it still needs OS-vendor support, and without pretending that it solves ALL problems ;-)).

Note also that I do agree that dual-sack routing with dual-stack CPEs, where it can be deployed quickly and at low cost, is the most obvious solution.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Oct 2010 10:21:59 +0200

Hi, Scott,

Le 20 oct. 2010 à 21:52, Scott Beuker a écrit :

> both improve upon a solution with flaws (6to4)

The problem I discuss is that it introduces in exchange a new flaw.
And unless I misunderstand, the cure is worse than the disease.

With 6to4-PMT (i.e. NAT66 added to 6to4), peer-to-peer applications will NO LONGER work. 
(They do work today between two 6to4 addresses  that have both good 6to4 relays on their way.)

> which will be utilized no
> matter what you say or do.

Each organization obviously makes its own decisions.
Yet, documenting that there is a problem can help to make the best decisions.
What I say is only said in view to enlighten the community.

> You can either have the better version, or

Exactly.
It's why breaking an "existing interior version" (6to4 in the present case) can create bad problems .

> past 2+ years.

Should I make the point again that 6rd and 6a44 are precisely designed for native IPv6 address deployments without hardware changes.

> This is sometimes how things go in the real world, and
> Blocking these improvements via this draft will not make 6to4 go away.
> I guarantee it.

If you are responsible for choosing deployed solutions somewhere, and if you have made your decision, no one, and certainly not me, will block you. 

But if you pollute 6to4 with NAT66, users should know it, and should probably prefer Teredo despite its limitations because, at least, it doesn't break IPv6 for P2P applications.

Note that it's clear to me that:
- 6to4 between TWO 6to4 addresses (its original purpose) does work without problem.
- This will remain true for your customers even after you have added NAT66 to your 6to4. 

To concluse:
- do you claim that 6to4 with NAT66 still permits P2P applications between 6to4 and native IPv6 addresses?
(If yes, and if you are right, I will acknowledge my mistake and present my apologies.)
- If P2P applications do become impossible between 6to4 and native IPv6, do you consider it a minor effect on future user experience?

RD

---

From: "Scott Beuker" <[email-masked]>
Date: Fri, 22 Oct 2010 08:08:38 -0600

Remi,

> (If yes, and if you are right, I will acknowledge my mistake and present

No, you are correct, but the trade off is thus: with 6to4-PMT a network operator can "guarantee" (as best is possible on the Internet) reachability to IPv6-only web sites. With regular 6to4, return traffic may have to pass through a third party network and service, who may be doing anything up to and including dropping it.

Now, comparing those two things to determine which is more desirable is debatable, but I want the network operator to be able to make that decision for themselves.

> - If P2P applications do become impossible between 6to4 and native IPv6,
> do you consider it a minor effect on future user experience?

Personally, looking at the user who will be utilizing 6to4, I see someone for whom ensuring basic IPv6-only content accessibility is more important. This user is likely unaware they're using 6to4, and simply want to be able to look up recipes for cookies or check their email. Even if they do dabble in P2P, i.e. torrents, they won't notice the missing IPv6 peers.

On the other hand, anyone savvy enough to notice will be more willing to buy a home gateway device that supports 6RD or native IPv6, depending on where we're at with deployment in their area. In fact this can be leveraged to motivate them to toss the old gateway and get one with proper IPv6 support.

The bottom line is that it's a tool in the toolbox I would like to have. The fact is, while I defend it as a viable option in certain circumstances, that doesn't necessarily mean I would end up deploying it. If all goes well, we'll never have to, and I continue to strive for that.

Thanks,
Scott

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 22 Oct 2010 10:13:17 -0400

Group,

May I propose an option here to help us understand the benefits and/or
confirmed drawbacks of PMT operation.

I can conduct a test within a live production network (limited scope/time)
and we can understand and verify how this would perform.

Would the group be open to this approach?  WE can have this coded on single
Linux platform (with 6to4) using the PF functions supporting IPv6 (as I have
been informed).

This is just a thought.

Regards,

Victor

On 22/10/10 10:08 AM, "Scott Beuker" <[email-masked]> wrote:

> No, you are correct, but the trade off is thus: with 6to4-PMT a network
> operator can "guarantee" (as best is possible on the Internet) reachability to
> IPv6-only web sites. With regular 6to4, return traffic may have to pass
> through a third party network and service, who may be doing anything up to and
> including dropping it.
> 
> Now, comparing those two things to determine which is more desirable is
> debatable, but I want the network operator to be able to make that decision
> for themselves.
> 
> Personally, looking at the user who will be utilizing 6to4, I see someone for
> whom ensuring basic IPv6-only content accessibility is more important. This
> user is likely unaware they're using 6to4, and simply want to be able to look
> up recipes for cookies or check their email. Even if they do dabble in P2P,
> i.e. torrents, they won't notice the missing IPv6 peers.
> 
> On the other hand, anyone savvy enough to notice will be more willing to buy a
> home gateway device that supports 6RD or native IPv6, depending on where we're
> at with deployment in their area. In fact this can be leveraged to motivate
> them to toss the old gateway and get one with proper IPv6 support.
> 
> The bottom line is that it's a tool in the toolbox I would like to have. The
> fact is, while I defend it as a viable option in certain circumstances, that
> doesn't necessarily mean I would end up deploying it. If all goes well, we'll
> never have to, and I continue to strive for that.
> 
> Thanks,
> Scott 
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Oct 2010 16:49:17 +0200

> assume most 6to4 users don't rely on e2e transparency.

How would SIP, Skype, games, etc., work in IPv6 with 6to4-PMT isn't clear to me.
Don't they require referrals? 

> Worst case it may require manual opt-out. This is still under discussion.

Opt in would be better IMHO, so that referrals still work by default.

Cheers,
RD

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Oct 2010 16:57:59 +0100

> Linux platform (with 6to4) using the PF functions supporting IPv6 (as I have

I think this is a first class idea.  Even if we don't have rough consensus,
running code would be a great start.

Nick

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Oct 2010 10:44:30 -0700

The impact on the routing table for longer than /16 is complete FUD. The
reality is that the RIRs are most likely to put 6rd into a separate prefix
from the normal provider allocation, so there will be an impact on routing
in any case. Yes there will be more prefixes for a longer than /16 approach
than for a parallel 6rd prefix block, but if you remove TE from the picture
the actual number is more like 3x the number of provider AS's to ignore the
broken one-liner in 3056. 

Everyone needs to stop finding reasons to inhibit progress, do what is
necessary, and move on. There will be systems that need to operate in
unmanaged environments, and their needs are completely different from those
that are managed. Stop trying to force everything into the managed bucket.
Fix 3056 to say that longer prefixes in 2002:: are an appropriate way for a
provider to start managing those unmanaged systems while they wean those
customers off the unmanaged technology. 

FWIW: I believe kuarsingh-v6ops-6to4-provider-managed-tunnel is a bad idea
because it is fundamentally a 66nat. The right thing to do is ignore 3056
and advertise the appropriate longer than /16 prefix to cause symmetric
traffic. This is not a long term solution, so a short term hit to the IPv6
routing table is not an issue.

Tony

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Victor Kuarsingh
> Sent: Wednesday, October 20, 2010 1:57 PM
> To: Mikael Abrahamsson
> Cc: IETF V6OPS WG

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 22 Oct 2010 13:59:35 -0400

Tony,

If there would be consensus on longer then /16s on 2002:: then the PMT model
operation is not needed.  It would provide the same level of "control"
without the need for PT66.

But, we (operators) need something that works with "deployed" software
features in deployed hardware (of which 6to4 is one of them - I like 6RD and
other technologies, but they are just not currently in many/most of the
equipment in production networks).

We (operators) just had the distinct impression that the rules set in 3056
(as I was informed the other day) were "firm" and not likely to be broken.
Brian noted the other day that 3056 was fitted with that text based on
"feedback" at that time.  Do you think this can be reversed / modified?  I
got the impression there is considerable negative support on this.

Regards,

Victor

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Oct 2010 21:04:34 +0200

Hi,

> got the impression there is considerable negative support on this.

One approach to rework 3056 would be to completely deprecate the 
6to4-with-anycast model.  Get the vendors to drop it from their
operating systems (at least as "default-on") - possibly adding new
rules that only 6to4<->6to4 traffic is allowed to use the 6to4 tunnels,
and that traffic destined to other IPv6 addresses MUST NOT be sent
with a source address of 2002::

So, yes, unreachability for "IPv4-only clients" to "IPv6-only servers".

If there's real interest to reach those servers, the clients will find
a way to get IPv6 - but it's unlikely that we'll see IPv6-only servers
any time soon.

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 22 Oct 2010 21:40:18 +0200 (CEST)

On Fri, 22 Oct 2010, Victor Kuarsingh wrote:

> We (operators) just had the distinct impression that the rules set in 
> 3056 (as I was informed the other day) were "firm" and not likely to be 
> broken. Brian noted the other day that 3056 was fitted with that text 
> based on "feedback" at that time.  Do you think this can be reversed / 
> modified?  I got the impression there is considerable negative support 
> on this.

I don't really know what you mean by "considerable negative support" in 
this context, but I don't know many people who seriously think importing 
the IPv4 table into IPv6 under 2002::/16 is a good idea.

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 10:29:12 +0200

Hi, Gert, 

+1, see below.

> with a source address of 2002::

Full agreement.
In practice, that's:
- deprecation of RFC 3068 (An Anycast Prefix for 6to4 Relay Routers)  
- modification of RFC 3056 (Connection of IPv6 Domains via IPv4 Clouds), to eliminate or at least complete with  the reference to 6to4 relays (or at least complete it with a serious warning):
This is restoring the original 6to4 model of tools.ietf.org/id/draft-ietf-ngtrans-6to4-00, which works just fine. 

Regards,
RD