Re: [Softwires] Standardizing "4rd-U" vs "4rd-Encapsulation AND Double translation - analysis

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

Hi Behcet,

Thank you for your interest in understanding 4rd-U.

- The draft is informational because it is, at this stage, just a design proposal. The expectation is that it will eventually be included in a standard-track document whose form has to be decided in the WG.

- Despite my current attempt to spend less time for IETF, I will try to have soon a -01.
It will incorporate what I see as significant improvements resulting from the WG debate:
  . TOS copied in the IPv6 fragment header (pipe & short-pipe compatibility) 
  . Use of a checksum-neutral IPv6 addresses (compatibility with web redirection in IPv6 domains)  

Regards,
RD


Le 19 oct. 2011 à 22:05, Behcet Sarikaya a écrit :

> I would like to see more details on 4rd-u before. Why is it informational? A -01 would help.
> 
> Regards,
> 
> Behcet
> 
> On Wed, Oct 19, 2011 at 3:07 AM, Rémi Després <[e-mail]> wrote:
> Mark,
> More on this debate below.
> 
> Le 18 oct. 2011 à 19:44, Mark Townsley a écrit :
> > On Oct 18, 2011, at 4:31 PM, Rémi Després wrote:
> ...
> >> 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.
> 
> Successfully deployed in production, not so sure. (Even IPv6 isn't that largely deployed today).
> In any case, it has the side effect that it damages network transparency to IPv4 packets.
> 
> > We can expect to see IPv4 payloads with IPv6 headers on the network because of translators, but at least the checksums will be correct
> 
> For ISP networks where web redirection with existing IPv6 tools is needed, 4rd-U could be completed so that checksums are correct.
> This can be done like in dIVI by checksum adjustments at IPv6-domain entrance and exit, or (better IMHO) by revising the unified address-mapping to make it checksum neutral (something Ole has in my understanding suggested).
> 
> Thanks for pointing out that something was missing to get the best of both worlds.
> 
> > 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.
> 
> New, yes, but quite simple, and with an immediate operational advantage.
> 
> > 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.
> 
> Assuming that the three solutions would be available in products, I don't see why an ISP would prefer to keep double translation or encapsulation:
> - The fact that translations and encapsulations were first to exist IS NOT an operational advantage
> - Having both of network transparency to IPv4 AND applicability of IPv6 O&M tools IS an operational advantage.
> 
> I still hope that, with more thoughts on the subject, you can become more open.
> 
> Regards,
> RD
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>