[manet] AODVv2 responses to recent comments

[Victoria Mercieca <[e-mail]>]

Hi all,

We have just released the newest AODVv2 draft. The major update is the
separation of the AODVv2 route set from the RIB.

Here are also responses to the comments received before Christmas. This
should include all the points from Thomas Clausen regarding versions 11 and
12, and also a couple of other points which have been brought up since.
Apologies for the huge email. For issues that need further discussion, I
have tried to include the main points of the discussion so far. Please feel
free to create a separate thread for any further discussion.

We are still looking into the loop conditions recently reported for AODV,
also still working on the text about security, and use of msg-hop-limit.

Kind regards,
Victoria.


1. End-to-end / hop-by-hop acks - issue when a route is marked as confirmed
and valid when the link to the next hop is confirmed as bidirectional (but
the links downstream have not yet been verified as bidirectional).

AODVv2: The authors believe this is an issue which would not occur
frequently, and would right itself.

This only occurs for the route to OrigAddr. What needs to happen for this
to occur is that an intermediate node that takes part in the route
discovery between OrigAddr and TargAddr coincidentally has packets to send
to OrigAddr in the time between confirming the link to its own next hop
toward OrigAddr is bidirectional, and the time taken for all other routers
on the path to confirm their next hops too. If the route is used to forward
packets before every other link in the path is confirmed as bidirectional,
and the data packets are forwarded faster than the RREP and any RREP_Acks,
then yes they could be delivered to a router without a valid route to
OrigAddr. Alternatively if one of the links turns out to be unidirectional
then the data packets will also arrive at a router without a valid route.
In these cases, RERR messages will be generated toward the source of the
traffic, the route to OrigAddr will be deleted at routers back toward
TargAddr, but if data packets are still flowing from any source to
OrigAddr, the route will be re-requested by the router responsible for
discovering routes for the source of the data.

The changes required to make acknowledgements end-to-end would require a
lot more control traffic and be necessary for every route discovery and in
almost all cases would be unnecessary.

Text has been added to the draft in “Local Route State Changes” to describe
this.

2. Buffering
Thomas:
“It would seem that buffering, as specified, does not accomplish what
it states that it accomplishes: packets are (as you describe) still being
sent while no route is available, and therefore will be dropped later.
=> Consequently, it seems that buffering is a futile exercise?”

AODVv2: Packets are buffered before a route exists. A router only begins
sending them when it deems the route to be valid. In general, buffering is
not futile.

True, there is this case outlined above where the router could deem the
route valid before the bidirectionality check has happened for each and
every hop. If the links chosen for the route are not all bidirectional,
then yes, any data packets forwarded along this route will end up being
dropped at some point on that path.
This case is caused by the RREP_Ack being hop-by-hop, and not caused by
buffering.

Thomas: 
“Buffers have huge impacts on TCP performance, and I doubt if the issues on
e.g. TCP are well enough understood by this WG (Bufferbloat was an example
of where people got it wrong, despite having extensive experience).”

AODVv2: Packets will only be buffered while a route is requested. The TCP
packets buffered will be packets for session initialisation. The authors
believe that buffering these will have a positive effect. Some references
have been suggested, listed here, the first of which has been included in
the draft:
http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koodli.pdf
Mobile Internetworking with IPv6: Concepts, Principles and Practices
{Koodli, Perkins}
disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt
Analysis of TCP performance over mobile ad hoc networks
http://dl.acm.org/citation.cfm?id=313540
Alternatively, we could remove the mention of TCP, and instead state that
buffering MAY be used for packets awaiting a route, but that implementation
and implications of this are out of scope for AODVv2.


3. Use of msg-hop-limit and msg-hop-count:
Thomas:
But, either way, as according to your model messages are never forwarded,
but always are intended for receipt by a router which is a direct neighbor,
then a <msg-hop-limit> >1 (which applies to the message) seems
inappropriate.
Actually, according to that model, I would even say that receipt of a
message with a <msg-hop-count> >1 should be interpreted as a malfunction.
As you refer to RFC5444 appendix B, do note that Appendix B of RFC5444
(and, note the errata 4003) talks about:
      <msg-hop-limit> field, if present, contains the number of hops on
