In terms of CNP, CNP needs to be calculated every time if the packet is toward to outside of domain because the embedded IPv4 address could be different. So, I think there is no difference between CNP and recalculation of L4 checksum from the implementation point of view.
Thanks, Tetsuya Murakami On 2012/03/27, at 19:31, Satoru Matsushima wrote: > I do agree with Tetsuya-san's comments. On the other hand, I couldn't > understand the reason of why the CNP is needed. Since 4rd-u focus on support > to communicate between ipv4 hosts, L4 checksum consistency could be agnostic > from any kind of 4rd-u nodes. So then I suggest that remove checksum > neutrality function from the document. > > cheers, > --satoru > > > On 2012/03/28, at 0:42, Tetsuya Murakami wrote: > >> Hi Remi, >> >> Thank you for having the informational meeting of 4rd-u. I can understand >> 4rd-u very much. >> >> As you mentioned during the informational meeting, 4rd-u defines the new >> type of the translation between IPv4 and IPv6 instead of MAP-E/MAP-T. Also, >> this new type of the translation has no relationship with the mapping rule. >> Hence, I think 4rd-u draft can be changed only to define the new type of the >> translation similar to MAP-E/MAP-T by removing any text related to mapping >> rule and refer to MAP for the mapping rule. In this case, it depends on >> deployment scenario to choose MAP-E, MAP-T or 4rd-u. >> >> Also, as I mentioned during the meeting, I double-checked the current >> implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6 stack >> gives received IPv6 packet to 4rd-u module after processing it. But, >> according to the current implementation of IPv6 stack, IPv6 stack totally >> removes IPv6 fragment header when IPv6 stack finds IPv6 fragment header and >> processes it. >> >> Since 4rd-u module gets the packet after IPv6 stack processes the packet, >> IPv6 fragment header is not present when 4rd-u module gets the packet. 4rd-u >> utilizes IPv6 fragment header to carry some of IPv4 information. But all >> information embedded in IPv6 fragment header is disappeared in IPv6 stack >> before 4rd-u module gets the packet. Hence, in order to keep/pass the >> information embedded in IPv6 fragment header to 4rd-u module, I think the >> existing IPv6 stack needs to be changed. >> >> In terms of MAP-T, IPv6 fragment header is also required but no information >> is embedded in IPv6 fragment header. Also, the current IPv6 implementation >> can give only information if there is a fragment header or not. So, MAP-T >> can know if there is a fragment header or not after IPv6 stack processes the >> packet without any change of the existing IPv6 stack. >> >> I think MAP/4rd-u are transition technology and so it is good to eliminate >> any impact on the existing implementation of IPv6 stack as much as possible. >> >> Thanks, >> Tetsuya Murakami >> >> On 2012/03/26, at 11:57, Rémi Després wrote: >> >>> Hi, all, >>> >>> With some co-authors of the 4rd-U proposal, we will hold an informal >>> meeting about it. >>> - subject: Clarification on what 4rd-U is designed to do, and how it does >>> it. >>> - Participants: whoever is interested in a good understanding of the 4rd-U >>> proposal. >>> - place: room 204 >>> - time : Tuesday 15:15 (duration depending on questions, maximum till >>> 16:30). >>> >>> The meeting can be seen as a bar BOF... without drinks in the room. >>> >>> See you there if interested, >>> RD" >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
