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

[Behcet Sarikaya <[e-mail]>]

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
>