Subject: Re: [manet] DLEP address semantics and in-the-wild examples

From: Rick Taylor <[email-masked]>
Date: Fri, 12 Nov 2021 17:10:07 +0000

Hi Brian,

Your first assumption is correct.  The MAC address of the interface the router uses to maintain the DLEP session is the MAC address used as a Destination identifier by its peers.  DLEP does not (currently) define an 'out-of-band mode' where the DLEP session is maintained on a different MAC address from the data-plane.

One could define an out-of-band mode by a router using a Destination Up message with an alternate data-plane MAC address, but that is currently not defined anywhere.

Cheers,

Rick

From: manet [mailto:[email-masked]] On Behalf Of Sipos, Brian J.
Sent: 25 October 2021 16:05
To: [email-masked]
Cc: Taylor, Rick
Subject: [manet] DLEP address semantics and in-the-wild examples

All,
I am in the process of investigating and implementing a DLEP router component and trying to figure out which sets of data items are available for which contexts (peer session vs. destinations) and how they must/may be interpreted.
Specifically, it's not fully clear to me what the IPvX and MAC Address data items [1] are allowed or required to represent for a peer (modem) or a destination (other router). My assumption is that the IPvX are addresses on which the router sends/receives traffic for forwarding on past the DLEP-informed link and the IPvX Attached Subnets are those to-be-forwarded nets, but the MAC Address is really an opaque identifier for the far-side destination and may or may not be an address actually associated with or seen by any of the routers.

In the Link Identifier extension [2] it's more explicitly stated that the MAC Address is supposed to be an address on the far-side router, but I don't see that same kind of language in the original DLEP document [1]. And since there is no signaling of the router MAC Address within the Session Initialization, I assume that it is implied that the MAC Address of the peer (router) used to establish the TCP connection is used for this purpose. For multi-interface routers there may be no relation between the MAC Address and it's routed-traffic IPvX addresses (if the router is talking DLEP on a different interface than the routed traffic), but if the MAC Address is supposed to be just an opaque identifier then this doesn't really matter.

I've been able to dig into the OONF [3] implementation of DLEP to see how it works, but this is just one implementation and not an authority of the correct or possible semantics.

Thanks for any clarification,
Brian S.

[1] https://www.rfc-editor.org/rfc/rfc8175.html
[2] https://www.rfc-editor.org/rfc/rfc8703.html
[3] https://github.com/OLSR/OONF

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Nov 2021 09:54:33 +0100

As long as the Radio/Router answers the ARP for the unicast IPs used
for both DLEP UDP and TCP, the MAC for them should not matter.

MAC addresses in DLEP in the default "bridging" mode are the router
end-to-end MACs... DLEP has to refer to these, otherwise the router
will not be able to make sense of the DLEP messages.

I am not sure what you mean by "out of band"... are you talking about
Layer-3 routing DLEP radios?

Henning

On Fri, Nov 12, 2021 at 6:10 PM Rick Taylor
<[email-masked]> wrote:
>
> Hi Brian,
>
>
>
> Your first assumption is correct.  The MAC address of the interface the router uses to maintain the DLEP session is the MAC address used as a Destination identifier by its peers.  DLEP does not (currently) define an ‘out-of-band mode’ where the DLEP session is maintained on a different MAC address from the data-plane.
>
>
>
> Specifically, it’s not fully clear to me what the IPvX and MAC Address data items [1] are allowed or required to represent for a peer (modem) or a destination (other router). My assumption is that the IPvX are addresses on which the router sends/receives traffic for forwarding on past the DLEP-informed link and the IPvX Attached Subnets are those to-be-forwarded nets, but the MAC Address is really an opaque identifier for the far-side destination and may or may not be an address actually associated with or seen by any of the routers.
>
>
>
> In the Link Identifier extension [2] it’s more explicitly stated that the MAC Address is supposed to be an address on the far-side router, but I don’t see that same kind of language in the original DLEP document [1]. And since there is no signaling of the router MAC Address within the Session Initialization, I assume that it is implied that the MAC Address of the peer (router) used to establish the TCP connection is used for this purpose. For multi-interface routers there may be no relation between the MAC Address and it’s routed-traffic IPvX addresses (if the router is talking DLEP on a different interface than the routed traffic), but if the MAC Address is supposed to be just an opaque identifier then this doesn’t really matter.
>
>
>
> I’ve been able to dig into the OONF [3] implementation of DLEP to see how it works, but this is just one implementation and not an authority of the correct or possible semantics.
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Rick Taylor <[email-masked]>
Date: Fri, 19 Nov 2021 09:09:01 +0000

