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

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

Thanks, Mark, for the quick and detailed response.
More below.

Le 18 oct. 2011 à 11:07, Mark Townsley a écrit :

> 
> On Oct 18, 2011, at 10:38 AM, Rémi Després wrote:
> 
>> 
>> Le 18 oct. 2011 à 10:21, Mark Townsley a écrit :
>> 
>>> 
>>> While it is interesting to explore the various design spaces, we do not need more ways to munge an IPv4 packet into an IPv6 packet and back to an IPv4 packet. Any alternative beyond the simple and obvious encap/decap that routers have used for decades is already too much IMHO, we certainly don't need a 3rd or 4th method.
>> 
>>> Let's please curtail new the inventions, and get back to the standardization.
>> 
>> Sorry that you see it that way.
>> 
>> The interim meeting has been useful in that objectives of present parties were clarified better than ever before.
>> Standardization is, and has always been, a process in which understanding each other, and finding ways to accommodate all valid concerns, are been key to success.
>> That's what I have been working for: good standardization. 
>> 
>> Would you please indicate what you personally challenge in this:
>> a) One standard is better than two.
> 
> Yes. 

Clearly an important point for this discussion.


>> b) Maintaining network transparency to IPv4 packets is a useful feature
>> c) Being able to apply IPv6 O&M tools to IPv4 traffic, e.g. with ACLs, is a useful feature
>> d) Encapsulation has b) but not c)
>> e) Double translation has c) but not b)
>> f) 4rd-U has both b) and c)
> 
> IPv6 packets with incorrect checksums may be incompatible with firewalls, website redirects (e.g. I don't see why the web server will not just drop the packet if the checksum fails), etc. 

Thanks for rising the website-redirect issue.
With 4rd-U, some functions that exploit IPv6 packets above the A+P layer are not readily possible, but:
- Some other important functions, like ACLs, are readily made possible with existing tools.
- Complementing web redirectors so that they recognize 4rd addresses and adapt their checksum processing isn't technically difficult. It can be done later on.
- With encapsulation, web redirectors need a CE-like decapsulation function before processing IPv4 packets. The same can be done with 4rd-U, with decapsulation replaced by the v6-to-v4 header mapping. 


> The translation (or header mapping) cases all purport to be helpful to various processing or operations along the path between the router endpoints. By definition, it is more complicated to weigh relative value of the various options in this space as we have to start weaving our way through sometimes unknown and certainly non-standard DPI, ACL, redirection, O&M, etc. features at multiple places in the network.

Each ISP will decide which functions it can use, depending on its deployed tools, as it does for encapsulation.
  

> In some cases, I'm afraid that we are optimizing based on speculative properties of IPv6 networks that are still in their infancy in terms of mainstream deployment.

> Experience tells me convergence here will be difficult, and getting it right will be even more difficult. 

In the particular instance of 4rd-U, I don't see that, because its consequences are easily understood.
If I may, it's somewhat like 6rd whose implications were quickly understood by Free, in less than one hour, because the specification is short and self contained.
(This is unlike double translation, which depends on the the sophisticated RFC 6145, and on its operational variants to configured.)


> I think we need to get the base case of stateless encap/decap out the door so that it can be built into CPE alongside the stateful ds-lite encap/decap option that is being built already.

That's a respectable view, but one that, IMHO, would lead to a missed opportunity to have a single standard.

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. 

> Then we can continue in the search for the best translation method (which, if we are still coming up with new clever alternatives right now, we are not converging nearly as fast as we might think we are).

It is clear, I hope, that 4rd-U is NOT a double translation technique between IPv4 and IPv6 packets. 
It is a simple header mapping technique that, like encapsulation, preserves network transparency to IPv4 packets across IPv6 domains.

Regards,
RD