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

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

Le 28 oct. 2010 à 04:14, Victor Kuarsingh a écrit :

> Remi,
> 
> I do appreciate the points from the group.  I agree, IPv6 native =
> good/best.  I also agree, where I cannot have Native IPv6, we will provide a
> more managed solution (like 6RD).

Note that a useful distinction here is between native-IPv6 ROUTING and native-IPv6 ADDRESSES.
6rd does provide native-IPv6 ADDRESSES to customers (unlike 5to4 and Teredo).
This is because users can't even detect that their IPv6 packets traverse some IPv4-only routing domain via tunnels.  


> But unfortunately, neither of these options help operators where there are
> "unmanaged" devices which are not yet upgraded to support such technologies.
> Believe it or not, many persons do not ever upgrade their firmware in their
> home gateways)

Not only I do believe it, but its is precisely why, with Brian and Sheng, we propose 6a44 (www.ietf.org/id/draft-despres-softwire-6a44-01).
- It offers to native-IPv6 addresses to 6a44-capable hosts that are behind NAT44-CPEs.
- It is plug and play.
- Traffic between two hosts behind the same NAT44-CPE remains within their site.
- It can work even in sites that only get private IPv4 addresses of RFC 1918. 
  
> Operators need an option to help customers who have not yet replaced
> equipment which has a "current set" of features (and as noted, this often
> includes 6to4 default operation).

That's why current 6to4 users shouldn't lose the ability to be reached at their 6to4 address, including by hosts that have native-Ipv6 addresses and routes via 6to4 relays.
Adding a NAT66 to 6to4 relays breaks this ability.
This technical reality MUST NOT be ignored.  

> ... But, many
> operators have commented on this list that the reality in our networks is
> that we cannot control all our CPE endpoints, and replacing them is many
> times out of our control.