Hi Henning,

I think we're agreeing here.

By "out of band" I meant that while developing modem simulators, I have come across routers that have an internal L2-switch, and wish to establish DLEP on their "control interface" but the data-plane uses a "data interface" (with a different MAC).  In this scenario, the modem uses the TCP MAC (learned via ARP) as the Destination ID, and then the data-plane traffic arrives from the router with a source MAC that doesn't match.  In my simulator I just drop this traffic (because it's not to or from a 'destination') which causes confusion amongst users.  In the real world, should the modem be sniffing the packets and learning new local destinations rather than them being signalled via DLEP?  It's a very corner-case example, but RFC8175 is quite silent on the correct behaviour.  

I suppose this behaviour should be captured by the mythical "DLEP implementation Experience" draft all of us agree needs writing when we have the cycles...

Cheers,

Rick

> -----Original Message-----
> From: Henning Rogge [mailto:[email-masked]]
> Sent: 19 November 2021 08:55
> To: Rick Taylor
> Cc: Sipos, Brian J.; [email-masked]; Taylor, Rick
> Subject: Re: [manet] DLEP address semantics and in-the-wild examples
> 
> > Your first assumption is correct.  The MAC address of the interface the
> router uses to maintain the DLEP session is the MAC address used as a
> Destination identifier by its peers.  DLEP does not (currently) define an ‘out-
> of-band mode’ where the DLEP session is maintained on a different MAC
> address from the data-plane.
> >
> >
> >
> > One could define an out-of-band mode by a router using a Destination Up
> message with an alternate data-plane MAC address, but that is currently not
> defined anywhere.
> >
> >
> >
> > Cheers,
> >
> >
> > Rick
> >
> >
> >
> > I am in the process of investigating and implementing a DLEP router
> component and trying to figure out which sets of data items are available for
> which contexts (peer session vs. destinations) and how they must/may be
> interpreted.
> >
> > Specifically, it’s not fully clear to me what the IPvX and MAC Address data
> items [1] are allowed or required to represent for a peer (modem) or a
> destination (other router). My assumption is that the IPvX are addresses on
> which the router sends/receives traffic for forwarding on past the DLEP-
> informed link and the IPvX Attached Subnets are those to-be-forwarded nets,
> but the MAC Address is really an opaque identifier for the far-side
> destination and may or may not be an address actually associated with or
> seen by any of the routers.
> >
> >
> >
> > In the Link Identifier extension [2] it’s more explicitly stated that the MAC
> Address is supposed to be an address on the far-side router, but I don’t see
> that same kind of language in the original DLEP document [1]. And since
> there is no signaling of the router MAC Address within the Session
> Initialization, I assume that it is implied that the MAC Address of the peer
> (router) used to establish the TCP connection is used for this purpose. For
> multi-interface routers there may be no relation between the MAC Address
> and it’s routed-traffic IPvX addresses (if the router is talking DLEP on a
> different interface than the routed traffic), but if the MAC Address is
> supposed to be just an opaque identifier then this doesn’t really matter.
> >
> >
> >
> > I’ve been able to dig into the OONF [3] implementation of DLEP to see how
> it works, but this is just one implementation and not an authority of the
> correct or possible semantics.
> >
> >
> >

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Nov 2021 10:11:09 +0100

I have done so with my current implementation... no real code change
necessary, just the options to put the DLEP UDP/TCP socket on a
different interface.

DLEP MUST deliver data-plane MACs in Destination-Up messages... the
DLEP-control-plane MACs are irrelevant for most things. I don't see a
reason to specify it, DLEP only cares about a layer-3 control
connection...

Henning