Hi Vicky,
Am 19.03.2016 um 16:14 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:Oooh, good point! Yes it would! Sorry I didn’t think about that :) Problem
Just thinking quickly (so I could have forgotten something)...would that RREP
contain the AckReq element which contains the IP address of who the Ack is
expected from…?
Vicky :-)
On 19 Mar 2016 10:06, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi all,
Am 04.03.2016 um 19:21 schrieb Lotte Steenbrink<snip>
<lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>>:
(What are we checking! What table or timer is there to check? JWD!)
Fix: add reference to multicast route message table: if no RREP matching our
RREP_Ack is found there, no actions are required (as the RREQ was
unsolicited and should thus be ignored).
Buuut, as I'm typing this, I'm wondering– some RREPs are unicast and would
thus not be in the Multicast table– is this a problem? I'm thinking it
wouldn't because neighbors whose bidirectionality is unconfirmed get their
RREPs via multicast, but then the document shouldn't say:
"and RREP messages may be multicast when the link to
the next router is not known to be bidirectional.
"
in section 4.6, should it? I think we should change the "may" to "will".
Quick follow-ups to that one:
1) finding the RREP matching our RREP_Ack in the Multicast Route Message
Table is a bit more complicated than I’d anticipated: since the RREP is
multicast when no bidirectionality is determined yet, the MRMT doesn’t
contain any info regarding the IP Address who we’re expecting the RREP_Ack
from. Consequently, a RREP_Ack would be considered expected if it matched
*any* RREP in the MRMT (i.e. if the MRMT contains a RREP with
RteMsg.Timestamp > CurrentTime - RREP_Ack_SENT_TIMEOUT).
At the very least, this should be mentioned in the Security Considerations,
but I’m wondering if there’s anyting we can do to improve this situation?
2) since I didn’t see anyone protesting, I’ve changed „may“ to „will“ as
suggested above :D