4. Applicability Statement

The AODVv2 routing protocol is designed for stub (i.e., non-transit) or disconnected (i.e., from the Internet) mobile ad hoc networks (MANETs). AODVv2 handles a wide variety of mobility patterns by determining routes on-demand. AODVv2 also handles a wide variety of traffic patterns. In networks with a large number of routers, AODVv2 is best suited for relatively sparse traffic scenarios where any particular router forwards packets to only a small percentage of the AODVv2 routers in the network, due to the on-demand nature of route discovery and route maintenance.

Although AODVv2 is closely related to AODV [RFC3561], and has some of the features of DSR [RFC4728], AODVv2 is not interoperable with either of those other two protocols.

AODVv2 is applicable to memory constrained devices, since little routing state is maintained in each AODVv2 router. Only routing information related to routes between active sources and destinations is maintained, in contrast to proactive routing protocols that require routing information to all routers within the MANET be maintained.

AODVv2 supports routers with multiple interfaces, as long as each interface has its own IP address. In addition to routing for their local processes, AODVv2 routers can also route on behalf of other non-routing nodes (i.e., "hosts", or, in this document, "clients"), reachable via those interfaces. Any such node which is not itself an AODVv2 router SHOULD NOT be served by more than one AODVv2 router.

Multi-homing is difficult unless the sequence number is expanded to include the IP address as well as OwnSeqNum. Otherwise, comparing sequence numbers would not work to evaluate freshness. Even when the IP address is included, there isn't a good way to compare sequence numbers from different IP addresses, but at least a handling node can determine whether the two given sequence numbers are comparable. If the route table can store multiple routes for the same destination, then multi-homing can work with sequence numbers augmented by IP addresses.

AODVv2 routers perform route discovery to find a route toward a particular destination. Therefore, AODVv2 routers MUST must be configured to respond to RREQs for a certain set of addresses. When AODVv2 is the only protocol interacting with the forwarding table, AODVv2 MAY be configured to perform route discovery for all unknown unicast destinations.

At all times within an AODVv2 MANET, only one AODVv2 router SHOULD be serve any particular routing client. The coordination among multiple AODVv2 routers to distribute routing information correctly for a shared address (i.e. an address that is advertised and can be reached via multiple AODVv2 routers) is not described in this document. The AODVv2 router operation of shifting responsibility for a routing client from one AODVv2 router to another is mentioned in Appendix C. Each AODVv2 router, if serving router clients other than itself, is configured with information about the IP addresses of its clients. No AODVv2 router is required to have information about the relationship between any other AODVv2 router and its router clients. Address assignment procedures are entirely out of scope for AODVv2.

AODVv2 only utilizes bidirectional links. In the case of possible unidirectional links, either blacklists (see Section 5.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) of assuring and monitoring bi-directionality is recommended. Otherwise, persistent packet loss or persistent protocol failures could occur. The Cost(L) of bidirectional link L may depend upon the direction across the link for which the cost is measured.

The routing algorithm in AODVv2 may be operated at layers other than the network layer, using layer-appropriate addresses. The routing algorithm makes of some persistent state; if there is no persistent storage available for this state, recovery can impose a performance penalty in case of AODVv2 router reboots.

5. Data Structures

5.1. Route Table Entry

The route table entry is a conceptual data structure. Implementations may use any internal representation so long as it provides access to the same information as specified below.

Conceptually, a route table entry has the following fields:

Route.Address

The (host or network) destination address of the node(s) associated with the routing table entry

Route.PfxLen

The value is the length of the netmask/prefix. If the value of the Route.PfxLen is nonzero and different than the length of addresses in the address family used by the AODVv2 routers, the associated address is a routing prefix, rather than a host address.

Route.SeqNum

The AODVv2 SeqNum associated with a route table entry

Route.NextHopAddress

An IP address of the adjacent AODVv2 router on the path toward the Route.Address

Route.NextHopInterface

The interface used to send packets toward the Route.Address

