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

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

Hi Tetsuya-san,
Please see below.

Le 21 oct. 2011 à 01:26, Tetsuya Murakami a écrit :

> Hi Remi,
> 
> I am not sure if this proposal is good or not... But I think you are trying to introduce a new semantics for IPv6 fragmentation header. For this, I think the implementation of IPv6 stack must be changed to process your new fragmentation header. But I am not sure how to decide if the fragmentation header in the packet should be processed as either the normal fragmentation header or your new fragmentation header.

AFAIK, the proposal is a new use of the IPv6 fragmentation function which remains compatible with its current specification:
- 4rd sources select Identification-field values in a 4rd-specific way which does comply with existing constraints on these values. 
- 4rd-capable destinations do IPv6 reassembly as usual, with only the additional feature that, when addresses are recognized as being 4rd, IPv4 specific information is extracted and  passed to the 4rd function.  
- 4rd-unable destinations won't receive any 4rd packets because 4rd destination addresses are different from others, e.g. with the recently proposed 4rd-specific V octet in address bit 64-71. (And even if they would receive 4rd packets, their reassembly function could work as usual.)

> Usually, IPv6 stack decides the processing for the following extension header based on the next header type. But you are using the same number of the existing fragmentation header for your new fragmentation header. If requiring any other information in the packet except the next header type, it might be a little bit painful from the implementation point of view.

Having a new header type would defeat the ability to use existing IPv6 O&M tools, a key objective of the proposal.
Fortunately, and as explained above, we have here a _new use_ of the existing fragmentation header, not a "new fragmentation header".


Regards,
RD


> 
> Thanks,
> Tetsuya Murakami
> 
> On 2011/10/17, at 5: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
>