Subject: [manet] RFC 5444 translation tables

From: Lotte Steenbrink <[email-masked]>
Date: Wed, 6 May 2015 18:30:40 +0200

Hi all,
as promised in today's interim meeting, the updated section on RFC 5444 messages in AODVv2. The idea is that this section merely details how to translate the generic AODVv2 packet format which is used throughout the draft into RFC 5444 messages. The primary goal was to make the representation more readable, but we've made some tweaks to the way data elements are encoded, too. I'd be very grateful about any feedback on both whether our representation is easy to understand (and what might be improved) as well as if there's anything that's illegal or could be arranged more elegantly in terms of RFC 5444-ish-ness. 
It's important to know that DEFAULT_METRIC_TYPE now has the value 0, so not supplying an exttype for MetricType implicitly sets the metric type to DEFAULT_METRIC_TYPE, which maps to Hop Count. Hop Count itself still has the value 3, so as to remain consistent with RFC6551 and enable the explicit declaration of hop count as the metric type. 

In case there's any other context missing, please let me know. Victoria has edited the draft pretty heavily to increase its readability and clarity, so once the new revision is out, it should help provide some more context, too.

Regards,
Lotte

---

From: Henning Rogge <[email-masked]>
Date: Wed, 6 May 2015 21:20:49 +0200

Hi,

just a few quick comments...

> 8.3.  RREP_Ack
>
> 8.3.1.  Message Header
>
>             +----------------+------------------+-----------+
>             | Data Element   | Header Field     | Value     |
>             +----------------+------------------+-----------+
>             | msg_hop_limit  | <msg-hop-limit>  | 1         |
>             | Message Type   | <msg-type>       | RREP_Ack  |
>             +----------------+------------------+-----------+

Setting msg_hop_limit to 1 is similar to not setting the field at all.
Not setting it at all saves 1 byte. ;)

> 8.4.  RERR
>
> 8.4.2.  Message TLV Block
>
>   A RERR may contain the PktSource message TLV as detailed in
>   Section 7.4.
>
>   +-------------+-----------+-----------+-----------------------------+
>   | Data        | TLV Type  | Extension | Value                       |
>   | Element     |           | Type      |                             |
>   +-------------+-----------+-----------+-----------------------------+
>   | PktSource   | PktSource | 0         | The source IP address of    |
>   | (optional)  |           |           | the packet triggering RERR  |
>   |             |           |           | generation.                 |
>   +-------------+-----------+-----------+-----------------------------+

Putting the Packet Source into an message TLV prevents you from compressing it.

Henning Rogge

On Wed, May 6, 2015 at 6:30 PM, Lotte Steenbrink
<[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 7 May 2015 10:00:40 +0000

There is a style question that all existing TLVs have names like LINK_STATUS, while here TLVs have names like OrigSeqNum. I don't think IANA enforce such issues, and different people will have different opinions on the importance of consistent style. (Naming can matter, we're spending cycles on an ID just about TLV names.)

(I haven't checked if planning to use message specific TLV numbering range.)

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Lotte Steenbrink
Sent: 06 May 2015 17:31
To: [email-masked]
Subject: [manet] RFC 5444 translation tables

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Consider carefully whether you should click on any
links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi all,

Regards,
Lotte

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Lotte Steenbrink <[email-masked]>
Date: Wed, 13 May 2015 15:55:00 +0200

Hi Christopher,
thanks for your feedback.

Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) <[email-masked]>:

> There is a style question that all existing TLVs have names like LINK_STATUS, while here TLVs have names like OrigSeqNum. I don’t think IANA enforce such issues, and different people will have different opinions on the importance of consistent style. (Naming can matter, we’re spending cycles on an ID just about TLV names.)
>  

Absolutely. In your opinion, would it suffice to adjust the current names stylistically (see attached file), or do some names need extra work in terms of clarification or consistency? (I was just wondering if METRIC should be edited to make clear that it is not directly related to LINK_METRIC...)

Regards,
Lotte

