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

[Maoke <[e-mail]>]

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.

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

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.

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?

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