Route.LastUsed

The time that this route was last used

Route.ExpirationTime

The time at which this route must expire

Route.Broken

A flag indicating whether this Route is broken. This flag is set to true if the next-hop becomes unreachable or in response to processing to a RERR (see Section 8.4)

Route.MetricType

The type of the metric for the route towards Route.Address

Route.Metric

The cost of the route towards Route.Address

A route table entry (i.e., a route) may be in one of the following states:

Active

An Active route is in current use for forwarding packets

Idle

An Idle route can be used for forwarding packets, even though it is not in current use

Expired

After a route has been idle for too long, it expires, and may no longer be used for forwarding packets

Broken

A route marked as Broken cannot be used for forwarding packets but still has valid destination sequence number information.

Timed

The expiration of a Timed route is controlled by the Route.ExpirationTime time of the route table entry, not MAX_IDLETIME. Until that time, a Timed route can be used for forwarding packets. Afterwards, the route must be Expired (or expunged).

The route's state determines the operations that can be performed on the route table entry. During use, an Active route is maintained continuously by AODVv2 and is considered to remain active as long as it is used at least once during every ACTIVE_INTERVAL. When a route is no longer Active, it becomes an Idle route. After a route remains Idle for MAX_IDLETIME, it becomes an Expired route; after that, the route is not used for forwarding, but the sequence number information can be maintained until the destination sequence number has had no updates for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old sequence number information is considered no longer valuable and the route is expunged.

MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 router MUST NOT transmit any routing messages. Thus, if all other AODVv2 routers expunge routes to the rebooted router after that time interval, the rebooted AODVv2 router's sequence number will not be considered stale by any other AODVv2 router in the MANET.

When the link to a route's next hop is broken, the route is marked as being Broken, and the route may no longer be used.

5.2. Bidirectional Connectivity During Route Discovery and Blacklists

To avoid repeated failure of Route Discovery, an AODVv2 router (HandlingRtr) handling a RREP message MAY attempt to verify connectivity to the next upstream router towards AODVv2 router originating an RREQ message, by including the Unicast Response Request message TLV (see Section 15.2) in the RREP. Any unicast packet will satisfy the Response Request, for example an ICMP REPLY message. If the verification fails, HandlingRtr SHOULD put the upstream neighbor in a blacklist. RREQs received from a blacklisted node SHOULD NOT be retransmitted by HandlingRtr. However, the upstream neighbor should not be permanently blacklisted; after a certain time (MAX_BLACKLIST_TIME), it should once again be considered as a viable upstream neighbor for route discovery operations.

For this purpose, a list of blacklisted nodes along with their time of removal should be maintained:

BlacklistNode

The IP address of the node that did not verify bidirectional connectivity.

BlacklistRmTime

The time at which BlacklistNode will be removed from the blacklist.

5.3. Router Clients and Client Networks

An AODVv2 router may offer routing services to other nodes that are not AODVv2 routers. The AODVv2 Sequence Number is (by definition) the same for the AODVv2 router and each of its clients.

For this purpose, a list of IP addresses nodes along with relevant prefixes must be configured on each AODVv2:

Client IP address

The IP address of the node that requires routing service from the AODVv2 router.

Client Prefix Length

The length of the routing prefix associated with the client IP address.

If the Client Prefix Length is not the full length of the Client IP address, then the prefix defines a Client Network. If an AODVv2 router is configured to serve a Client Network, then the AODVv2 router MUST serve every node that has an address within the range defined by the routing prefix of the Client Network. The list of Routing Clients for an AODVv2 router is never empty, since an AODVv2 router is always its own client as well.

5.4. AODVv2 Packet Header Fields and Information Elements