which the message is allowed to travel before being discarded by a MANET
router.  The <msg-hop-limit> is set by the message originator and is used
to prevent messages from endlessly circulating in a MANET.
Specifically “set by the message originator” and “number of hops on which
the message is allowed to travel” — with your control messages traveling
just one hop, I believe that setting <msg-hop-limit> = 1 is correct.

AODVv2: Discussion is still needed here. We wonder if these fields are
necessary at all for AODVv2. We were using them to limit the number of
regenerations of a RREQ. However, the hop limit value needs to be large
enough to allow a RREQ from one side of the network to another. It might be
the case that using the hop limit, almost every router in the network would
receive that RREQ anyway, and by using the redundancy check, we already
stop RREQs from circulating endlessly.

4. Abstract
Thomas:
“I made the following comment, which still applies:
“This is a little over-stating the applicability: these statements may be
true in some scenarios (for example, when there are few concurrent traffic
flows, and therefore few routes to repair, and therefore few flooding
operations to contend for channel access). As a general statement, this
last sentence is incorrect””

AODVv2: The text has been removed and the abstract now states: “ The Ad Hoc
On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended
for use by mobile routers in wireless, multihop networks.  AODVv2
determines unicast routes among AODVv2 routers within the network in an
on-demand fashion.”

5,9,12,13,20. Router Client
Thomas:
“I made a comment previously that “Router client” is a poorly chosen term,
and have proposed alternatives. I’ve seen some attempts on the list at
rather than change the term, explain it — some of which is in this
document. The “Overview” still talks about “a router…one of its clients” -
which is no less confusing than last time Iw went through it.
I reiterate, why not use “Local Attached Network Set”, which is the term
used by other documents from this WG?”

AODVv2: We already answered this suggestion on the MANET list and asked for
comments and suggestions, and no responses were received. We have defined
what we mean by Router Client, and the terminology has so far not changed.
However, some alternatives have been suggested, so if you feel any of these
are more effective, please let us know:
•    Advertised IP Address: puts the emphasis on advertisement rather than
topological connection
•    Accessible IP Address: puts the emphasis on accessibility through the
particular router – not bad
•    Reduced Function Device [RFD]: doesn’t roll off the tongue, but this
is terminology used for L2R in IEEE 802 Wireless for a similar situation
•    Accessible Device Address: adds some emphasis for the device as well
as the address
•    Stably Connected IP Address: nothing is permanent, of course, but the
router client set is thought to be relatively stable
•    Topologically Connected IP address: ... suggests that a "topological
connection" is stable compared to wireless
•    Administratively Assigned IP address: ... somehow does not connote the
"otherness" of the router client devices.

6. Overview - adjacency
Thomas:
The term “confirming adjacency” is gone, and is now replaced by “confirming
bidirectionality” - which, alas, still sounds like there is some active
monitoring (HELLO message exchange) going on. Unless that is the case, then
please be more specific here.
I note that the term adjacency is used through and through the document,
btw.

AODVv2: The text has been updated to avoid the word adjacency. We do not
believe the text implies active monitoring through HELLO messages.

7. Overview - forwarding plane
Thomas: I suggested in my last review: The overview must also include a
paragraph on the intersections between this protocol and the forwarding
plane — this, as it is different (and more invasive) from that which is
typically seen in routing protocols.
Specifically, as a reactive protocol, it is required (at least) that the
forwarding plane is modified :
1) A “miss” when looking up a next hop for a data packet to be forwarded,
is signalled to the AODVv2 process so as to permit that route discovery be
launched;
2) A “miss” when attempting to deliver a data packet to a next hop, which
was recorded in the routing table, is signalled to the AODVv2 process so as
to permit that a route repair be initiated and/or a Route Error be
generated.
3) A “hit” when looking up a next hop for a data packet to be forwarded to
a destination is signalled to the AODVv2 process so as to permit
maintenance of “active route” Route State, timers and such.
Note that these things are necessary to call out in the “overview” and in
the “applicability statement”, both: it is not that they are negatives per
se, but that they are important factors governing the applicability of this
protocol: will a given platform permit such access to the forwarding plane,
for example? Important to understand if for that platform this protocol is
apple
I see that this was not addressed in the overview, nor in the applicability
other than by a forward reference to section 6.4. While it is positive that
there is a section 6.4, this does not exonerate the overview and the
applicability statement for being honest about the requirements (notably to
the platform/os) that this protocol has for being applicable

