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

[Maoke <[e-mail]>]

hi Satoru-san,

2011/10/18 Satoru Matsushima <[e-mail]>

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

thanks for the correction. i meant the behavior similar to encapsulation but
implemented as double translation, but the wording was  wrong. :P


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


> ...

>
> > 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.
>
>
good point. however, Remi's proposed problem is a real concern. the solution
putting DF as the first bit at IPv6 identification doesn't cause the trouble
on routers but may hurt the single translation behavior. the translator
should not know if the packet will be translated back to IPv4 later or not.

cheers,
maoke


> cheers,
> --satoru
>