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

[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.

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
>