AODVv2: The Overview and the Applicability Statement now refer to these
basic requirements for the interaction with the forwarding plane. The
Applicability Statement also contains the reference to the later section
which describes this in more detail.

8. 7182 and security

Thomas: I suggested in my last review: It is important to do more than
this: 7182 does only provide “containers” for ICVs and timestamps, and does
not specify how to use them to obtain specific security properties. RFC7182
may be a tool that can be used, but how* that tool is used is what
determines the security properties.
Therefore, saying that “security is dealt with by using RFC7182” is either
an incomplete statement, or is indicative of insufficient security
considerations.”
The actual sentence in the I-D has been changed, now it explicitly names
the two TLVs from 7182 that it uses. That is, alas, still not sufficient.
Making the aside that was discussed recently on the list, that (i) control
messages are not forwarded, and that (ii) they are modified in transit, the
security/trust model is somewhat different from that of 7181 and
consequently for what 7182 was initially written for. I think that  calling
out the trust model, and how 7182 actually is used here, might be what is
called for.
Continuing with the aside, this *especially* as the applicability statement
says: "Providing security for a reactive routing protocol can be difficult”

Thomas:
OK, so assume that I understand regeneration as per my previous email, as
meaning “generate a new message and send to my neighbors, based on what I
learned when processing a received message” — just like any distance vector
protocol does.
In that model, what you write makes sense: each originator of a control
message (i.e., whoever generates or regenerates it) is free to include the
information it desires, such as the 4 points you list above. No issues with
that.
However, and this joins what I pointed out in a previous email, you write
in the applicability statement: "Providing security for a reactive routing
protocol can be difficult."
While we can discuss if the nature of “reactive routing protocol” generates
particular difficulties, we certainly can agree that this protocol has the
same “difficulties” as a distance vector protocol: routing topology
information (by definition) not being exchanged end-to-end, but between
neighbors (who do calculations and generate their own announcements —
regeneration, as you call it).
This means that a specific security model of transitive trust must be
assumed, no? I trust Victoria, therefore when Victoria says “Stan told
me” then I trust that she actually verified that "it was indeed Stan who
told her …” — and either way, I have no way of verifying?
I did not see the trust model / trust assumption discussed in the
specification (specifically not in applicability and in section 13, both of
where it should be called out), but I think that this is actually a crucial
point to get right, in order to approach developing the MTI security
mechanisms.
Anyways, that observation actually contrasts strongly with what the
applicability statement then goes on to say, namely:
   AODVv2 provides for message integrity and security against replay
   attacks by using integrity check values, timestamps and sequence
   numbers, as described in Section 13.
This is true only in as much as messages are indeed exchanged between
neighbors: when you “regenerate” a message, i.e., generate a new message in
response to receipt of a message, you generate brand new payload (but
possibly including some of the data from the received message, of course):
thus, any ICVs “from farther away than the neighbor” will be useless (or,
if you zero out the parts that you change, these parts will not be
protected).
The above sentence, quoted from the applicability statement, and that which
transpires from section 13, seems - certainly, absent the trust model
assumed - to suggest that end-to-end protection/validation is provided.
But, this is not the case.
Finally to the applicability statement, a question:
If security associations can be established, encryption can be used for
AODVv2 messages to ensure that only trusted routers participate in routing
operations.
What you want to say here is that “if all trusted routers have a shared
secret, then we’re able to use that shared secret to ignore non-trusted
routers”, right?
While “security associations” that do not pass through a shared secret
probably can be thought up, it’s not trivial and I did not find any
discussion of that in the document?
Having, on the topic of security, re-read Section 13, which starts:
   This section describes various security considerations and potential
   avenues to secure AODVv2 routing.
While this is an honest description of what follows, I remain convinced
that this is not sufficient. So let me ask as precisely as I can:
o what is the MTI security mechanism that a conformant implementation must
provide? Specifically: - which are the processing steps (for example in
section 7.2.1 and section 7.2.2 for RREP - and similarly for the other
message types) that define that security mechanism
o what protection is offered by that MTI security mechanism? And what
remains vulnerable.
If this specification targets std.track, then it should include (reasonably
solid, but definitely well specified) MTI security.

Chris Dearlove:
There are two potential choices:

- RREQ has an integrity check value to indicate that someone trusted
created it, if not necessarily the destination. That someone might be
identifiable or not.
- RREQ has a signature that indicates that the destination created it.

