I remember that what Remi said during the meeting, is that 4rd-u is a brand-new 
transport protocol which doesn't need to follow rfc6145 translation spec. If it 
is true, 4rd-u doesn't need to take care checksum consistency of any kind of L4 
protocols.
On the other word, 4rd-u can support transparency of original packet so not 
only the CNP, but also checksum recalculation are not required.

cheers,
--satoru


On 2012/03/28, at 11:02, Simon Perreault wrote:

> On 03/28/12 10:48, Satoru Matsushima wrote:
>>> On the contrary, there is a big difference. The difference is that you are 
>>> only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, 
>>> etc, etc. You need a lot of code to handle all existing transport 
>>> protocols, and you still can't handle future protocols that people might 
>>> develop.
>>> 
>>> Checksum neutrality is a *big* advantage.
>> 
>> Cool. How many protocols we should support for just a *transition* mechanism?
> 
> The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a 
> longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep 
> providing clients with residual IPv4 for a potentially loooooooooooong time. 
> So we need to be really careful to get this right, because we'll be stuck 
> with what we design for a long time.
> 
> So you have two options:
> 
> a) checksum neutrality
>   - no code specific to each transport prototol
>   - supports all current and future transport protocols
> b) checksum non-neutrality
>   - additional code necessary for each transport protocol
>   - limited set of supported transport protocols
> 
> Less code, more transport protocols. I think the choice is easy.
> 
> There's a reason NPTv6 and NAT64 chose checksum neutrality...
> 
> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to