Subject: [manet] #33 (aodvv2): RFC 5444 processing constraint

From: "manet issue tracker" <[email-masked]>
Date: Thu, 03 Apr 2014 21:31:08 -0000

#33: RFC 5444 processing constraint

 (Thomas Clausen)
 I have a general concern about how this protocol imposes constraints
 on RFC5444 usage, which precludes co-existence with other RFC5444
 protocols running on the same device.

 Let me give an example hereof, from Section 5.4:

 {{{
                 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), and the
                 IP destination is multiple hops away, it becomes
 infeasible
                 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.
 }}}

 An RFC5444 packet is *never* to be sent more than one hop.
 ... A router receives an RFC5444 packet, decapsulates
 it, process each message (if appropriate), the owner process of each
 message identifies which messages are to be forwarded (if appropriate),
 hands those off to the appropriate "message multiplexing engine" which
 packs those messages up in a new RFC5444 packet, and transmits that
 new RFC5444 packet.

 Also, in RFC5444 messages, addresses are contained in address blocks.
 There is no semantics associated with an address being in one address
 block, or in another (in fact, (re-)organising addresses into address
 blocks is one of the tricks to use to obtain more compact messages).
 Likewise, there is no semantics associated with an address being first,
 last, or in any other position in an address block: the ordering of
 addresses in an address block carries no semantics.

 Therefore, writing something like this:

 {{{
                 RteMsg.Address[i] denotes the [i]th address in an RFC 5444
                 AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the
                 associated prefix length for RteMsg.Address[i], and
                 RteMsg.{field} denotes the corresponding value in the
 named
                 AddrTLV block associated with RteMsg.Address[i].
 }}}

 makes no sense whatsoever (aside from the fact that I do not understand
 the notation !RteMsg.{field} - that would indicate a "field" in a
 message, not in an attribute associated with an address).

 Let me give one more example, from section 9:

 {{{
            If a message with an unknown type is received, the message is
            disregarded.
 }}}

 An implementation of this specification will (according to RFC5444)
 "own", and therefore get messages that this protocol has gotten
 assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK.  Messages of any
 other Message Types will not (again, according to RFC5444) be
 delivered to an implementation of this protocol.

 Therefore, this protocol <should not>
 specify discarding any message types other than those than it "owns".

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/33>
manet <http://tools.ietf.org/manet/>