Unfortunately, an RREQ that changes as it is forwarded (aggregating data of
any sort) makes the second option tricky, unless there’s some sort of
aggregating signature as it is forwarded. But I’m not an expert on the
latter.

The most trivial case of the former is simply that everyone trusted has a
single shared key. That has obvious issues – although it was good enough
that embodied as RFC 7183 we could get 7181 through the system (as a “must
implement, do not need to use” minimal case). Alternatively something
identity-based (e.g. draft-ietf-manet-ibs) could be used, so you know who
created the message you received, but you are relying on a chain of trust,
hop by hop. At which point you might as well just sign packets (see RFC
7182).

But in even the weakest case (the single shared key used hop by hop) there
has to be a failure for things to go wrong - either loss of key (in which
case all bets are off) or suborning one router (who can do quite a lot of
damage).

I haven't read the latest AODVv2 draft yet, but this sort of thing should
be described in its security considerations - the previous draft though
didn't discuss this as far as I recall.

Chris Dearlove:
If you go down this route of assuming transitive trust, then you might as
well use 7182’s packet ICV and timestamp rather than message ICV and
timestamp.

There is a complication (mostly one of presentation) that the 5444
multiplexer (rather than AODVv2) needs to do this, at least for packets
containing AODVv2 messages (but at which point, probably all 5444 packets).
So you either, depending on your point of view, need to request it to do
that, or (administratively) decline to operate except over a 5444
multiplexer that is doing this.

The advantage is one of saved space and time when packets contain more than
one message. Plus slightly better protection (hop count and limit are
covered) but which probably doesn’t matter here.

If messages are changed/replaced on a one-to-one basis as forwarded, then
the only solutions I can see are hop by hop transitive trust (packets or
messages per hop), or something complicated involving aggregation and
knowledge of changes. But the latter would be a research task to develop,
so let’s not try that.

Jiazi Yi:
I agree with Chris and Thomas on their concerns on the hop-by-hop security
issue.
This is very different from classical DV protocol, in which the vector
information is designed to be exchanged between neighbours.
In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple hops. A
router can sign a message that isn't actually initialised by itself -- this
is, at least, against intuition.
This can be an issue if we have compromised routers in the network. Of
course, a compromised router is a problem for every protocol, like OLSRv2.
But in OLSRv2, a compromised router can only speak on behalf of itself --
however, in AODVv2, a compromised/mis-configured router can pretend to be
any other router (for example, generate RREQ messages using another address
as OrigAddr).  The consequence will be much more serious if that happens.

AODVv2: This is not yet addressed.

9. Terminology - host, routers, router clients:

Thomas: My last review suggested:
“This has been brought up on the list several times in the past, without
having been addressed.
There are “hosts” and there are “routers” — whose roles are well defined.
Node” not so much — which is clear from looking at the definition here:
“either AODVv2 routers or router clients” (with “router clients” being
defined as “an AODVv2 router is also its own router client”).

This is very much related to the use of “Router Client”, and both that
term, and “node” indicative that some clarity is needed here.

All a router cares about is “an address”. If that address is of a network,
or a router, or an interface (and, if said interface is installed in a
router or a host) doesn’t matter.

So, “an address” is something that the routing protocol should care about
finding paths to. Which means that each address that should be made
reachable by the routing protocol should be advertised by (at least) one
router in the network.

One way of doing that would be to simply talk about “Attached Networks” as
is done in RFC7181, wherein an address included in the “Attached Network
Set” is advertised by an OLSRv2 router....in this case, the equivalent
would be “for each address in the Attached Network Set of an AODVv2 router
the router MUST respond authoritatively to a RREQ, and MUST maintain the
corresponding sequence number”.
The text, as it currently is, is really hard to read, and a re-edit along
these lines would go a long way.”

I note that the terms “Node” and “Router Client” are still used, in their
original form, and that other than some slight wordsmithing this comment
has not been addressed in the document.

I reiterate that the need to use router, host, node, and router client in
and by itself should be an indicator that tightening up of terminology is
required.

AODVv2: See 5. The use of “node” has been addressed.