> (I haven’t checked if planning to use message specific TLV numbering range.)
>  
> --
> 
> Christopher Dearlove
> T:  +44 (0)1245 242194  |  E: [email-masked]
> 
> www.baesystems.com/ai

---

From: Henning Rogge <[email-masked]>
Date: Wed, 13 May 2015 16:10:54 +0200

On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink
<[email-masked]> wrote:
> There is a style question that all existing TLVs have names like
> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don’t think IANA
> enforce such issues, and different people will have different opinions on
> the importance of consistent style. (Naming can matter, we’re spending
> cycles on an ID just about TLV names.)
>
>
>
> Absolutely. In your opinion, would it suffice to adjust the current names
> stylistically (see attached file), or do some names need extra work in terms
> of clarification or consistency? (I was just wondering if METRIC should be
> edited to make clear that it is not directly related to LINK_METRIC...)

Maybe the name "PATH_METRIC" would make sense for the new TLV... this
describes the usage of the TLV very well.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 13 May 2015 14:33:00 +0000

I don't have time to look at this today, but Henning's suggestion looks good.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 13 May 2015 15:11
To: Lotte Steenbrink
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] RFC 5444 translation tables

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink <[email-masked]> wrote:
> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don’t think 
> IANA enforce such issues, and different people will have different 
> opinions on the importance of consistent style. (Naming can matter, 
> we’re spending cycles on an ID just about TLV names.)
>
>
>
> Absolutely. In your opinion, would it suffice to adjust the current 
> names stylistically (see attached file), or do some names need extra 
> work in terms of clarification or consistency? (I was just wondering 
> if METRIC should be edited to make clear that it is not directly 
> related to LINK_METRIC...)

Maybe the name "PATH_METRIC" would make sense for the new TLV... this describes the usage of the TLV very well.

Henning Rogge

---

From: Lotte Steenbrink <[email-masked]>
Date: Wed, 13 May 2015 19:13:54 +0200

Hi all,
FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses all comments made in this thread. Any feedback is very welcome!

Regards,
Lotte

---

From: Jiazi YI <[email-masked]>
Date: Tue, 26 May 2015 01:19:51 +0200

If I understand well, we still need the existence and the order in the
address block, to identify the usage of addresses?

For example, section 8.1:

8.1.3 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09#section-8.1.3>.
Address Block

   A RREQ contains two Addresses, OrigAddr and TargAddr, and each
   address has an associated prefix length.

        +-------------------------+------------------------------+
        | Data Elements           | Address Block                |
        +-------------------------+------------------------------+
        | OrigAddr/OrigPrefixLen  | <address> + <prefix-length>  |
        | TargAddr/TargPrefixLen  | <address> + <prefix-length>  |
        +-------------------------+------------------------------+

We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the
only address block TLV for TargAddr (TargSeqNum) is optional. It means
if we don't have the TargSeqNum TLV, according to RFC5444, we won't be
able to know what's the TargAddr.

best

Jiazi

On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink <
[email-masked]> wrote:

> Hi all,
> FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses
> all comments made in this thread. Any feedback is very welcome!
>
> Regards,
> Lotte
>
> > ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> > Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 27 May 2015 10:23:49 +0100

Hi Jiazi, and thanks for your comments,

This is part of an ongoing discussion. The current draft implies that
because there are two addresses in a RREQ, then if one is marked as
OrigAddr by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the
other address must be TargAddr. i.e in a RREQ, we can interpret an address
without an associated TLV as TargAddr. By doing it this way, we save the
length of the TLV we might have associated with TargAddr. Further, this
applied to other messages - the meaning of an unmarked address is deduced
from the message type. For RREP, an address without an associated TLV is
OrigAddr. For RERR, all unmarked addresses are unreachable destinations. In
RERR, we mark the PktSource address with its own PktSource (PKT_SOURCE) TLV
to differentiate from the unreachable addresses.

