Hi all,
John and I have just had a discussion and identified an issue with the way
routes are installed based on RREP_Ack.
Consider:
OrigAddr ---- A ---- B ---- C ---- D ---- TargAddr
Router A sends a RREQ on behalf of OrigAddr. Routers B and C regenerate it,
and Router D receives it and responds with a RREP, requesting a RREP_Ack
from its neighbor Router C.
Router C regenerates the RREP toward OrigAddr and sends the RREP_Ack to D.
Router D then marks the route to OrigAddr as valid and can start forwarding
traffic to OrigAddr.
In fact, at this point, the route is not fully established. If D now
forwards data for OrigAddr via C, at this point C doesn't have a valid
route installed to OrigAddr, and would send a RERR. This would result in
Router D deleting the route to OrigAddr, when it might be about to become
confirmed. If OrigAddr starts using the route to TargAddr, D wont be able
to send any return traffic (without initiating a new RREQ for OrigAddr).
Another potential problem: if C regenerates the RREP to B and requests a
RREP_Ack, but does not receive one (i.e. the link BC is not bidirectional),
then C deletes any route to B and to OrigAddr via B. Because the route is
not Active, it wont report this. So Router D, who installed a valid route
to OrigAddr, wont find out the route is invalid (unless it tries to forward
data and receives a RERR - so this is sort of self-healing). Perhaps this
is also solved by the retry of the RREQ that will happen when A does not
receive the RREP. Router D should learn a new route if this happens. BUT in
the meantime, there's potential for packets to get dropped.
Solution:
The ideal thing would be to say that you cannot send the RREP_Ack until
your route to OrigAddr is confirmed. So C cannot send a RREP_Ack at the
same time it regenerates the RREP. B cannot send a RREP_Ack to C yet
either. Router A, however, knows the route to OrigAddr is confirmed and
valid because OrigAddr is a router client of A. So A can send the RREP_Ack
to B. B can set the route to OrigAddr as confirmed, set A as a confirmed
bidirectional neighbor, and send a RREP_Ack to C. Router C can set the
route to OrigAddr as confirmed, set B as a confirmed bidirectional
neighbor, and send a RREP_Ack to D. Router D can set the route to OrigAddr
to confirmed and set C as a confirmed bidirectional neighbor.
Another potential issue, similar scenario:
OrigAddr ---- A ---- B ---- C ---- D ---- TargAddr
If the link CD was already confirmed as being bidirectional, D wont request
the RREP_Ack from C. It will assume its route to OrigAddr is valid just
because the next hop is a valid neighbor. But there is no guarantee that AB
and BC are also bidirectional and that the route will be valid. To solve
this, should we ALWAYS request the RREP_Ack for every route that gets
established? In which case, do we need to include OrigAddr in the RREP_Ack
so that we know which route is being acknowledged?
Kind regards,
Vicky.
