Le 2012-03-28 à 04:31, Satoru Matsushima a écrit : > I do agree with Tetsuya-san's comments.
Answered separately. > 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. - Without checksum neutrality, the IPv4 payload has to be modified for the tunnel packet to be a valid IPv6 packet. This modification has to be made protocol per protocol. - RFC6145 says that CNP field wasn't needed because other address fields can be chosen to ensure checksum neutrality. the problem is that with stateless mapping rules, they cannot be chosen to ensure this. - CNP computation is really simple. Regards, RD > 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