If in future, we decided to add an new type of address into a message for
some reason, that address MUST have a TLV associated with it to
differentiate. That makes sense anyway, we would want to indicate what the
new address means.

The question is, is this acceptable? If not, maybe we have to accept adding
a TLV to each of these messages so that there are no addresses without
associated any Address Block TLVs.

Also, the order of addresses in the Address Block doesn't matter in either
case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section
8, page 46):
"The addresses in an Address Block may appear in any order, and values
   in an Address Block TLV must be associated with the correct address
   in the Address Block.  To indicate which address each value is
   associated with, the AODVv2 message representation uses lists where
   the order of the addresses in the AddressList matches the order of
   values in the other lists, e.g., SeqNumList in a RERR."
Is this unclear?

Kind regards,
Victoria.

On Tue, May 26, 2015 at 12:19 AM, Jiazi YI <[email-masked]> wrote:

> 8.1.3 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09#section-8.1.3>.  Address Block
>
> We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the only address block TLV for TargAddr (TargSeqNum) is optional. It means if we don't have the TargSeqNum TLV, according to RFC5444, we won't be able to know what's the TargAddr.
>
>
> best
>
>
> Jiazi
>
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 27 May 2015 11:00:50 +0000

Actually, you save I think two bytes not having a target address. For significant loss of extensibility.

Two bytes?

Currently you can have a valueless TLV. It needs a single address index, no length or value.
Instead you can have a TLV with two values for the two address types. Using a multivalue TLV it needs no indices, a single byte length (2) and two value bytes.

Extensibility? You can add additional addresses with other meanings in future extensions. You can use the 254 unallocated (or 253, having an UNSPECIFIED value of 255 as in RFC 7188 is also a good idea) values for this in some cases.

It is also compatible with existing generic 5444 parsers approaches.

From: manet [mailto:[email-masked]] On Behalf Of Victoria Mercieca
Sent: 27 May 2015 10:24
To: Jiazi YI
Cc: manet
Subject: Re: [manet] RFC 5444 translation tables

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Hi Jiazi, and thanks for your comments,

This is part of an ongoing discussion. The current draft implies that because there are two addresses in a RREQ, then if one is marked as OrigAddr by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the other address must be TargAddr. i.e in a RREQ, we can interpret an address without an associated TLV as TargAddr. By doing it this way, we save the length of the TLV we might have associated with TargAddr. Further, this applied to other messages - the meaning of an unmarked address is deduced from the message type. For RREP, an address without an associated TLV is OrigAddr. For RERR, all unmarked addresses are unreachable destinations. In RERR, we mark the PktSource address with its own PktSource (PKT_SOURCE) TLV to differentiate from the unreachable addresses.

If in future, we decided to add an new type of address into a message for some reason, that address MUST have a TLV associated with it to differentiate. That makes sense anyway, we would want to indicate what the new address means.

The question is, is this acceptable? If not, maybe we have to accept adding a TLV to each of these messages so that there are no addresses without associated any Address Block TLVs.

Also, the order of addresses in the Address Block doesn't matter in either case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section 8, page 46):

Kind regards,
Victoria.

On Tue, May 26, 2015 at 12:19 AM, Jiazi YI <[email-masked]<mailto:[email-masked]>> wrote:
If I understand well, we still need the existence and the order in the address block, to identify the usage of addresses?

8.1.3<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09#section-8.1.3>.  Address Block

best

Jiazi

On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses all comments made in this thread. Any feedback is very welcome!

Regards,
Lotte

Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:

> T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>
>
> From: Henning Rogge [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: 13 May 2015 15:11
> To: Lotte Steenbrink
> Cc: Dearlove, Christopher (UK); [email-masked]<mailto:[email-masked]>
> On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink <[email-masked]<mailto:[email-masked]>> wrote:
>> Hi Christopher,
>> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK)
>> <[email-masked]<mailto:[email-masked]>>:
>>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 27 May 2015 13:35:02 +0200

Hi,

there is one major and one minor problem with "no TLVs attached to address".

