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

[Behcet Sarikaya <[e-mail]>]

the idea of 4rd-U is to map IPv4 headers into IPv6 headers

address translation is called address derivation.

Isn't this translation?

regards,

Behcet

On Mon, Oct 17, 2011 at 11:26 AM, Rémi Després <[e-mail]>wrote:

>
> Le 17 oct. 2011 à 18:15, Ole Troan a écrit :
>
> > Remi,
> >
> > how is 4rd-U different from translation?
>
> Functionally, full network transparency to DF bit (and TOS with the
> complement that was missing).
> Technically, see for instance Figure 1 of the draft.
>
> Cheers,
> RD
>
>
> >
> > cheers,
> > Ole
> >
> >
> > On Oct 17, 2011, at 18:09 , Rémi Després wrote:
> >
> >>
> >> Le 17 oct. 2011 à 17:27, Satoru Matsushima a écrit :
> >>
> >>> 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.
> >>
> >> 4rd-u (duly completed with TOS transparency) is neither Double RFC6145
> translation nor Encapsulation.
> >> It is believed to have advantages over both of them.
> >> Disadvantages has AFAIK still to be identified.
> >>
> >>
> >>>> 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.
> >>
> >> Indeed, one cant't do both simultaneously, but AFAIK either choice is
> acceptable.
> >> Is there one you prefer, for which reason?
> >>
> >>>> 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.
> >>
> >> The idea is to avoid having two designs, each one with its own
> limitations, while a third design exists that has none of these limitations.
> >>
> >> A key advantage of Double translation over Encapsulation, is that the
> IPv6 next header is the same as the Protocol of the conveyed IPv4 packet.
> Having a new protocol number would therefore defeat the objective of having
> advantages of both Double translation and encapsulations.
> >>
> >>>> 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.
> >>
> >> I don't see that:
> >> - IPv6 routers are not concerned with fragmentation.
> >> - the 4rd-U endpoint doesn't need to keep anything in a reassembly
> buffer if a conveyed IPv4 packet is completely contained in a single IPv6
> packet.
> >>
> >>> 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.
> >>
> >> See above why a new protocol number wouldn't be workable.
> >>
> >>> 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.
> >>
> >>
> >>
> >> The point isn't to prevent any ISP from deploy for its own use any
> design that works.
> >>
> >> Yet, having only ONE STANDARD for a given need is better than several.
> >> I hope you can agree with that.
> >> (In this case, the need is stateless support of residual IPv4 across
> IPv6-only networks.)
> >>
> >> AFAIK, 4rd-U is better for this than double translation (say 4rd-T), and
> better than encapsulation (say 4rd-E), because it combines advantages of
> both (applicability of IPv6 O&M tools (a feature of 4rd-T), AND e2e
> transparency to IPv4 semantics (a feature of 4rd-E).
> >> If you still believe this is not right, an explanation will of course be
> welcome.
> >>
> >> Cheers,
> >> RD
> >>
> >>
> >>
> >>
> >>>
> >>> 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
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> Softwires mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/softwires
> >
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>