10. Terminology and elsewhere - address
Thomas: I made the following comment to Routable Unicast IP Address:
“Are there any technical reason why not simply *any* address could be
considered by the routing protocol?
My understanding, but correct me if I am wrong, is that all that is
required is that all interfaces in a given AODVv2 routing domain has an
unique address.
That some of these addresses (by an IP addressing architecture document)
has special semantics associated (such as are link locals, or are for
private use, or are for example use only, or are for multicast) is out of
scope here?
I see nothing has changed on the above, so let me be more explicit: the
routing protocol itself probably) should not care about what kind of
addresses are filled into it. Is an 192.16./16 address appropriate? Not
across the internet, but it may be in somebody’s private deployments.
Should the routing protocol be “address police” and is implementation of a
“I refuse to route these addresses…” a requirement for claiming
conformance? Suggest simply stating what the requirements are under which
the routing protocol will work — and leave “address assignment politics”
aside.

AODVv2: We ask for clarification on this issue. We use the phrase “routable
and unicast” in the draft with respect to OrigAddr and TargAddr. We dont
mean to exclude addresses from the private address ranges. But we dont want
to request routes for multicast, indeterminate, link-local, or loopback
addresses. This is not about router interface addresses which are used for
AODVv2.

11. Multiple interfaces with the same IP address, 6621 implications

Thomas: I also continued:
Now, with that being said also, the WG wanted that RFC7181 supports not
just multiple interfaces, but also the same address used on multiple
interfaces of the same router. There were good reasons for that, and while
it was not trivial to implement, it turned out to be the right thing to
support. If there are technical reasons why this is not supported in AODVv2
(for example, if this cannot be made work because of <reason>) then that
should be called out in the applicability statement also?
Conversely, if it is possible in AODVv2, then I do not believe that it is
clearly specified how (at least, in the “naive” on paper examples I drew
up, something ended up not working). So either the protocol as-is does not
support it (but could be made to?) or it is supported (but just need to be
spelled out), or is not possible (and need to be disclaimed in the
applicability statement).
Stan Ratliff was a driving force in holding the WG’s collective feet to the
fire in getting this support included in RFC7181, and would likely be the
right person to consult on this matter?
I actually have not seen changes, or comments, on this. In OLSRv2, the WG
was making it a strong requirement that it should be possible to use the
same IP address on different interfaces of a router. It was somewhat
tedious to design around, but it was worked out, and the conditions under
which that was possible were defined and documented.
I would like to see the same done for this protocol.
I also note that this is not unrelated to RFC6621-discussions. For example,
when selecting S-MPRs on a multi-interface and multi-address-per-interface
router, care must be taken least things won’t work. So, if (and this links
back to previous mails) RFC6621 is a requirement or desire for this
protocol, then there are some considerations required here.

AODVv2: We have removed references to RFC 6621.
Initial thoughts on this topic of multiple interfaces using the same IP
address, is that this wouldn’t cause a problem, if the router has only one
sequence number. However, this is up for further discussion.

12. Interfaces configured as router clients

Thomas: I see that the definition of “Router Client” has changed to be
“An address or address range…the AODVv2 router’s interface addresses are
also configured as router clients”
Better than before, but still missing the target. The term “Router Client”
is, as I indicated numerous times before, odd.
But the second part of the sentence, does that mean (what it says) that the
interfaces must be configured specially, so as to be able to be “router
clients”? That can’t be true.
What you likely mean is:
An AODVv2 router is configured so as to consider its own interfaces as part
of the locally attached network set” ?
You configure the router, right? No special “interface configuration
properties” are required for an interface to be announcable by  an AODVv2
router? (And, getting rid of node would actually make the definition
shorter and nicer)

AODVv2: The wording we use says: "The IP Addresses of the router's
interfaces will appear in the Router Client Table." and in the Terminology:
"The AODVv2 router's interface addresses are also configured as Router
Clients." Both statements say that ‘interface addresses are configured as
router clients’ ...we are not sure why this is misunderstood. We have a
router client list, and the AODVv2 router’s interface addresses are
included in this list. The interface itself doesn’t have special “interface
configuration properties”.

13 - more on router clients
Thomas: Now, snipping out from the applicability statement:
"Multi-homing of an IP address is not supported by AODVv2, and therefore a
Router Client, i.e. an IP Address,  … "
…evidence to there being some redundant terminology here to weed away.

