[aodvv2-discuss] Re: The interface a message was received on

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Sat, 30 Apr 2016 14:37:03 +0100

From the usage draft:



1.2.2 
<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-1.2.2>.
Multiplexing and Demultiplexing

   The primary purposes of the multiplexer are to:

   o  Accept messages from MANET protocols, which also indicate over
      which interface(s) the messages are to be sent, and to which
      destination address.



4.2 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.2>.
Packets and Messages

   o  Outgoing messages are then sent to the [RFC5444
<https://tools.ietf.org/html/rfc5444>] multiplexer.  The
      owning protocol MUST indicate which interface(s) the messages are
      to be sent on and their destination address, and MAY request that
      messages are kept together in a packet; the multiplexer SHOULD
      respect this request if at all possible.




Kind regards,

Vicky :)

On Sat, Apr 30, 2016 at 2:33 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:

Hello Vicky,

O.K., I will look to see how RFC 5444 provides a method to send across a
certain network interface.

Or if you happen to remember I would appreciate a small pointer...

No apologies needed, and thanks for helping me to understand your point of
view!

Regards,
Charlie P.

On 4/30/2016 6:21 AM, Victoria Mercieca wrote:

Ok, so this relates back into what 5444 will tell us.

However, in other places in the draft we use the interface, both storing
it in a route, and sending messages on certain interfaces. Has anyone
flagged up that this isn't possible? Sending on certain interfaces
definitely is since rfc5444 says so but I didn't see anything in 5444 or
the usage draft which says about receiving interface.

If I missed that in previous discussions then please accept my apologies
and carry on.

Kind regards,
Vicky.

On Sat, Apr 30, 2016 at 2:07 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:

Hello Vicky,

Follow-up below...

On 4/30/2016 4:39 AM, Victoria Mercieca wrote:

I'm sorry, I'm lost on this discussion. I thought we'd addressed it by
noting what interface a message was received on, and making sure to send a
response on the same interface.


As stated, this fixes the problem.

However, I don't have any understanding about how an AODVv2
implementation will be able to note what interface a message was received
on.

Please let me know if I missed something about how that happens.  Or, if
nobody cares!

Whenever such a requirement existed in the past, to my knowledge it was
always satisfied by either specialized IPv6 addresses or MAC addresses.
For MIA, the former is not available.


Regards,
Charlie P.



If this doesn't fix the problem, definitely get the discussion on MANET
and if its not too much trouble, state exactly what problem it solves, I
apologise but I feel like I don't have time to scroll back through the
archives. I think we have until Wednesday?

Kind regards,
Vicky.



On Fri, Apr 29, 2016 at 3:54 PM, Charlie Perkins <
<charles.perkins@xxxxxxxxxxxxx>charles.perkins@xxxxxxxxxxxxx> wrote:

Hello folks,

I could submit a design for using RFC 7182 for the end-to-end
authentication unless you folks already have a plan for that.

I would also be willing to carry on the discussion about multi-interface
IP address (MIA) handling unless something has been decided about that.  I
didn't see any follow-up to my previous discussion here or on the mailing
list, so I don't know the status.

Please let me know...

Regarding the MIA support, I think we ought to have a configuration
variable called MIA_SUPPORT.  If TRUE, then the platform would have to meet
certain requirements.  These can be formulated as requirements for
"interface ID" support, or support for MAC addresses.  In the former case,
I expect the requirement for support would be more invasive.  Supporting
MAC addresses is much more natural for the operating system platform.

Regards,
Charlie P.







Other related posts: