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

[Satoru Matsushima <[e-mail]>]

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.

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


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


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

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