Re: [Softwires] 4rd-U complement - e2e transparency to IPv4 TOS

[Mark Townsley <[e-mail]>]

On Oct 18, 2011, at 4:31 PM, Rémi Després wrote:

> 
> Le 18 oct. 2011 à 15:35, Mark Townsley a écrit :
>> On Oct 18, 2011, at 2:31 PM, Rémi Després wrote:
> ...
> 
>>> I do understand the inconvenience of having to adapt running codes based on encapsulation to a header mapping such as that of 4rd-U. 
>>> However, I have no doubt that this is technically easy.
>>> That's AFAIK the price to be paid to get a unique standard, with the nice bonus that existing IPv6-ACL tools, which weren't usable with encapsulation, become usable. 
> ...
> 
>> Bravo, your ingenuity has led you to something that lies perfectly in the middle of the two warring parties. The problem of course is that the solution has the full advantages of neither side,
> 
> It's not because a design has positive features of two other designs that it "lies in the middle".
> 
> Could you explain the important advantage of encapsulation that is missing in 4rd-U?

It's been specified and implemented for years, it is part of other softwires specifications, it is being implemented in CPE equipment today as part of ds-lite, it doesn't put payloads on the wire with mis-matching checksums.... Sure, tunneling doesn't play nice with some ACLs that only look at native IPv6, but at least this is a very well-understood attribute of tunneling that operators expect and in many cases are able to design around. FWIW, my crystal ball says that these limitations will will become less and less relevant if and when 4-in-6 operation becomes more and more prevalent, but that's just me.

Translation based on what's already defined in the behave WG is less conservative than simple encapsulation, but at least it is building on something that already exists, is well-specified and deployed, etc. We can expect to see IPv4 payloads with IPv6 headers on the network because of translators, but at least the checksums will be correct and there is a decent chance that a host will be able to digest the packet and get it to a working application after passing through one level of translation (or being redirected, subjected to DPI, etc). 

Again, no offense at all to the ingenuity of -U, but I simply have a hard time justifying that we need to cast a balance between these relatively well-known, specified, and implemented building-blocks with something new. 

If I believed for a microsecond that -U would wipe both encapsulation and translation from the planet so that we would have only one mechanism here, I would be more supportive. The problem is that the other two already exist in other closely related contexts such that there is no way that this doesn't become a 3rd method in the network without turning back time itself.

- Mark

> 
> 
> RD
> 
>