The minor problem is that it forces the AODV2 parser to be aware of
ALL possible TLVs. Normally each protocol does only need to care about
the TLVs it uses itself, but in this case you need to make sure there
is no other unknown TLV.

The major problem is that the "no TLV" mechanism blocks any extension
related to the address. What if we want a cryptographic signature
attached to RERR unreachable addresses in the future? Or some other
additional data? This would force a break of compatibility with the
current draft.

Because of these two reasons the protocol should always have a TLV
that gives an address a meaning, this way it can ignore any unknown
TLVs attached to the address AND ignore addresses which have no known
TLVs, which makes extensions much easier.

Henning Rogge

On Wed, May 27, 2015 at 11:23 AM, Victoria Mercieca
<[email-masked]> wrote:
> because there are two addresses in a RREQ, then if one is marked as OrigAddr
> by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the other address
> must be TargAddr. i.e in a RREQ, we can interpret an address without an
> associated TLV as TargAddr. By doing it this way, we save the length of the
> TLV we might have associated with TargAddr. Further, this applied to other
> messages - the meaning of an unmarked address is deduced from the message
> type. For RREP, an address without an associated TLV is OrigAddr. For RERR,
> all unmarked addresses are unreachable destinations. In RERR, we mark the
> PktSource address with its own PktSource (PKT_SOURCE) TLV to differentiate
> from the unreachable addresses.
>
> case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section 8,
> page 46):
>> 8.1.3.  Address Block
>> We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the only
>> address block TLV for TargAddr (TargSeqNum) is optional. It means if we
>> don't have the TargSeqNum TLV, according to RFC5444, we won't be able to
>> know what's the TargAddr.
>>
>>
>> best
>>
>>
>> Jiazi
>>
>>
>>
>>
>> On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink
>>> > originates from outside our organisation, either from an external partner or
>>> > from the internet.
>>> >> <[email-masked]>:
>>> >>

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 27 May 2015 13:51:11 +0100

Hi Chris,

Thanks for your comments also.

> Currently you can have a valueless TLV. It needs a single address index,

 Instead you can have a TLV with two values for the two address types.
> Using a multivalue TLV it needs no indices, a single byte length (2) and
> two value bytes.
>
>
Like an "address meaning" TLV? And using just one of these TLVs in each
message, mark each address in the address block? I've just found Section C2
in RFC5444 -

Assume the definition of an Address Block TLV with type EXAMPLE1 (and
   no type extension) that has single octet values per address.  There
   are a number of ways in which values a, a, b, and c may be associated
   with the four addresses in the preceding Address Block, where c is a
   default value that can be omitted.

   Examples:

   Using one multivalue TLV to cover all of the addresses:
      *  <tlv-flags> has thasvalue and tismultivalue set (value 20);
      *  <index-start> and <index-stop> are omitted;
      *  <length> = 4 (single-length = 1).
      *  The TLV is then EXAMPLE1 20 4 a a b c (7 octets).

So we would define values a b c d, where "a" represents OrigAddr, "b"
represents TargAddr, "c" represents an unreachable address in RERR,
and "d" represents a PktSource address?

Then separately add TLVs relating to metrics, sequence numbers, etc.?
...and we wouldnt need three kinds of SEQ_NUM TLV for this, we could
just use SEQ_NUM, and have multi-values if necessary.

Did I understand that correctly?

Kind regards,

Victoria.

>
> Extensibility? You can add additional addresses with other meanings in
> future extensions. You can use the 254 unallocated (or 253, having an
> UNSPECIFIED value of 255 as in RFC 7188 is also a good idea) values for
> this in some cases.
>
>
>
> *-- *
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Victoria
> Mercieca
> *Sent:* 27 May 2015 10:24
> *To:* Jiazi YI
> *Cc:* manet
> *Subject:* Re: [manet] RFC 5444 translation tables
>
>
>
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> The question is, is this acceptable? If not, maybe we have to accept
> adding a TLV to each of these messages so that there are no addresses
> without associated any Address Block TLVs.
>
>
>
>  8.1.3
> <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09#section-8.1.3>.
> Address Block
>
>
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 27 May 2015 13:08:39 +0000