AODVv2: That was there as a reminder that a router client is based on IP
address, even though the device with that IP address may have other IP
addresses too. It’s the IP address that is the router client, not the
device as a whole with its entire collection of configured IP addresses.
One IP address of that device might be configured as a router client on one
router, and a different IP address of that device could be configured as a
router client on another router. The IP addresses would seem to AODVv2 to
be on different devices.


14. data elements

Thomas: The below is a little bit of a meta-comment, I am not quite sure
what I think here. The definitions for Target Node and such were confusing
before. They still are, somewhat.
I think that it may be because the definitions now used are simply
copy-pasted out from the tables in the previous version, for example:
   “An AODVv2 Data Element containing the destination address of the IP
packet triggering route discovery.”
OK, I can trace back and see that a Data Element is something that exists
inside a protocol message. To me, however, that’s not really general
terminology as such, but part of the specification of a packet format - or
rather, it is the notation that you use when describing an algorithm. By
the way, why are some notations in CamelCase whereas others have a space in
them, e.g. “Target Node” and “TargMetric”, both of which are Data Elements?
Would be good with a consistent approach here.
I *think* that it would be better to take all those “Data Element” bits and
move to a separate section (or subsection) to the terminology, and then
keep all the “other stuff” (Neighbor, …) in its own section.

AODVv2: Your comment from draft 11 where we already had data elements in a
separate table, says:
"Also suggest abolishing this table and folding the definitions in with the
other definitions in the terminology section."
We have updated to not refer so heavily to the term Data Element. All the
terms are described in the Terminology section. Those in CamelCase are used
as message fields.


15. Route “to a specific address”
Thomas:
I made a comment: Second, should “valid route” not be qualified by “to a
specific address”?”
Which was not addressed.

AODVv2: Every route is to a specific address...the address is specified by
Route.Address and Route.PrefixLength.
Do you mean that routes are to the address TargAddr or OrigAddr and
therefore to a specific host address rather than to a network prefix? This
is not the case. Prefix Length is included in AODVv2 messages so that the
route learned from the message represents the prefix which OrigAddr or
TargAddr resides on (if the router client entry corresponding to OrigAddr
at RREQ_Gen or TargAddr at RREP_Gen is configured with a prefix length).
e.g. OrigAddr is 10.0.0.1 but the corresponding router client entry at
RREQ_Gen could be 10.0.0.0/8. So when constructing the RREQ you include a
prefix length of 8, and when receiving the RREQ and learning the route to
OrigAddr, you can install a route to 10.0.0.0/8.  Text has been updated to
make this more obvious.

16. unreachable address

Thomas: I also made a comment on "Unreachable Address” - I am glad I did,
because I apparently had a different understanding than what was intended.
I now see that an Unreachable Address by definition is an address listed in
a RERR message, and not the same as an address to which no route has yet
been discovered? If yes, then please use a different term, such as
FormerlyReachableAddress” or something of the sort?

AODVv2: "Formerly reachable" is inaccurate... we send a RERR if another
router forwards a packet via us, and we dont have a route, not just when we
lose a route. We might never have had a route, or might never have had a
valid route, so the address may not have been "formerly reachable". Also, I
think "FormerlyReachableAddress" is a really ugly term. Unreachable means
"we don’t have a route and we aren’t going to request one" or "we lost this
route" (depending on why the RERR is being sent). It doesn’t mean "we
didn’t request one yet", and it would be wrong to class an address as
unreachable because we hadn’t requested a route for it yet, that is,
assuming it’s configured as a router client.

If a better term is suggested we could consider changing but at the moment
we have kept “Unreachable Address”.


17. Applicability - multiple interfaces same address, 6621 again

Thomas: Applicability statement: First, I would like to recognize the
efforts made to improve this since last review. Thanks
Second, the document states: "AODVv2 supports routers with multiple
interfaces, as long as each interface configured for AODVv2 has a unicast
IP address.  A router may use the same IP address on multiple interfaces.
Address assignment procedures are out of scope for AODVv2.”
Is that true? Granted, I have not worked this through in detail, but I can
present a counter-example: the use of RFC6621 means that there certainly
are some constraints that must be respected least various flooding
optimizations may not work.
Secondly, if the multiple-interfaces-with-same-address are on the same L2,
and this is what I have not worked through, are there any situations that
will not work?
The immediately previous version of this specification read:
"AODVv2 supports routers with multiple interfaces, as long as each
interface configured for AODVv2 has its own unicast routable IP address"
So what changed that means that each interface no longer needs its *own*
unicast address?

