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

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

Olde,

Thanks for the quick answer.
More below.

Le 18 oct. 2011 à 09:42, Ole Troan a écrit :

> Remi,
> 
>> Let me now ask whether you challenge any of the following:
>> a) One standard is better than two.
>> 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
> 
> I think we need to detail this point more:
> 
> c1) apply IPv6 features on the traffic as if it is IPv6. use of 5 tuple etc.
> c2) apply IPv4 features on the traffic as if it is IPv4.
> c3) be able to redirect traffic or communicate with native IPv6 only hosts. e.g. web cache, web authentication
> 
> if this is useful or not, depends on your world view...

I see that, but aren't solutions that are compatible with both world views better than those that satisfy only one?

 
> traditionally the whole purpose of a tunnel was to bypass devices in the middle mingling with your packets.
> 
> _iff_ one wishes that a "legacy" router in the middle of the traffic path should be able to apply features and classifiers
> based on 5 tuple, then translation supports c1 and c3.
> encapsulation supports none.
> what I hear on the list is that one don't want to treat this as IPv6 traffic, but want to be able to identify it as IPv4 traffic. and presumably apply IPv4 features and classifiers on that traffic.

> if that's the case, you need to modify the box in the middle anyway,

The point is that you only need to configure the box, without depending on a new product release that hasn't been announced yet.
I think promoters of double translation made clearly this point, and it is AFAIK a valid one.
  
> and I would claim it is a lot easier to move a pointer 40 bytes, than to recreate the IPv4 header on the fly.

Recreating an IPv4 header at domain exit isn't a big deal. IMHO, since it is the key to combine valuable features of both double translation and encapsulation, and to thus have a single standard, it is worth doing.
   

>> d) Encapsulation has b) but not c)
>> e) Double translation has c) but not b)
>> f) 4rd-U has both b) and c)
> 
> I disagree. double translation has just as much of b) as 4rd-U has.

In clear, you claim that 4rd-U isn't more transparent to IPv4 than double translation! 
With its DF+TOS copied in the IPv6 fragment header, 4rd-U is fully transparent to the TOS and the DF bit of IPv4, which isn't always the case with double translation.
Could you explain your understanding?

> but I will claim that double translation offers less
> transparency than encapsulation.

Indeed (and less than 4rd-U by the same token, see above).


>> - If you challenge one or several of these, our debate can continue on well identified subjects.
>> - If you don't challenge any of a) to f), we are IMHO on the right track to make progress.
>> 
>> Please do answer these questions so that questions you ask me can be answered in a clarified context.
> 
> in my view this doesn't change the encapsulation versus translation debate.
> would an option be to merge your ideas with the new dIVI-pd document that will reference the new mapping document?

It is up to you, as leader of the unified-format effort, to see how you would like documents to be merged and/or re-written.

My own understanding is that:
- a unified address mapping is possible, e.g. by modifying the 4rd-addmapping to incorporate the proposed format with the V octet.
- a unified header format is also possible, based on 4rd-U which has been designed for that. 

I hope others will express their view on this.

Cheers,
RD



> cheers,
> Ole
>