Yes, I believe you did understand. I believe that shortly you (everyone) will have some additional material that I hope will also be helpful.

From: Victoria Mercieca [mailto:[email-masked]]
Sent: 27 May 2015 13:51
To: Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] RFC 5444 translation tables

*** WARNING ***

On Wed, May 27, 2015 at 12:00 PM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Actually, you save I think two bytes not having a target address. For significant loss of extensibility.

Two bytes?

Like an "address meaning" TLV? And using just one of these TLVs in each message, mark each address in the address block? I've just found Section C2 in RFC5444 -

   Examples:

So we would define values a b c d, where "a" represents OrigAddr, "b" represents TargAddr, "c" represents an unreachable address in RERR, and "d" represents a PktSource address?

Then separately add TLVs relating to metrics, sequence numbers, etc.? ...and we wouldnt need three kinds of SEQ_NUM TLV for this, we could just use SEQ_NUM, and have multi-values if necessary.

Kind regards,

Victoria.

From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Victoria Mercieca
Sent: 27 May 2015 10:24
To: Jiazi YI
Cc: manet
Subject: Re: [manet] RFC 5444 translation tables

*** WARNING ***

Kind regards,
Victoria.

best

Jiazi

Regards,
Lotte

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 27 May 2015 09:15:10 -0700

Hello Chris,

> significant loss of extensibility.

I do not see the loss of extensibility.  Could you provide an example 
where the existing design prevents extensibility?

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 27 May 2015 18:19:58 +0200

> significant loss of extensibility.

Like I said in my earlier post, you would be (as an example) be unable
to add a signature to this address. Because this would require to add
a TLV. In fact you will be unable to add anything to this addresses.

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 27 May 2015 10:29:34 -0700

Hello Henning,

Do you mean it is not extensible because one could not add any additional
information to (in this example) the target address?  I don't think that 
is true.

Do you mean it is not extensible because one could not add more addresses?
I also do not think that is true.

Before going into greater detail, I wanted to find out more about the 
problem
you have in mind.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 27 May 2015 19:42:59 +0200

On Wed, May 27, 2015 at 7:29 PM, Charlie Perkins
<[email-masked]> wrote:
> information to (in this example) the target address?  I don't think that is
> true.

If you define "address X triggers behavior Y because it has no TLVs
attached" you cannot add TLVs to address X without breaking the
protocol. Even if the TLVs have no meaning for AODV2.

Henning

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 27 May 2015 10:59:29 -0700

Hello Henning,

The intention was, instead, to have
"address X triggers behavior Y because it has no OrigSeqNum TLV attached".

We do have TargSeqNum, and if in the future it is needed for 
extensibility, it can
be used.  If needed, we can include this sentence in the current 
specification
to guide future authors of new extensions.

Also I note that the basic address content of RREQ and RREP has not
changed in 20 years, unless you count path accumulation, the specification
of which still didn't at that time require both SeqNum TLVs to be included.
If history is any guide, we may not see the need for additional addresses
any time soon.  But if we do, they can be added.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 27 May 2015 20:03:17 +0200

> "address X triggers behavior Y because it has no OrigSeqNum TLV attached".

This doesn't make sense either...

how do you recognize an address added by an extension to the message?
It will have no OrigSeqNum TLV attached either because it is not meant
for your base protocol.

Henning

---

From: Jiazi YI <[email-masked]>
Date: Wed, 27 May 2015 23:26:41 +0200

Hi all,

> It will have no OrigSeqNum TLV attached either because it is not meant

I agree with Henning.

> any time soon.  But if we do, they can be added.

In different papers citing/extending AODV, I'm very sure that the authors
throw all kinds of weird stuff in the RREQ/RREP messages for different
reasons: security, backup routes, route repair, etc., etc., etc. I don't
agree with all of them, but people do that :)

best

Jiazi