Le 2012-03-28 à 11:06, Satoru Matsushima a écrit : > 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.
It does matter where some IPv6-only middle boxes do DPI (a point that justifies to standardize also T if E is standardized instead of U) >> - 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. Right. 4rd-U doesn't follow RFC6145. This point is just to emphasize that reasons that led to no CNP in RFC6145 don't apply to 4rd-U (no contradiction). >> - CNP computation is really simple. >> > > Without CNP is much more simple. Of course, not supporting a feature is simpler than supporting it, even if it is simple, but the benefit of this feature is then lost (in this instance, benefit is one standard behavior instead of two). Regards, RD > > 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
