Re: [Softwires] 4rd-U complement - e2e transparency to IPv4 TOS

[Rémi Després <[e-mail]>]

Le 17 oct. 2011 à 18:15, Ole Troan a écrit :

> Remi,
> 
> how is 4rd-U different from translation?

Functionally, full network transparency to DF bit (and TOS with the complement that was missing).
Technically, see for instance Figure 1 of the draft.

Cheers,
RD  


> 
> cheers,
> Ole
> 
> 
> On Oct 17, 2011, at 18:09 , Rémi Després wrote:
> 
>> 
>> Le 17 oct. 2011 à 17:27, Satoru Matsushima a écrit :
>> 
>>> On 2011/10/17, at 23:46, Maoke wrote:
>>> 
>>>> hi Satoru-san,
>>>> 
>>>> 2011/10/17 Satoru Matsushima <[e-mail]>
>>>> Hi Maoke-san,
>>>> 
>>>> On 2011/10/17, at 22:30, Maoke wrote:
>>>> 
>>>>> hi Satoru-san,
>>>>> 
>>>>> may i understand that, as Remi's proposal is applied for the double translation case, TTL being translated to IPv6 Hop Limit is enough? as is stated in RFC6145, translator is a "router" and therefore the behavior should not be as same as the virtual link. right?
>>>> 
>>>> If so, just double translation is enough for that.
>>>> 
>>>> it sounds nice. what i would like to have is a consistent header processing for single/double translations and encapsulation.
>>> 
>>> I think that encapsulation and double translation can't be consistent to processing packet at all.
>> 
>> 4rd-u (duly completed with TOS transparency) is neither Double RFC6145 translation nor Encapsulation.
>> It is believed to have advantages over both of them.
>> Disadvantages has AFAIK still to be identified.
>> 
>> 
>>>> can we keep the TTL of IPv4 in the IPv6 header (plus fragment header but not anything more unless really necessary)?
>>>> 
>>>> can i understand that the following requirements are exclusive to each other: (a) we want to keep TTL changed in the IPv6 domain as the behavior of translation; (b) we want to keep TTL not changed until leaving the IPv6 domain as the behavior of encapsulation (4rd-U)? 
>>> 
>>> I think that these are exclusive.
>> 
>> Indeed, one cant't do both simultaneously, but AFAIK either choice is acceptable. 
>> Is there one you prefer, for which reason?
>> 
>>>> RFC6145 has defined TTL<->HopLimit translation. then how about using another reserved bit, say EF, in the fragment header for indicating the mode? if EF = 1, it is encapsulation mode, and therefore the HopLimit in the base header keeps unchanged untile being translated back to IPv4; if EF = 0, it is translation mode, and the HopLimit in the base header will decrease 1 for each hop. btw, previously i suggest using one of the reserved bits for the DF (e.g., the one before MF) instead of the first bit of the identification in the ipv6 fragement header, in order to avoid ambiguity caused by an IPv6 host in the single translation.
>>> 
>>> It seems that adding new semantics more. Very creative, but is it really needed even we already have both encaps and translation? When you want to define more new semantics, it would be better you define new protocol number for 4rd-U.
>> 
>> The idea is to avoid having two designs, each one with its own limitations, while a third design exists that has none of these limitations.
>> 
>> A key advantage of Double translation over Encapsulation, is that the IPv6 next header is the same as the Protocol of the conveyed IPv4 packet. Having a new protocol number would therefore defeat the objective of having advantages of both Double translation and encapsulations.
>> 
>>>> thus i'd like to suggest that one as follows, based on Remi's complement, where E is the indicator of encapsulation mode. copying TOS in the fragment header is fine because it doesn't impact the IPv6 dst (of single translation) getting the original IPv4 src's relative identification.
>>>> 
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |Vers=6 |   TrafClass   |            Flow Label                 |
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |         Payload Length        |Next Header=44 |   Hop Limit   |
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |                                                               |
>>>>     +                                                               +
>>>>     |                                                               |
>>>>     +                  IPv6 Source Address                          +
>>>>     |                                                               |
>>>>     +                                                               +
>>>>     |                                                               |
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |                                                               |
>>>>     +                                                               +
>>>>     |                                                               |
>>>>     +                IPv6 Destination Address                       +
>>>>     |                                                               |
>>>>     +                                                               +
>>>>     |                                                               |
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |  Next Header  |   Reserved    | IPv6  Fragment Offset   |E|D|M|
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |      0        |     TOS       |       IPv4 Identification     |
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |                        IPv4 Payload                           |
>>>>     |                                                               |
>>>> unfortunately, however, even we free the first bit of IPv6 identification in the fragment header, we cannot put the TTL here (before the TOS) because traversing different paths may cause inconsistant IPv6 identification values in fragments of the same datagram and disable reassemble at the IPv6 dst (in the single translation mode).
>>>> 
>>>> the problem of EF in fragment header is, it requires that the implementation process fragment header before descreasing the HopLimit. is it feasible?
>>>> 
>>>> how do you think?
>>> 
>>> IMHO, I'm not sure it is good idea to change the semantics of the IPv6 fragment. If a router receives 4rd-U packets, which router doesn't understand 4rd-U, processing these packets as fragmented packets could cause problem that sounds buffer exhaust attack.
>> 
>> I don't see that:
>> - IPv6 routers are not concerned with fragmentation.
>> - the 4rd-U endpoint doesn't need to keep anything in a reassembly buffer if a conveyed IPv4 packet is completely contained in a single IPv6 packet.
>> 
>>> And I also think that if we need to add new semantics even we can utilize IPv6 fragment, it would be better to define new protocol number for 4rd-U.
>> 
>> See above why a new protocol number wouldn't be workable.
>> 
>>> However, I don't think that we need to request to define it, because existing encapsulation and translation can be utilized for each appropriate situation.
>> 
>> 
>> 
>> The point isn't to prevent any ISP from deploy for its own use any design that works.
>> 
>> Yet, having only ONE STANDARD for a given need is better than several. 
>> I hope you can agree with that.
>> (In this case, the need is stateless support of residual IPv4 across IPv6-only networks.)
>> 
>> AFAIK, 4rd-U is better for this than double translation (say 4rd-T), and better than encapsulation (say 4rd-E), because it combines advantages of both (applicability of IPv6 O&M tools (a feature of 4rd-T), AND e2e transparency to IPv4 semantics (a feature of 4rd-E).  
>> If you still believe this is not right, an explanation will of course be welcome.
>> 
>> Cheers,
>> RD
>> 
>> 
>> 
>> 
>>> 
>>> cheers,
>>> --satoru
>>> 
>>> 
>>>> 
>>>> cheers,
>>>> maoke
>>>> 
>>>> cheers,
>>>> --satoru
>>>> 
>>>>> regards,
>>>>> maoke
>>>>> 2011/10/17 Satoru Matsushima <[e-mail]>
>>>>> Hi Remi-san,
>>>>> 
>>>>>> With this added, I believe that 4rd-U is a real progress over previously proposed Double translation and Encapsulation.
>>>>>> It can make IMHO a valuable unified standard.
>>>>> 
>>>>> Not enough. The original TTL value in IPv4 header must be carried.
>>>>> 
>>>>> cheers,
>>>>> --satoru
>>>>> 
>>>>> 
>>>>> On 2011/10/17, at 21:36, Rémi Després wrote:
>>>>> 
>>>>>> Hi Satoru-san,
>>>>>> 
>>>>>> Thank you for identifying a limitation of the 4rd-U
>>>>>> You are right, as currently specified, "it doesn't support diff-serv tunneling model, pipe and short-pipe".
>>>>>> All these need e2e transparency to the IPv4 Type of Service.
>>>>>> 
>>>>>> Fortunately, this is easy to fix: in the Identification field of the IPv6 Fragment header, copy not only the DF bits but also the IPv4 TOS.
>>>>>> 
>>>>>> The proposed 4r-U packet format becomes:
>>>>>> 
>>>>>> 
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |Vers=6 |   TrafClass   |            Flow Label                 |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |         Payload Length        |Next Header=44 |   Hop Limit   |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |                                                               |
>>>>>> +                                                               +
>>>>>> |                                                               |
>>>>>> +                  IPv6 Source Address                          +
>>>>>> |                                                               |
>>>>>> +                                                               +
>>>>>> |                                                               |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |                                                               |
>>>>>> +                                                               +
>>>>>> |                                                               |
>>>>>> +                IPv6 Destination Address                       +
>>>>>> |                                                               |
>>>>>> +                                                               +
>>>>>> |                                                               |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |  Next Header  |    Reserved   | IPv6  Fragment Offset   | 0 |M|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |D|      0      |    IPv4 TOS   |       IPv4 Identification     |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |                        IPv4 Payload                           |
>>>>>> |                                                               |
>>>>>> 
>>>>>> With this added, I believe that 4rd-U is a real progress over previously proposed Double translation and Encapsulation.
>>>>>> It can make IMHO a valuable unified standard.
>>>>>> 
>>>>>> Yet, I may have missed something else.
>>>>>> New justified objections are therefore most welcome..
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> RD
>>>>> 
>>>>> _______________________________________________
>>>>> Softwires mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>