(usagi-users 03677) Re: Routing header reversal support is missing!

I see, apparently we have interpreted the RFC differently. I suppose
this is why there is so much confusion around this specific point, and
I do wish the RFC were clearer.

Well, this ambiguity basically removes any usefulness in the routing
header... If the implementations are free to choose whether or not to
reverse the routing header, one can only guarantee that the route is
followed in one direction, that is, from the origin to the
destination. So any applications of the "source routing" concept of
IPv4 are impossible to duplicate in IPv6.

That's why I assumed that implementations did not have the freedom to
choose whether or not to reverse the route, because it wouldn't make
much sense to have a routing header if it would be ignored at the
destination. However, as you pointed out, the wording in the RFC does
not convey obligation, but instead a possibility. So yes, I agree,
your implementation follows the RFC correctly, the problem is in the
RFC itself, but that is not your concern.

Thank you for explaining your point of view.

Sérgio Gomes

On 26/05/06, YOSHIFUJI Hideaki / 吉藤英明 <[email protected]> wrote:
> In article <[email protected]> (at Fri, 26 May 2006 15:23:15 +0000), "Sérgio Gomes" <[email protected]> says:
>
> > As a followup to my previous post, and because I received no reply, I
> > began carefully analysing the IPv6 source code in the USAGI webcvs,
> > and I realized that the support for point 8.4 (Responding to Packets
> > Carrying Routing Headers) of the IPv6 RFC2460 is incorrect.
> :
> > It states that it should be possible to reverse routing headers if
> > authentication (namely IPSec AH) is present in the connection.
>
> I don't think so.  It is just permitted.
> The implementation is NOT incorrect; we simply do not support the 3rd
> option in kernel.
>
> --yoshfuji
>