In its default mode of operation, AODVv2 uses the UDP port 269 [RFC5498] to carry protocol packets. In addition, IP Protocol Number 138 has been reserved for MANET protocols [RFC5498]. Most AODVv2 messages are sent with the IP destination address set to the link-local multicast address LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore, all AODVv2 routers MUST subscribe to LL-MANET-Routers [RFC5498] to receiving AODVv2 messages. In order to reduce multicast overhead, retransmitting multicast packets in MANETs SHOULD be done according to methods specified in [RFC6621]. AODVv2 does not specify which method should be used to restrict the set of AODVv2 routers that have the responsibility to retransmit multicast packets. Note that multicast packets MAY be sent via unicast. For example, this may occur for certain link-types (non-broadcast media), for manually configured router adjacencies, or in order to improve robustness.

The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 messages is set to 255. If a packet is received with a value other than 255, any AODVv2 message contained in the packet MUST be disregarded by AODVv2. This mechanism, known as "The Generalized TTL Security Mechanism" (GTSM) [RFC5082] helps to assure that packets have not traversed any intermediate routers.

IP packets containing AODVv2 protocol messages SHOULD be given priority queuing and channel access.

AODVv2 messages are transmitted in packets that conform to the packet and message format described in [RFC5444]. Here is a brief description of the format. [RFC5444]. The length of an address (32 bits for IPv4 and 128 bits for IPv6) inside an AODVv2 message is indicated by the msg-addr-length (MAL) in the msg-header, as specified in [RFC5444].

A packet formatted according to RFC5444 contains zero or more messages.

A message contains a message header, message TLV block, and zero or more address blocks.

Each address block may also have associated TLV blocks.

If a packet contains only a single AODVv2 message and no packet TLVs, it need not include a packet-header

When multiple messages are aggregated into a single packet according to RFC 5444 formatting, and the aggregation of messages is also authenticated (e.g., with IPsec), it becomes unfeasible to delete individual messages. In such cases, instead of deleting individual messages, they are maintained in the aggregation of messages, but simply ignored for further processing. In such cases where individual messages cannot be deleted, in this document "disregarded" means "ignored". Otherwise, any such "disregarded" AODVv2 messages SHOULD be deleted from the aggregated messages in the RFC 5444 packet.

5.5. AODVv2 Sequence Numbers

AODVv2 sequence numbers allow AODVv2 routers to evaluate the freshness of routing information. Proper maintenance of sequence numbers assures that the destination sequence number value stored by intermediate AODVv2 routers is monotonically increasing along any path from any source to the destination. As a consequence, loop freedom is assured.

Each AODVv2 router in the network MUST maintain its own sequence number (OwnSeqNum, a 16-bit unsigned integer). An AODVv2 router increments its OwnSeqNum as follows. Most of the time, OwnSeqNum is incremented by simply adding one (1). But to increment OwnSeqNum when it has the value of the largest largest possible number representable as a 16-bit unsigned integer (i.e., 65,535), it MUST be set to one (1). In other words, the sequence number after 65,535 is 1.

An AODVv2 router SHOULD maintain OwnSeqNum in persistent storage. If an AODVv2 router's OwnSeqNum is lost, it MUST take the following actions to avoid the danger of routing loops. First, the AODVv2 router MUST invalidate all route table entries, by setting Route.Broken for each entry. Furthermore the AODVv2 router MUST wait for at least MAX_SEQNUM_LIFETIME before transmitting or retransmitting any AODVv2 RREQ or RREP messages. If an AODVv2 protocol message is received during this waiting period, the AODVv2 router SHOULD perform normal route table entry updates. If a data packet is received for forwarding to another destination during this waiting period, the AODVv2 router MUST transmit a RERR message indicating that no route is available. At the end of the waiting period the AODVv2 router sets its OwnSeqNum to one (1) and begins performing AODVv2 protocol functions again.

5.6. Enabling Alternate Metrics

Route selection in AODVv2 MANETs depends upon associating metric information with each route table entry. When presented with candidate route update information, deciding whether to use the update involves evaluating the metric. Some applications may require the consideration of metric information other than Hop Count, which has traditionally been the default metric associated with routes in MANET. In fact, it is well known that reliance on Hop Count can cause selection of the worst possible route in many situations.

