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
>>
Softwires@...
>>
https://www.ietf.org/mailman/listinfo/softwires>>
>
> _______________________________________________
> Softwires mailing list
>
Softwires@...
>
https://www.ietf.org/mailman/listinfo/softwires_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires