|
»
« Return to Thread: 4rd-U informal meeting - Tuesday 15:15 Room 204
Re: 4rd-U informal meeting - Tuesday 15:15 Room 204
by Tetsuya Murakami
::
Rate this Message:
In terms of CNP, CNP needs to be calculated every time if the packet is toward to outside of domain because the embedded IPv4 address could be different. So, I think there is no difference between CNP and recalculation of L4 checksum from the implementation point of view.
Thanks,
Tetsuya Murakami
On 2012/03/27, at 19:31, Satoru Matsushima wrote:
> 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
Thanks,
Tetsuya Murakami
On 2012/03/27, at 19:31, Satoru Matsushima wrote:
> 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
« Return to Thread: 4rd-U informal meeting - Tuesday 15:15 Room 204
| Free embeddable forum powered by Nabble | Forum Help |