It is beyond the scope of this document to describe how applications specify route selection at the time they launch processing. One possibility would be to provide a route metric preference as part of the library routines for opening sockets. In view of the above considerations, it is important to enable route selection based on metric information other than Hop Count -- in other words, based on "alternate metrics". Each such alternate metric identifies a "cost" of using the associated route, and there are many different kinds of cost (latency, delay, financial, energy, etc.).

The most significant change when enabling use of alternate metrics is to require the possibility of multiple routes to the same destination, where the "cost" of each of the multiple routes is measured by a different alternate metric. The other change relevant to AODVv2 is that the method by which route updates are tested for usefulness has to be slightly generalized to depend upon a more abstract method of evaluation which, in this document, is named "Cost(R)", where 'R' is the route information to be evaluated. From the above, the route table information for 'R' must always include the type of metric by which Cost(R) is evaluated, so the metric type does not have to be shown as a distinct parameter for Cost(R). Since determining loop freedom is known to depend on comparing the Cost(R) of route update information to the Cost(R) of an existing stored route using the same metric, AODVv2 must also be able to invoke an abstract routine which in this document is called "LoopFree(R1, R2)". LoopFree(R1, R2) returns TRUE when, given that R2 is loop-free and Cost(R2) is the cost of route R2, Cost(R1) is known to guarantee loop freedom of the route R1. In this document, LoopFree(R1,R2) will only be invoked for routes R1 and R2 which use the same metric.

Generally, HopCount may still be considered the default metric for use in MANETs, notwithstanding the above objections. Each metric has to have a Metric Type, and the Metric Type is allocated by IANA as specified in [RFC6551]. Each Route has to include the Metric Type as part of the route table entry for that route. Hop Count has Metric Type assignment 3. The Cost of a route using Metric Type 3 is naturally the Hop Count between the router and the destination. For routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when Cost(R2) ≤ (Cost(R1) + 1). The specification of Cost(R) and LoopFree(R1,R2) for metric types other than 3 is beyond the scope of this document.

Whenever an AODV router receives metric information in an incoming message, the value of the metric is as measured by the transmitting router, and does not reflect the cost of traversing the incoming link. In order to simplify the description of storing accrued route costs in the route table, the Cost() function is also defined to return the value of traversing a link 'L'. In other words, the domain of the Cost() function is enlarged to include links as well as routes. For Metric Type 3, (i.e., the HopCount metric) Cost(L) = 1 for all links. The specification of Cost(L) for metric types other than 3 is beyond the scope of this document. Whether the argument of the Cost() function is a link or a route will, in this document, always be clear. As a natural result of the way routes are looked up according to conformant metric type, all intermediate routers handling a RteMsg will assign the same metric type to all metric information in the RteMsg.

For some metrics, a maximum value is defined, namely MAX_METRIC[i] where 'i' is the Metric Type. AODVv2 does not store routes that cost more than MAX_METRIC[i]. MAX_METRIC[3] is defined to be MAX_HOPCOUNT, where as before 3 is the Metric Type of the HopCount metric.

6. AODVv2 Operations on Route Table Entries

In this section, operations are specified for updating the route table due to timeouts and route updates within AODVv2 messages. The route update information in AODVv2 messages includes the destination IP address (DestIP), SeqNum and prefix length associated with DestIP, and the Metric from DestIP to the node transmitting the AODVv2 message. DestIP information and prefix length are encoded within an RFC 5444 Address Block, and the SeqNum and Metric associated with each DestIP are encoded in RFC 5444 AddrTLVs. Optionally, there may be AddedNode route updates included in AODVv2 messages, as specified in Section 13.7. In this section, RteMsg is either RREQ or RREP, RteMsg.Addr denotes the [i]th address in an RFC 5444 AddrBlk of the RteMsg, RteMsg.PfxLen denotes the associated prefix length for RteMsg.Addr, and RteMsg.{field} denotes the corresponding value in the named AddrTLV block associated with RteMsg.Addr. All SeqNum comparisons use signed 16-bit arithmetic.

