Hi everyone,
Thanks for the replies on this, this topic is now finished! :)
I've updated the 5444 section so that PktSource is put in the AddressBlock,
and the PktSource TLV is now an Address Block TLV. IANA section also
updated.
I added the text about avoiding duplicate RERR in response to undeliverable
packets, without defining what "recent" means.
I added to RERR reception process, on the line where we check that the
route's next hop is the RERR sender, "OR if the PktSource is present and is
a router client".
Kind regards,
Vicky.
On Thu, May 7, 2015 at 4:57 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Welcome back Vicky,
Follow-up below...
On 5/7/2015 1:56 AM, Victoria Mercieca wrote:
On Thu, Apr 30, 2015 at 7:42 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Address Block TLV?
CP: Wouldn't the PktSource still be a data element even if it is an
VM: Yes, my mistake. We'd still have PktSource and AddressList as normal
but in the RFC5444 section, the mapping is where it will be handled
differently. Should I go ahead and do this?
Yes, please do.
CP: I agree with you that sending an RERR upon reception of an
undeliverable data packet SHOULD inhibit sending of new RERR packets for a
little while for the same PktSource/destination pair.
Should I add a sentence something like this?:
"In order to avoid flooding the network with RERR messages when a stream
of packets to Unreachable Address arrives, an AODVv2 router SHOULD
determine whether a RERR has recently been sent with the same unreachable
address and PktSource, and avoid creating duplicate RERR messages. "
Do we need to define anything though, or leave it to implementations to
decide the details?
For the purposes of getting to Last Call I think your sentence would be
sufficient. It might be
better to define a parameter to quantify "recently", on the order of one
or a few seconds,
but it's also O.K. as is.
otherwise
- If we send the RERR to the next hop on our route to PktSource, howstart, we avoid wasting messages (first the one C sends to B, then the one
can we be sure this is the route PktSource used to forward the packet?
(See
also the email on precursors - the following scenario is duplicated in
that
email in the context of precursors)
Consider:
source -----> A ---------> B ----------> C ----------> destination
| | ^
| | |
V V |
E --------> D -------------------------|
C's next hop to the source is B. When C receives a packet from source
which it cannot forward to destination, C sends a RERR to B using the
PktSource data element.
However, the packet might have come via D - the source could be using
the route via EDC. If the RERR goes to B, B might regenerate it to A (or it
might not be regenerated at all), then A might regenerate it to source (or
not regenerate at all), and if it reaches the source, the source will say
"thats not my next hop, I don't care" and ignore it. It will carry on
sending packets via E and D, and C will again say "I've got no route, send
a RERR to PktSource" (and the same thing happens again).
Either way, just because C's next hop to PktSource is B, doesnt
necessarily mean that PktSource used the route via B and C to reach the
destination. If the RERR goes back a different way to the route PktSource
is using, it will get ignored, if not at an intermediate node, it will get
ignored by source.
I have not heard of this being a problem. However, if it needs to be
prevented,
we could say that the second RERR from missing route to a destination
should
be multicast.
Regards,
Charlie P.
Why dont we just multicast it anyway? By multicasting from the
B might send to A, then the one A might send to PktSource), and we KNOW
that PktSource will get it. And if our route isnt used by a router that
receives our RERR, it wont regenerate it, simple. It only goes as far as
it needs to.
Alternatively, Charlie's MAC address idea from the email about precursors
will work.
CP: Generally, the reason for not multicasting is to avoid bothering
quiescent neighbors. But this could be a selectable behavior. Notably,
when
PktSource is included, a lot of neighbors might end up forwarding separate
RERR messages back to PktSource, so multicast could be burdensome.
CP: Storing MAC addresses during packet forwarding might have a big
impact
on throughput. Stan would know better, but I think that routers hate
doing
that sort of thing.
VM: The RERR needs to come from PktSource's next hop on the route to
unreachable address. Any other RERRs wont result in the route being deleted
on PktSource. The way to ensure that is to multicast. HOWEVER, I've just
thought of another solution: We could add in a test that if we receive a
RERR and we are PktSource (or it is one of our Router Clients), we should
process the route and delete our route to that address, even if the message
isn't from our next hop. Would that be acceptable? Could be mis-used
though, an attacker could stop PktSource sending traffic by sending a
malicious RERR with a PktSource value, knowing that the RERR would cause
the contained route to be deleted, cutting off its communication to the
destination.
I am O.K. with your solution, and if adopted then I should add this as a
threat
listed in the Security Considerations.
Regards,
Charlie P.