AODVv2: Well, based on previous questions on this, we talked it through and
decided there shouldn’t be an issue if different interfaces of a router
used the same IP address. Note that we changed AODVv2 so that there is one
sequence number per router. No longer can a router use different sequence
numbers on different interfaces. If an RREQ went out of two interfaces
using the same address, we worked it through and decided the request would
be processed correctly.
Also, text referring to RFC 6621 has been removed.

18. Applicability and appendix - multihoming

Thomas: I pointed out to the Applicability Statement:
I think that appendix B needs to be removed. Essentially, it makes claims
that it is possible to do multi-homing — but neither specifies how it is
done, nor gives pointers to documents that justify the claim.
AODVv2 does not support multi-homing — that’s clear, and it is fine that it
is called out here. Thank you for that.
Now, with that being said, I am torn between being satisfied that it is
called out on one hand, and wanting to have “multi homing” on the other
hand. RFC7181 supports multi-homing, FWIW.
I believe that this also would merit some explicit discussion by the WG, in
order to understand if this design decision is acceptable?
I see that Appendix B still is in the document, and I do not recall having
seen this discussed on the mailing list. Simply removing the reference from
the Applicability Statement to Appendix B does not address the issue that I
raised in my previous review.

AODVv2: Appendix has been removed and may appear in a future informational
document.

19. interfaces list - use of “SHOULD”

Thomas: To 4.1, I made the following comment:
"Is this a should, or a SHOULD? If the latter, should it be a MUST?
In general, there are a lot of such “maybe normative language” through the
document, and I would much like to see an editorial pass — essentially all
may/should/ must and friends carefully evaluated as if they should become
2119-terms, and ... more importantly (it has been called out before, fwiw)
quite a bit of should/SHOULD which ought to be transformed into MUST.
Generally, aiming for a very a low number of SHOULD is a good design metric
for a document”
Aside from the general comment on 2119-language, why is this a SHOULD?

AODVv2: We changed this instance to a MUST and will be checking for “maybe
normative language”.


20. Router client - Local Attached Network Set

Thomas: To 4.2, I made the following comment:
As indicated earlier, I believe that the term “Router Client” is ill
chosen. I believe that it is more appropriately an “Attached Network Set”
since — as indicated previously — the term “Router Client” is ambiguous. I
am pleased to see, though, that this “Router Client List” in reality is an
“Attached Network Set” and so that change should be (relatively) easy.
The above comment still is applicable to this revision,

AODVv2: See 5,9,12,13.


21. Subnet
Thomas: To 4.2, I made the following comment:
Also, I recommend to not say “subnet” — how about rephrasing to “If a
prefix is included in the attached network set of an AODVv2 router, then
that AODVv2 router MUST provide connectivity for, i.e. answer to RREQs and
maintain sequence numbers for, all addresses from within that prefix.”
I note that while the term has been removed from section 4, there’re 4
lingering instances of this term in the document, that could easily be
removed.

AODVv2: All mentions of "subnet" were in the ENAR section. They have been
updated to say network, or "networks attached to the routers"


22. relocating router client

Thomas: I Also made a comment about Appendix B in my previous review, which
is referenced here. That comment still applies.

AODVv2: Moved into main draft.


23. Neighbor Monitoring

Thomas: To Section 4.3, I noticed:
Does section 6.2 describe how to monitor an established adjacency only, or
how to discover neighbouring AODVv2 routers? Looking in 6.2, I see
“Not every pair of neighboring routers will necessarily form an adjacency,”
— so it likely isn’t 6.2 that tells me how to maintain this table?
In short, “A neighbour table MUST be maintained” — where can I find
information on how to do this?
Section 6.2 states:
“The default approach for monitoring bidirectional connectivity to the next
hop toward OrigAddr is to request acknowledgement of Route Reply messages.”
That certainly will tell me if a link over which an RREP is sent is
bi-directional, but will not maintain a “neighbor table”.
So how is this done? Or, is the “Neighbor Table” not supposed to contain
the complete set of neighbours? What information “...MUST be maintained”
then, in this table?
This is very unclear, I would not know how to implement a mechanism that
populates this “Neighbor Table” with the needed information here.
I see no (relevant) changes to 6.2 nor to 4.3 so I assume that this comment
has not been addressed