6.1. Evaluating Incoming Routing Information

If the incoming RteMsg does not have a MetricTypeTLV, then the metric information contained by RteMsg is considered to be of type DEFAULT_METRIC_TYPE. Whenever an AODVv2 router (HandRtr) handles an incoming RteMsg (i.e., RREQ or RREP), for every relevant address (RteMsg.Addr) in the RteMsg, HandRtr searches its route table to see if there is a route table entry with the same MetricType of the RteMsg, matching RteMsg.Addr. If not, HandRtr creates a route table entry for RteMsg.Addr as described in Section 6.2. Otherwise, HandRtr compares the incoming routing information in RteMsg against the already stored routing information in the route table entry (Route) for RteMsg.Addr, as described below.

	 (RteMsg.SeqNum > Route.SeqNum) OR
	{(RteMsg.SeqNum == Route.SeqNum) AND
       [(RteMsg.Metric < Route.Metric) OR
       ((Route.Broken == TRUE) && LoopFree (RteMsg, Route))]}
		 

Suppose a route table entry (Route[RteMsg.Addr]) uses the same metric type as the incoming routing information, and contains Route.SeqNum, Route.Metric, and Route.Broken. Suppose the incoming routing information for Route.Addr is RteMsg.SeqNum and RteMsg.Metric. The incoming routing information is compared as follows:

1. Stale::

RteMsg.SeqNum < Route.SeqNum :
If RteMsg.SeqNum < Route.SeqNum the incoming information is stale. Using stale routing information is not allowed, since that might result in routing loops. HandRtr MUST disregard the routing information for RteMsg.Addr.

2. Unsafe against loops::

(TRUE != LoopFree (RteMsg, Route)) :
If RteMsg is not Stale (as in (1)), RteMsg.Metric is next considered to insure loop freedom. If (TRUE != LoopFree (RteMsg, Route)) (see Section 5.6), then the incoming RteMsg information is not guaranteed to prevent routing loops, and it MUST NOT be used.

3. Longer::

(RteMsg.Metric >= Route.Metric) && (Route.Broken==FALSE)
When RteMsg.SeqNum is the same as in a valid route table entry, and LoopFree (RteMsg, Route) assures loop freedom, incoming information still does not offer any improvement over the existing route table information if RteMsg.Metric ≥ Route.Metric. Using such incoming routing information to update a route table entry is not recommended.

4. Offers improvement::

Incoming routing information that does not match any of the above criteria is better than existing routing table information and SHOULD be used to improve the route table. The following pseudo-code illustrates whether incoming routing information should be used to update an existing route table entry as described in Section 6.2.

• it is more recent, or
• it is not stale and is shorter, or
• it can safely repair a broken route.

6.2. Applying Route Updates To Route Table Entries

To apply the route update, the route table entry is populated with the following information:

• Route.Address := RteMsg.Addr
• If (RteMsg.PfxLen != 0), then Route.PfxLen := RteMsg.PfxLen
• Route.SeqNum := RteMsg.SeqNum
• Route.NextHopAddress := IP.SourceAddress (i.e., an address of the node from which the RteMsg was received)
• Route.NextHopInterface is set to the interface on which RteMsg was received
• Route.Broken flag := FALSE
• If RteMsg.MetricType is included, then
  Route.MetricType := RteMsg.MetricType. Otherwise, Route.MetricType := DEFAULT_METRIC_TYPE.
• Route.MetricType := RteMsg.MetricType
• Route.Metric := RteMsg.Metric
• Route.LastUsed := Current_Time
• If RteMsg.VALIDITY_TIME is not included, then
  Route.ExpirationTime := MAXTIME, otherwise Route.ExpirationTime := Current_Time + RteMsg.VALIDITY_TIME

