Hi Gang,
Thanks for your reply. Please see in lines.
Regards!
Jiang Dong
Tsinghua University
2012-03-28
From: GangChen
Date: 2012-03-28 00:30
To: jiangdong345
CC: Kevin Y; Softwires WG
Subject: Re: [Softwires]Path to move forward with 4rdŠ
2012/3/27, Jiang Dong <[email protected]>:
> Hi Gang and all,
>
> I think there are some points need to be considered between MAP series and
> 4rd-U.
>
> 4rd-U saids "IPv4 headers can be reversibly mapped into IPv6 headers so that
> 4rd tunnel packets can be designed to be valid IPv6 packets" in Section I.
> In my understanding, the difference between 4rd-u and MAP-E is "IPv6
> fragment header vs IPv4 header". Both 4rd-U and MAP-E can keep the
> transparency, while 4rd-U reserves 12 bytes to improve the efficiency and
> MAT-E has some IPv4 redundancy octets but keep the original IP-IP
> encapsulation which is easy to be operated.
>
> Comparing with MAP-E, 4rd-U keeps the DF bit, TOS and so on with an
> additional IPv6 fragment header, which incurs reusing IPv6 option 44.
>
> If 4rd-U can be considered as a tunneling technique, the question is: does
> it deserve adding the IPv6 fragment header in order to save 12 bytes
> efficiency each packet?
Not just bits saving, but also capable of indentification with IPv6
address. Please see more detailed at
draft-despres-softwire-stateless-analysis-tool-01
> If 4rd-U can be considered as a translation technique, the question is: does
> it deserve adding the IPv6 fragment header in order to keep transparency?
See above draft to get more information on comparision. BTW,
fragmentation header is in common for MAP-T and 4rd-U.
[DJ] Thanks, I have read the comparison draft. With the fragmentation header
4rd-U can keep its transparency but MAP-T cannot, so I think the use of
fragmentation header are not the same for MAP-T and 4rd-U, and some compromises
may have to be considered.
BRs
Gang
>
> From: GangChen
> Date: 2012-03-27 15:53
> To: Kevin Y
> CC: Softwires WG
> Subject: Re: [Softwires]Path to move forward with 4rdŠ
> Hello Kevin and all,
>
> I actually see current multiple solution proposal from different
> angle. Regarding the changes you mentioned, MAP-T/E is also doing
> that, e.g. added fragmentation header to survive DF bit; change ICMP
> ID filed to carry the port information.
>
> 4rd-U doesn't beat MAP-series. I prefer to understand the situation is
> 4rd-U raised some points(e.g. CNP, Fully IPv4 transparency) which is
> desirable heading to a perfect protocol design.
>
> BRs
>
> Gang
>
> 2012/3/27, Kevin Y <[email protected]>:
>> Hi, Remi,
>>
>> This is beyond the charter of softwire WG, changing IPv6 address format
>> needs much broad discussion in IETF community to understand its impact
>> first, before we should even discuss if it is valid to design something
>> like this in softwire. Have you done that ?
>>
>> Best Regards,
>>
>> Kevin Yin
>>
>> On Thu, Mar 22, 2012 at 10:04 PM, Guanghui Yu <[email protected]>
>> wrote:
>>
>>> Hi Yiu
>>>
>>> 4rd-u changes the IPv6 header architecture (redefine
>>> fragmentation header extension) and IPv6 address architecture (different
>>> meaning of u-bit when g-bit=1). These are the fundamental changes. If
>>> 4rd-u
>>> becomes the standard, then there will be new defined 揑Pv6?packets on
>>> the Internet, which are not compatible with existing IPv6 packets and
>>> no existing devices can understand those packets.
>>>
>>>
>>> Yu Guanghui <ygh at dlut.edu.cn>
>>> Network and Information Center
>>> Dalian University of Technology, China
>>>
>>>
>>> On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu
>>> <[email protected]>wrote:
>>>
>>>> Hi Guanghui,
>>>>
>>>> I agree that both MAP and 4rd-u are similar technology and solving the
>>>> same problem. From technical perspective, can you elaborate this a
>>>> lithe
>>>> bit?
>>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> From: Guanghui Yu <[email protected]>
>>>> Date: Thu, 22 Mar 2012 20:26:40 +0800
>>>> To: Softwires WG <[email protected]>
>>>> Subject: Re: [Softwires] Path to move forward with 4rd?
>>>>
>>>> I read 4rd-u draft and found it is flawed.
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