AODVv2: A new section was added to show how to update the neighbour table.
There have also been updates to this entire section since version 12.

24.     pseudo-code

Thomas:
I am throwing this in here, as I am sure that I commented on that in the
previous review, but I do not see that addressed: is Appendix C normative,
or not? It represents “ a second specification of the protocol, in a
different language” from the main part of the specification. I have not
walked through and made 200% sure that both are perfectly aligned and that
there are no ambiguities, but having two different specifications of a
protocol is a recipe for disaster.  Please either make 2000% sure that they
are specifying the same thing without ambiguities, or remove one.

AODVv2: Removed - maybe to include in an informational document in future.


25. seqnum as 16 bit unsigned integer

Thomas: To section 4.4, I wrote:
"would like to nit-pick that: the router can maintain this sequence number
in whatever format it pleases — but, when it includes it in control
messages, it must be representable in a specified format, respecting
certain rules.”
I see that there were no changes following this comment.

AODVv2: Why store it as anything other than what it needs to be when it
goes into a message? However, we now state "MUST report its own sequence
number as a 16 bit....whenever it creates a RREQ or RREP message".


26. multiple seqnums?

Thomas:
To section 4.4 I asked for clarification as to if sequence numbers were per
interface or per router, as the specification was unclear on that. The
words has changed, but it still is unclear: how many sequence numbers does
a router maintain? One? One per interface?

AODVv2: We tried to start discussion on that point, and in the meantime we
reverted to having 1 seqnum per router. We think the text is clear... we
refer to "the routers sequence number" or "its sequence number" - never
hinting that there could be multiple seqnums per router (as far as I'm
aware).


27. sets/lists/tables

Thomas:
In my previous review, I expressed that it would be preferential to use “a
notation of Sets” rather than tables. I see that this has not changed.

AODVv2: You preferred sets rather than lists in your previous review...and
explained our reasoning for this in responses to the MANET list, and we did
not receive further comments.


28. use of “node”

Thomas:
I made a comment on node and address, let me pick this up again. The
following:
RteMsg.OrigAddr
An IP address of the node which requires the route, i.e., the source
address of the IP packet triggering the route request.
would be more compact and clear if getting rid of the term “node” and said:
RteMsg.OrigAddr
The source address of the IP packet triggering the route request.

AODVv2: Change made as suggested.

29. route table/rib/routing set

Thomas: To section 4.6, and I (and others) have commented on this before:
All AODVv2 routers MUST maintain a route table.  The route table entry is a
conceptual data structure.  Implementations MAY use any internal
representation but MUST contain the following information:
In order to avoid confusion, rename this to “Routing Information Base” or
“Routing Set” — a Routing Table is an operating system construct, whereon
operations directly influence packet forwarding. What you are defining here
is a RIB/an RS.

AODVv2: Done in version 13.


30. rreq for prefix, use of “ip address” and “address"

Thomas:
The confusion that I pointed out in my previous review on “IP address” and
“Address” being used a bit haphazardly persists, fwiw. It makes me think,
can a router send an RREQ for a prefix?

AODVv2: See also #15. RREQ_Gen can include the prefix associated with
OrigAddr by adding a prefix length to the message, the prefix length
associated with the router client entry corresponding to OrigAddr. So all
routers which receive it can learn a route to the prefix on which OrigAddr
resides. But for TargAddr... the RREQ only has one target IP address - the
destination IP address of the packet requiring the route... so what prefix
length would it use? The RREQ requests a route to a single IP address.
However, when the RREP is created, RREP_Gen should include the prefix
length associated with the router client entry for TargAddr. So all routers
which receive this RREP learn a route to the prefix TargAddr is part of (if
the router client entry is configured with a prefix length). The text has
been updated to make this more obvious.


31. next hop ip address wording

Thomas:
I also called this out in my previous review as incorrect, and despite
wordsmithing it still is:

        Route.NextHop
              The source IP address of the message advertising the route to
              Route.Address, i.e. an IP address of the AODVv2 router used
for
              the next hop on the path toward Route.Address.

If that “message” is an RFC5444 entity, then it does to have a “source IP
Address” — the encapsulating IP datagram containing the packet containing
the message does. And the message MAY have an Originator Address

AODVv2: Updated to say “the source IP address of the IP packet containing
the message advertising...”