With these assignments to the route table entry, a route has been made available, and the route can be used to send any buffered data packets and subsequently to forward any incoming data packets for Route.Addr. An updated route entry also fulfills any outstanding route discovery (RREQ) attempts for Route.Addr.

6.3. Route Table Entry Timeouts

During normal operation, AODVv2 does not require any explicit timeouts to manage the lifetime of a route. However, the route table entry MUST be examined be before using it to forward a packet, as discussed in Section 8.1. Any required expiry or deletion can occur at that time. Nevertheless, it is permissible to implement timers and timeouts to achieve the same effect.

At any time, the route table can be examined and route table entries can be expunged according to their current state at the time of examination, as follows. Section 13.3) then the precursor lists must also be expunged at the same time that the route itself is expunged.

• An Active route MUST NOT be expunged.
• An Idle route SHOULD NOT be expunged.
• An Expired route MAY be expunged (least recently used first).
• A route MUST be expunged if (Current_Time - Route.LastUsed) >= MAX_SEQNUM_LIFETIME.
• A route MUST be expunged if Current_Time >= Route.ExpirationTime

If precursor lists are maintained for the route (as described in

7. Routing Messages RREQ and RREP (RteMsgs)

AODVv2 message types RREQ and RREP are together known as Routing Messages (RteMsgs) and are used to discover a route between an Originating and Target Node, denoted here by OrigNode and TargNode. The constructed route is bidirectional, enabling packets to flow between OrigNode and TargNode. RREQ and RREP have similar information and function, but have some differences in their rules for handling. The main difference between the two messages is that RREQ messages are typically multicast to solicit a RREP, whereas RREP is typically unicast as a response to RREQ.

When an AODVv2 router needs to forward a data packet from a node (OrigNode) in its set of router clients, and it does not have a forwarding route toward the packet's IP destination address (TargNode), the AODVv2 router (in this section, called RREQ_Gen) generates a RREQ (as described in Section 7.3) to discover a route toward TargNode. Subsequently RREQ_Gen awaits reception of an RREP message (see Section 7.4) or other route table update (see Section 6.2) to establish a route toward TargNode. The RREQ message contains routing information to enable RREQ recipients to route packets back to OrigNode, and the RREP message contains routing information enabling RREP recipients to route packets to TargNode.

7.1. Route Discovery Retries and Buffering

After issuing a RREQ, as described above RREQ_Gen awaits a RREP providing a bidirectional route toward Target Node. If the RREP is not received within RREQ_WAIT_TIME, RREQ_Gen may retry the Route Discovery by generating another RREQ. Route Discovery SHOULD be considered to have failed after DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for a RREP response to the final RREQ. After the attempted Route Discovery has failed, RREQ_Gen MUST wait at least RREQ_HOLDDOWN_TIME before attempting another Route Discovery to the same destination.

To reduce congestion in a network, repeated attempts at route discovery for a particular Target Node SHOULD utilize an binary exponential backoff.

Data packets awaiting a route SHOULD be buffered by RREQ_Gen. This buffer SHOULD have a fixed limited size (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES). Determining which packets to discard first is a matter of policy at each AODVv2 router; in the absence of policy constraints, by default older data packets SHOULD be discarded first. Buffering of data packets can have both positive and negative effects (albeit usually positive). Nodes without sufficient memory available for buffering SHOULD be configured to disable buffering by configuring BUFFER_SIZE_PACKETS == 0 and BUFFER_SIZE_BYTES == 0. Doing so will affect the latency required for launching TCP applications to new destinations.

If a route discovery attempt has failed (i.e., DISCOVERY_ATTEMPTS_MAX attempts have been made without receiving a RREP) to find a route toward the Target Node, any data packets buffered for the corresponding Target Node MUST BE dropped and a Destination Unreachable ICMP message (Type 3) SHOULD be delivered to the source of the data packet. The code for the ICMP message is 1 (Host unreachable error). If RREQ_Gen is not the source (OrigNode), then the ICMP is sent over the interface from which OrigNode sent the packet to the AODVv2 router.

7.2. RteMsg Structure

RteMsgs have the following general format:

    +---------------------------------------------------------------+
    |                     RFC 5444 Packet Header                    |
    +---------------------------------------------------------------+
    |             RFC 5444 Message Header <msg-hopcount>            |
    +---------------------------------------------------------------+
    |    RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV     |
    +---------------------------------------------------------------+
    |       RteAddrBlk {[1]:=RREQ.OrigNode,[2]:=RREQ.TargNode)}     |
    +---------------------------------------------------------------+
    |         RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum)        |
    +---------------------------------------------------------------+
    |              Added Node Address Block (Optional)              |
    +---------------------------------------------------------------+
    |                Added Node Address TLV (SeqNum)                |
    +---------------------------------------------------------------+
    |          Added Node Address TLV (Metric[MetricType])          |
    +---------------------------------------------------------------+

    +---------------------------------------------------------------+
    |                     RFC 5444 Packet Header                    |
    +---------------------------------------------------------------+
    |     RFC 5444 Message Header <msg-hoplimit> <msg-hopcount>     |
    +---------------------------------------------------------------+
    |      UnreachableNode AddrBlk (Unreachable Node addresses)     |
    +---------------------------------------------------------------+
    |             UnreachableNode SeqNum AddrBlk TLV                |
    +---------------------------------------------------------------+

      /-------------------------\
     / +----------------+        \
    /  |  AODVv2 Router |         \
    |  |  191.0.2.2/32  |         |
    |  +----------------+         |            Routable 
    |                       +-----+--------+   Prefix
    |                       |   Internet   |  /191.0.2/24
    |                       | AODVv2 Router| /
    |                       |  191.0.2.1   |/       /----------------\         
    |                       | serving net  +-------+     Internet     \  
    |                       |  191.0.2/24  |       \                  /  
    |                       +-----+--------+        \----------------/ 
    |         +----------------+  |
    |         |  AODVv2 Router |  |
    |         |  191.0.2.3/32  |  |
    \         +----------------+  /
     \                           /
      \-------------------------/

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PV=0 |  PF=0  | msg-type=RREQ | MF=4  | MAL=3 |  msg-size=24  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-size=24  | msg-hop-limit |      msg.tlvs-length=0        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   num-addr=2  |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Head (bytes for Orig & Target)|   Orig.Tail   |  Target.Tail  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      addr.tlvs-length=11      |  type=SeqNum  |0|1|0|1|0|0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Index-start=0 | tlv-length=2  |     Orig.Node Sequence #      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  type=SeqNum  |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | OrigNodeHopCt |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PV=0 |  PF=0  | msg-type=RREP | MF=4  | MAL=3 |  msg-size=30  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-size=30  | msg-hop-limit |      msg.tlvs-length=0        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   num-addr=2  |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Head (bytes for Orig & Target)|   Orig.Tail   |  Target.Tail  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      addr.tlvs-length=13      |  type=SeqNum  |0|1|0|1|0|0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Index-start=0 | tlv-length=2  |     Orig.Node Sequence #      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Target.Node Sequence #     |  type=Metric8 |0|1|0|1|0|0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Index-start=1 | tlv-length=1  | TargNodeHopCt |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PV=0 |  PF=0  | msg-type=RERR | MF=4  | MAL=3 |  msg-size=25  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-size=25  | msg-hop-limit |      msg.tlvs-length=0        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   num-addr=2  |1|0|0|0|0| Rsv | head-length=3 |Head(Two Dests)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Head (for both destinations)  |  Tail(Dest_1) | Tail(Dest_2)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      addr.tlvs-length=8       |  type=SeqNum  |0|1|0|1|0|0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Index-start=0 | tlv-length=2  |        Dest_1 Sequence #      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Dest_2 Sequence #      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PV=0 |  PF=0  |msg-type=RREPAk| MF=0  | MAL=3 |  msg-size=3   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-size=3   |
     +-+-+-+-+-+-+-+-+