Hi, Abe-san.
On Fri, 13 Jun 2008 11:28:38 +0900
Toyo Abe <tabe@miraclelinux.com> wrote:
> Umm.. maybe right. But I'm still unconvinced. Isn't it too strict in the test?
> Redirects are sent only in response to data packets, so the neighbour
> (TR1 in this case) is apparently reachable. Updating the NCE also seems reason
able
> in terms of reducing ND packets in the network.
> Or, is updating NCE wrt the Redirect's source prohibited?
> If so, could you lecture me why? I don't see the reason so far.
>
> Thank you,
> -toyo
Unfortunately,
RFC doesn't require
"Redirects are sent only in response to data packets".
8.3. Host Specification
------------------------------------------------------------------------
4209 A host receiving a valid redirect SHOULD update its Destination Cache
4210 accordingly so that subsequent traffic goes to the specified target.
4211 If no Destination Cache entry exists for the destination, an
4212 implementation SHOULD create such an entry.
------------------------------------------------------------------------
Please check line 4211-4212.
RFC defines Redirect independently from the actual data exchange.
// Personally,
// I think that the situation will not offen happen on the usual network.
By your implimentation's policy,
you can update NCE for source node of Redirect.
But it is the additional function than RFC
and the behavior itself isn't defined in RFC.
If the Source Link-Layer Address option is valid in Redirect,
there is the possibility to update NCE by receiving Redirect,
but the fact is not so.
Please remember that Self_Test is the tester
for LOGO certification program.
The requirements must be the same as RFC,
because RFC is the absolute specification in the world.
What the tester can do is just only following RFC,
because this is the certification program.
Thanks,
On Fri, 13 Jun 2008 11:28:38 +0900
Toyo Abe <tabe@miraclelinux.com> wrote:
> Yukiyo Akisada wrote:
> > Hi, Abe-san.
> >
> > The Redirect never update the Neighbor Cache for TR1.
> > In Redirect case,
> > the importance is not the source address but the target address -- TR2.
> >
> > RFC 4861: Neighbor Discovery in IPv6
> > 8.3. Host Specification
> > ------------------------------------------------------------------------
> > 4214 If the redirect contains a Target Link-Layer Address option, the host
> > 4215 either creates or updates the Neighbor Cache entry for the target.
> > 4216 In both cases, the cached link-layer address is copied from the
> > 4217 Target Link-Layer Address option. If a Neighbor Cache entry is
> > 4218 created for the target, its reachability state MUST be set to STALE
> > 4219 as specified in Section 7.3.3. If a cache entry already existed and
> > 4220 it is updated with a different link-layer address, its reachability
> > 4221 state MUST also be set to STALE. If the link-layer address is the
> > 4222 same as that already in the cache, the cache entry's state remains
> > 4223 unchanged.
> > ------------------------------------------------------------------------
> >
> > The Neighbor Cache for TR2 may be updated by TLL option in Redirect.
> > But in that case the state is never updated to REACHABLE.
> > Updating to STALE is the only possibility.
> >
> > When the Neighbor Cache for TR2 is updated to STALE,
> > the state will have the same way as I described in the previous E-mail.
> >
> > IsRouter is one of the parameter for Neighbor Cache,
> > and it's not the same as the reachability state.
> >
> > How do you think?
> >
> > Thanks,
> >
>
> Umm.. maybe right. But I'm still unconvinced. Isn't it too strict in the test?
> Redirects are sent only in response to data packets, so the neighbour
> (TR1 in this case) is apparently reachable. Updating the NCE also seems reasonable
> in terms of reducing ND packets in the network.
> Or, is updating NCE wrt the Redirect's source prohibited?
> If so, could you lecture me why? I don't see the reason so far.
>
> Thank you,
> -toyo
>
>
>
>
--
Yukiyo Akisada <akisada@tahi.org>