Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00)

[Rémi Després <[e-mail]>]

Le 21 oct. 2010 à 17:40, Armstrong, Bill R a écrit :

> This is it. 
> 
> I keep hearing "just offer Native" or "deploy -[insert unreleased\un-deployed transition technology here]-" as the way to side step this proposal\problem. But I think the fundamental fact being *consistently* overlooked by the opponents to the draft is that the hands of a good deal of the operators are tied by the currently deployed(+100K's) unmanaged(not the ISPs to touch) CPE.
> 
> If the fix offered up to "just enable Native" is "simply" replace ALL the CPE that are IPv6 incapable and\or offer firmware patches for the remaining gear then we may need to have larger discussion on economic realities. Stuff costs money, new stuff doubly so.

It is NOT "simply replace ALL the CPE that are IPv6 incapable".
Brian Carpenter, Sheng Jiang, and myself, propose a simple solution for native IPv6 across NAT44 CPEs i(draft-despres-softwire-6a44-00).  
Its limitation (strong at this point, but which may evolve as the specification gets well understood) is that it depends on an update in host software.
Host software upgrades appear to be unavoidable to achieve simple, efficient, and reliable, native IPv6 across legacy CPEs.


> We need to stop looking at this as an OR to SOLVE the IPv6 problem but rather view it as an AND (as seen in bANDaid) which can help foster the adoption of IPv6.

We all agree, I believe, that one size doesn't fit all.

The specific danger of NAT66/6to4 is that, being easy to implement and to operate, there is a temptation to deploy it.
But, if deployed, it breaks things that worked before.
In particular it breaks the possibility to advertise one's own 6to4 address and to be reachable at this address by IPv6 hosts that have access to a 6to4 relay.
(Besides, but this is less important, the amount of user experience that could be improved by a NAT66/6to4 deployment is unclear.) 


Regards, 
RD


> 
> 	
> 
> -Bill
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Scott Beuker
> Sent: Thursday, October 21, 2010 9:24 AM
> To: Rémi Després; v6ops
> Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00)
> 
> Remi,
> 
>> That is the point of adding clean solutions that are still missing.
>> (6a44, which Brian Carpenter, Sheng Jiang, and myself, are proposing is
>> precisely that. It provides a solution for hosts behind legacy CPEs, at
>> a cost of simple code to be added in host-OS's, and a simple add-on in
>> one or a few ISP border devices.)
> 
> Code to be added to host operating systems? So in other words, a totally unrealistic and still-born idea. You're at least 5 years too late my friend.
> 
> The time for idealism has come and gone. Drastic changes to the IPv6 transition landscape are no longer possible in a world where the customer purchases their own CPE devices and expects a decent few years use from them.
> 
> Here are the current realities:
> 
> 1) 6to4 is out there
> 2) 6to4 provides a safety net to IPv6-only content for an IPv4-only user
> 3) 6to4 doesn't impede native IPv6 deployment, nor is it a substitute for it
> 
> Deal with that and move forward; or at least, please stay out of the way of those of us who are trying to. 
> 
> Promotion of your own draft is not a reason to try to impede someone else's.
> 
> 
> 
>> 6rd concerns customer sites where CPEs can be updated, yes, but doesn't
>> need PE modifications (RFC 5569 and 5969))
>> 6a44 concerns hosts behind legacy CPEs, provided they can be upgraded,
>> but doesn't need PE modification either.
> 
> So in other words, both are totally irrelevant to this discussion. Neither addresses the use case that 6to4-PMT does. Please read the draft to better understand this.
> 
> 
> 
>> Not necessarily if taken with the appropriate tools (remember that it
>> took Free.fr only 5 weeks from "no intention to support IPv6" to "It's
>> deployed, our customers can turn it on").
> 
> Free.fr has control of the customer CPE. 6to4-PMT comes to relevance in a totally different situation.
> 
> 
> 
>>> I am forced to admit that at this stage, we need it.
>> 
>> I hope you will understand you are not forced at all.
> 
> Though it's always nice to have people ready and willing to tell other network operators, in totally different markets, cultures, and technical environments, what they must and must not do... at some point you have to step back and realize that your experiences are not necessarily universally applicable.
> 
> Thanks,
> Scott
> _______________________________________________
> v6ops mailing list
> [e-mail]
> 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.
> 
> 
> 
> 
> 
> 
> 
>