Indeed, and 6a44 has been designed for them.
(We have to face that many existing CPEs don't support 6to4.) 

> It appears that that a number of commenter's in this list would rather us
> (operators) not address this segment of the population, and just "hope" that
> IPv4 only will work for them

I noticed that too, and believe they don't understand the situation.

All my personal efforts, from 6rd to 6a44, and including opposition to endorsing the NAT66-6to4 combination, are to promote good user experience with IPv6.


> I offer this question to the list, what "option" is available for the
> "non-upgraded" and "IPv4 only" endpoints?

If neither the host not the CPE is upgraded, the host is left with IPv4-only and NAT44's, with their limitations.


> Would the group agree with this statement "we would rather provide no IPv6
> at all rather then IPv6 based on 6to4-PMT"?

That's a strange question because adding NAT66 to 6to4 doesn't increase the number of IPv6 addresses offered to customers.
It just modifies what a host can do with its IPv6 address:
(a) It ensures a return path for connections from 6to4 to native IPv6 
(b) It breaks the possibility to be reachable at this IPv6 address.

It has to be faced that (b) would be a terrible step backward for 6to4 (and for IPv6 in general).
(See what James Woodyatt, among the well-known best friends of 6to4, says about it.)  


> Constructive options welcome.  


6a44 is a constructive option.
(Reactions to the proposal are most welcome.)

Destructive proposals are legitimate only as long as it isn't clear that they are destructive.
And it happens (unfortunately I agree) that adding NAT66 to 6to4 IS destructive 


Regards,
RD

Red




> I am not trying to be difficult or
> belligerent, but rather looking for solutions to problems.
> 
> Regards,
> 
> Victor
> 
> 
> 
> On 25/10/10 3:35 AM, "Rémi Després" <[e-mail]> wrote:
> 
>> 
>> Le 23 oct. 2010 à 17:55, Victor Kuarsingh a écrit :
>>> ...
>>> Why would we depreciate something that works before all the viable
>>> alternatives (6RD, Native IPv6 and new things like 6a44) are still not out
>>> there in mass?  Why reduce that IPv6 glue space?
>>> ...
>>> My analogy to Internet usage for most is like "gas in the car".  Most people
>>> put gas in the card, turn the key and press the accelerator/break.  All the
>>> rest "just works".
>> 
>>> Our mission (as operators) will be to make things "just
>>> work".
>> 
>> Agreed, what is needed is what "just works".
>> 
>> Now:
>> * Native IPv6 "just works"
>> 1. guaranteed e2e address transparency (OK for peer-to-peer)
>> 2. guaranteed connectivity
>> 3. ISP control of customer QoS
>> * 6to4 between two 6to4 addresses (without 6o4 relays) "just works":
>> 1. guaranteed e2e address transparency
>> 2. guaranteed connectivity
>> 3. ISP control of customer QoS (that of IPv4)
>> * 6to4 between a 6to4 address and a native-IPv6 address (with 2 6to4 relays)
>> "doesn't just work":
>> 1. (e2e address transparency still available)
>> 2. guaranteed connectivity is LOST
>> 3. ISP control of customer QoS is LOST
>> 
>> If SOME ISPs would deploy 6to4-PMT, i.e. add NAT66's to 6to4 relays, 6to4
>> would EVEN LESS "just work":
>> - For 6to4 customers of 6to4-PMT ISPs:
>> 1. e2e address transparency is LOST (peer-to-peer in Ipv6 is broken)
>> 2. guaranteed connectivity is still LOST  (depends on whether remote
>> native-IPv6 hosts access 6to4 relays)
>> 3. ISP control of customer QoS is still LOST (if remote native-IPv6 hosts
>> have access to 6to4 relays, it depends on which ones)
>> - For native IPv6 customers
>> 1. guaranteed e2e address transparency is LOST (remote native IPv6 addresses
>> may now be translated on their way)
>> 2. guaranteed connectivity with 6to4 addresses is still LOST (not all 6to4
>> addresses are 6to4-PMT addresses)
>> 3. ISP control of customer QoS is still LOST (not all 6to4 addresses are
>> 6to4-PMT addresses)
>> - For 6to4 customers of ISPs that haven't 6to4-PMT:
>> 1. e2e address transparency is LOST (they may be talking to 6to4-PMT
>> customers)
>> 2. guaranteed connectivity is still LOST (they may have no access to a 6to4
>> relay)
>> 3. ISP control of customer QoS is LOST (if they access some 6to4 relays, it
>> depends on which ones)
>> 
>> 6to4-PMT is simple, a quality, but, by combining two mechanisms that already
>> create more problems than they solve (6to4 relays and NAT66), it can only lead
>> to poor user experience in IPv6.
>> 
>> The technical content of the above can be challenged if one finds that is has
>> mistakes.
>> But if it is right, the conclusion is that, to only keep solutions that "just
>> work", using the 6to4 anycast address in 6to4 customers should be turned off,
>> at least by default, and that where 6to4 relays are still in use, no NAT66 of
>> any form should be added to them.
>> 
>> 
>>> Plus, depreciating it would take time since it hard to force customers to
>>> upgrade OSs (although this has become automated in most OSs) and consumer
>>> equipment (many customers do not upgrade past store rev firmware).
>> 
>> Deprecating a spec only means "if you have the choice, no longer do it".
>> In my understanding, deprecating 6to4-anycast in customer devices doesn't mean
>> that 6to4 relays that exist today should be dismantled.
>> As long as operators of these relays don't offer native IPv6, and see that
>> they still have users, they are perfectly entitled to maintain these relays
>> for these users.
>> 
>> 
>> To conclude, the proposal is that IETF:
>> - deprecates the use of the 6to4-relay anycast address in 6to4 routers
>> - explains why associating NAT66's with 6to4 relays should be avoided
>> This will contribute to make IPv6 something that "just works".
>> 
>> Regards,
>> RD
>> 
>> 
>>> 
>>> Just a thought.
>>> 
>>> Regards,
>>> 
>>> Victor
>>> 
>>> 
>>> On 23/10/10 5:20 AM, "Gert Doering" <[e-mail]> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> On Sat, Oct 23, 2010 at 09:15:38AM +1300, Brian E Carpenter wrote:
>>>>> On 2010-10-23 08:04, Gert Doering wrote:
>>>>> 
>>>>>> One approach to rework 3056 would be to completely deprecate the
>>>>>> 6to4-with-anycast model.
>>>>> 
>>>>> That is to say, deprecate RFC 3068 and revert to the pure RFC 3056 model.
>>>> 
>>>> Well, yes.  Sorry for mixing these RFCs.
>>>> 
>>>>> Good idea. Could you push my toothpaste back into the tube, too, please ;-)
>>>> 
>>>> Well, it's not like we haven't done this before.  A6/bitstring depreciation
>>>> comes to mind...
>>>> 
>>>> Gert Doering
>>>>       -- NetMaster
>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
> 
>