Subject: [manet] Unidirectional links versus MIAs (multi-interface IP addresses)

From: Charlie Perkins <[email-masked]>
Date: Fri, 4 Mar 2016 20:39:39 -0800

Hello folks,

In order to enable routing over multi-interface addresses (call them 
MIAs) in the presence of uni-directional links, a node receiving a 
multicast packet has to be able to identify the sending interface of the 
transmitter.  For this purpose, it is natural to simply use the MAC address.

With this formulation, we then require that the node receiving a RREQ 
packet has to be able to identify the MAC address of the sender.  This 
seems to work well, and enables MIAs.   Then, if that node receives a 
RREP, it has to send to the MAC address from which the RREQ came.  The 
second part is natural because already routers already require MAC 
address information so that they can send packets.

So I propose that we store the MAC address along with the information in 
the Multicast Table.  We need to allow multiple *different* RREQ 
messages to be stored in that table, in case of receiving multiple RREQ 
messages from different sending MAC addresses of a device using MIAs.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Sat, 5 Mar 2016 07:52:34 +0100

Hi Charlie,

why do you need the MAC address? MAC addresses are always a pain to
use because the normal network APIs don't deliver them to you unless
you use a RAW socket, which spams your routing agent with all IP
traffic.

Shouldn't the combination of "outgoing local interface" and "remote IP
address" be enough to identify and reach the neighbor?

Henning Rogge

On Sat, Mar 5, 2016 at 5:39 AM, Charlie Perkins
<[email-masked]> wrote:
>
> Hello folks,
>
> In order to enable routing over multi-interface addresses (call them MIAs)
> in the presence of uni-directional links, a node receiving a multicast
> packet has to be able to identify the sending interface of the transmitter.
> For this purpose, it is natural to simply use the MAC address.
>
> With this formulation, we then require that the node receiving a RREQ packet
> has to be able to identify the MAC address of the sender.  This seems to
> work well, and enables MIAs.   Then, if that node receives a RREP, it has to
> send to the MAC address from which the RREQ came.  The second part is
> natural because already routers already require MAC address information so
> that they can send packets.
>
> So I propose that we store the MAC address along with the information in the
> Multicast Table.  We need to allow multiple *different* RREQ messages to be
> stored in that table, in case of receiving multiple RREQ messages from
> different sending MAC addresses of a device using MIAs.
>
> Regards,
> Charlie P.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Rick Taylor <[email-masked]>
Date: Sat, 5 Mar 2016 09:43:40 +0000

Hi Charlie,

I think Henning is right.  The "outgoing local interface" is much easier to use as an identifier than MAC address, and removes any dependency on a specific layer-2 address format.  As you said in your note: "multi-interface addresses", i.e. the identifying tuple is { IP_address, Interface_Id }.

Rick

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 05 March 2016 06:53
To: Charlie Perkins
Cc: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Unidirectional links versus MIAs (multi-interface IP addresses)

Hi Charlie,

why do you need the MAC address? MAC addresses are always a pain to use because the normal network APIs don't deliver them to you unless you use a RAW socket, which spams your routing agent with all IP traffic.

Shouldn't the combination of "outgoing local interface" and "remote IP address" be enough to identify and reach the neighbor?

Henning Rogge

On Sat, Mar 5, 2016 at 5:39 AM, Charlie Perkins <[email-masked]> wrote:
> multicast packet has to be able to identify the sending interface of the transmitter.
> packet has to be able to identify the MAC address of the sender.  This seems to
> natural because already routers already require MAC address 
> information so that they can send packets.
>
> So I propose that we store the MAC address along with the information 
> in the Multicast Table.  We need to allow multiple *different* RREQ 
> messages to be stored in that table, in case of receiving multiple 
> RREQ messages from different sending MAC addresses of a device using MIAs.
>
> Regards,
> Charlie P.
>

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 5 Mar 2016 05:38:07 -0800

Hello Rick,

Using other interface identifiers, you'll need to find a way to restrict 
the transmission of messages to multicast addresses so that each 
outgoing interface is tagged with whatever other stuff you want.

MAC addresses are easier to use with multicast because layer 2 does it 
for you.

In my opinion, if RFC 5444 prevents detection of incoming MAC addresses 
for use in AODVv2 data structures, there is no realistic way to support 
MIAs.  Yes, it could be done, but it would be very expensive in 
signaling traffic and probably require major revisions that I cannot 
clearly predict right now.

Or, if you have a solution and text, please contribute.  I don't think 
it has been done before for wireless routers anyway.

Regards,
Charlie P.

---

From: [email-masked]
Date: Sat, 5 Mar 2016 14:53:02 +0100

> On Mar 5, 2016, at 14:38, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Rick,

<SNIP>

> In my opinion, if RFC 5444 prevents detection of incoming MAC addresses for use in AODVv2 data structures, there is no realistic way to support MIAs.

That has nothing to do with RFC5444 ! 

You did notice that Henning’s argument against using L2 addresses (https://mailarchive.ietf.org/arch/msg/manet/5BFkn1nYpYxbXUSP8CE6AozFlLE) didn’t mention RFC5444, right?

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 5 Mar 2016 14:04:28 +0000

RFC5444 is irrelevant to the point here.

We need an interface identifier. As a matter of practical engineering, you could use MAC address or anything else you have. We just don't need the choice hard specified. It's exactly what NHDP does.

But NHDP also ensures that identifier is local, router A doesn't want or need to know about router B's interface identifiers. I'd be very set against that, but with the same small restriction as NHDP, no need.

There is also then no interoperability issue, even if I use MAC address, Henning uses sequence numbers from zero, and whoever else uses a memory address, as our local identifiers.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 5 Mar 2016, at 13:38, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Rick,
> 
> Using other interface identifiers, you'll need to find a way to restrict the transmission of messages to multicast addresses so that each outgoing interface is tagged with whatever other stuff you want.
> 
> MAC addresses are easier to use with multicast because layer 2 does it for you.
> 
> In my opinion, if RFC 5444 prevents detection of incoming MAC addresses for use in AODVv2 data structures, there is no realistic way to support MIAs.  Yes, it could be done, but it would be very expensive in signaling traffic and probably require major revisions that I cannot clearly predict right now.
> 
> Or, if you have a solution and text, please contribute.  I don't think it has been done before for wireless routers anyway.
> 
> Regards,
> Charlie P.
> 
> 
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 7 Mar 2016 08:39:37 +0100

> But NHDP also ensures that identifier is local, router A doesn't want or need to know about router B's interface identifiers. I'd be very set against that, but with the same small restriction as NH…

You would be very set against "local identifiers" or against "letting
other routers know about your identifiers" ? ;)

> There is also then no interoperability issue, even if I use MAC address, Henning uses sequence numbers from zero, and whoever else uses a memory address, as our local identifiers.

Yes... as long as you don't need to share these identifiers you are good.

I have been looking for a SANE way to get the MAC address of incoming
UDP packets for ages... the only solution seems to be "use a RAW
socket and filter out the right UDP packets yourself", which sounds
insane.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 7 Mar 2016 07:53:25 +0000

Set against sharing them. Having them is fine.

> On 7 Mar 2016, at 07:39, Henning Rogge <[email-masked]> wrote:
>