Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

[Keith Moore <[e-mail]>]

On Jul 3, 2011, at 3:17 PM, Arturo Servin wrote:
>>> 
>>> 	And b.
>>> 
>>> 	And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here).
>> 
>> It's clearly inappropriate for operators to be filtering protocol 41.   Not only does this break 6to4, it also breaks other tunneling mechanisms.  More generally, it's inappropriate for operators to be favoring one kind of traffic over another.
> 
> 	Many corporate networks filter them because security concerns (I am not saying that is right or wrong, it just happens and it breaks 6to4). They won't change their mind because 6to4.

Fair enough.  (It bothers me when ISPs filter them, but I consider it within the rights of an enterprise network to do that.  What an enterprise does with its own traffic should be its own business, and they can benefit and/or suffer from the consequences of their choices.  Though I do think that there are probably better ways to handle the (legitimate) security concerns than to merely filter protocol 41.  e.g. ICMP unreachable.)

And of course protocol 41 becomes problematic for those behind a NAT of any kind, including LSN.    (I do see LSN as "best effort" delivery; it's just that the state of the the network has made "best" pretty sad these days.)

So if we were able to omit or finesse considerations (b) and (c) could we get consensus around the remaining items in that list?

>> The ISPs I've talked to tell me that they see no reason why static, public IPv4 addresses cannot continue to be given to those that request them, indefinitely, as long as they're paying for business service. 
> 
> 	Call one not in the USA. China or India perhaps.

I'll take your word for it.   6to4 is only going to work in corner cases, and those corners are somewhat defined by geography.

Honestly I'd be happy to declare 6to4 Historic if we had a suitable replacement - one that could be automatically configured by hosts, used by applications, and worked better than 6to4 in most cases.  I don't think it exists yet.  

(That oft-touted 80% reliability figure needs to be compared with similar figures for other methods, along with the realization that manual configuration, lack of platform support,  congestion at heavily-used tunnel endpoints, are all significant sources of failure.  Note that you can't measure this by looking only at traffic in the network.   And for those who insist that all v6 traffic should be native, note that from the perspective of an application developer, there is close to a 0% reliability for this at present.  80% is a huge improvement over that, though still not good enough.)

Keith