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

[Maoke <[e-mail]>]

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?
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
>