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
