On 2012/03/28, at 10:59, Rémi Després wrote: >> 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.
My understanding is that 4rd-u focus only on between v4 hosts, a packet looks like invalid IPv6 packet doesn't matter. > - 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. Above my understanding, 4rd-u doesn't need to follow rfc6145 spec, because during the meeting, you said that 4rd-u is a brand new transport protocol. > - CNP computation is really simple. > Without CNP is much more simple. cheers, --satoru > 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
