Hello Stan,
In this case, I think that traditional routing protocols would have the
same problem if they had unidirectional links. We're still O.K. against
routing loops. Since we are trying to verify bidirectionality at layer
3, and thus using IP addresses, our algorithm either has to be be more
restrictive, or incorporate more data.
From the last sentence, there are two ways to fix the problem, for the
use cases that need such IP address operation.
Being more restrictive, we could specify that for each RREQ, the device
has to pick one of its interfaces using that IP address and send the
RREQ out from that interface. Then, the node has to check that the RREP
comes in over the same network interface that the RREQ went out from.
Each later RREQ could use a different outgoing interface if that's
desirable. But, out of all the node's interfaces using the same IP
address, only one can transmit (or retransmit) the RREQ.
The node has to keep track of the outgoing interface anyway in the route
table as usual, and this just guards against the ambiguity which would
otherwise arise.
An alternate solution would be to extend the RREQ packets with an
interface ID that is different for each interface using the same IP
address, and to require the RREP to incorporate that interface ID.
Intermediate nodes would also have to store that interface ID.
Do big iron routers with such IP address allocations have
uni-directional links?
Finally, I am O.K. with simply disallowing the node to use the same IP
address for multiple interfaces. It's not like we're running out of
IPv6 addresses any time soon.
Regards,
Charlie P.
On 3/2/2016 12:38 PM, Ratliff, Stanley wrote:
Charlie,
If the answer is “it actually already works, because <blah>” (in this case, because of the single sequence number), then great! That’s the answer.
Take a look at Justin’s email on uni-directional links, though – looks to me like he has a failing case, since traffic received on interface #1 would **always** need to be sent on interface #2. I didn’t think AODVv2 does that.
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Charlie Perkins
*Sent:* Wednesday, March 02, 2016 3:36 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] Fwd: Re: [manet] AODVv2 reivew
Hello folks,
Before I wade into unfriendly waters, can someone tell me why AODVv2 does not already support the same IP address on multiple interfaces? We already went over this more than once, and keeping a single sequence number for all IP addresses on the same device just works!
Right now I can't think of any problem with this, but if any of you remember please tell me.
Regards,
Charlie P.
-------- Forwarded Message --------
*Subject: *
Re: [manet] AODVv2 reivew
*Date: *
Wed, 2 Mar 2016 14:27:10 -0500
*From: *
Justin Dean <bebemaster@xxxxxxxxx> <mailto:bebemaster@xxxxxxxxx>
*To: *
Stan Ratliff <ratliffstan@xxxxxxxxx> <mailto:ratliffstan@xxxxxxxxx>
*CC: *
Dearlove, Christopher (UK) <chris.dearlove@xxxxxxxxxxxxxx> <mailto:chris.dearlove@xxxxxxxxxxxxxx>, Christopher Dearlove <chris@xxxxxxxxxxxxxxxxxxxxx> <mailto:chris@xxxxxxxxxxxxxxxxxxxxx>, manet@xxxxxxxx <mailto:manet@xxxxxxxx> <manet@xxxxxxxx> <mailto:manet@xxxxxxxx>
To me this isn't a big deal (unless it isn't fixed). Two ways to fix it. Disallow different interfaces to have the same address. Two mandate any interfaces with the same IP address MUST be bridged into a single logical interface (i.e. both interfaces send and receive the same traffic). Either way fixes the issue.
Justin
On Wed, Mar 2, 2016 at 2:22 PM, Stan Ratliff <ratliffstan@xxxxxxxxx <mailto:ratliffstan@xxxxxxxxx>> wrote:
On Wed, Mar 2, 2016 at 2:03 PM, Thomas Heide Clausen
<ietf@xxxxxxxxxxxxxxxxx <mailto:ietf@xxxxxxxxxxxxxxxxx>> wrote:
A question and a comment:
1) I thought this was about AODVv2, not DLEP, so I fail to seeÂ
   why it is relevant to bring DLEP into this discussion?
I was asked, implicitly, why *I* was pushing (since I was
repeatedly named) for a set of requirements *then*, and not so
*now* - specifically, support of ip unnumbered on interfaces. It's
relevant to explain that it was based on companion technology -
technology that I no longer require. I would think that was
self-evident. Apparently not.Â
Â
2) I think that the argument bring made here is the logical
fallacy called
     /"moving the goal posts"/.Â
You are correct in that there is a logical fallacy in play here.
Yours. All I've said is (and I quote): "I don’t have any great
issues with disallowing it." That's an *opinion*, not an *edict*;
nor does it connote moving of goal posts, or any other associated
hardware. At least I believe that, according to IETF rules, I
still get to express opinions, as a WG participant... or did some
RFC slip past that I'm not aware of?Â
Stan
Â
 Â
There are use cases for "same IP address on multiple
interfaces" and I believe they should be supported (as Chris
wrote that we did for OLSRv2 "to the maximum extend
possible"), also by this protocol.
Thomas
On 02 Mar 2016, at 17:02, Ratliff, Stanley
<sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>> wrote:
Chris,
Â
I’m digging deep into the memory banks here… ;-) But
from what I remember, there were discussions at my old
employer about the possibilities of implementing & running
OLSRv2 in the router. Our implementations at the time were
based on RFC5578 – a collection of PPPoE links, running
over an RF net. For that, “ip unnumberedâ€would have
been a requirement. Since DLEP is **not** PPPoE based,
it pretty much mitigates the requirement.
Â
Regards,
Stan
Â
Â
*From:*Christopher Dearlove
[mailto:chris@xxxxxxxxxxxxxxxxxxxxx]
*Sent:* Wednesday, March 02, 2016 10:55 AM
*To:* Ratliff, Stanley <sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx>>
*Cc:* Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx
<mailto:chris.dearlove@xxxxxxxxxxxxxx>>; Justin Dean
<bebemaster@xxxxxxxxx <mailto:bebemaster@xxxxxxxxx>>;
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
*Subject:* Re: [manet] AODVv2 reivew
Â
I'm not sure why the case was insisted on for OLSRv2
(though we were happy to oblige to the maximum extent
possible) and isn't required for AODVv2, but it wasn't my
requirement.
Â
As for the different addresses on different platforms, I
think we are agreed, it was the point I made. (Gateways
may be a related but different issue.)
--Â
Christopher Dearlove
christopher.dearlove@xxxxxxxxx
<mailto:christopher.dearlove@xxxxxxxxx>
On 2 Mar 2016, at 15:19, Ratliff, Stanley
<sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>> wrote:
Chris,
Â
To answer a question with a question – Will anyone
want to run AODVv2 over a collection of PPPoE links? I
doubt it. I don’t have any great issues with
disallowing it. That would also resolve Justin’s
uni-directional failure case, since the common
addresses wouldn’t be assigned to multiple
interfaces in the first place.
Â
Other thoughts?
Â
Regards,
Stan
Â
Â
*From:*Christopher Dearlove
[mailto:chris@xxxxxxxxxxxxxxxxxxxxx]
*Sent:* Wednesday, March 02, 2016 9:52 AM
*To:* Ratliff, Stanley <sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx>>
*Cc:* Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx
<mailto:chris.dearlove@xxxxxxxxxxxxxx>>; Justin Dean
<bebemaster@xxxxxxxxx <mailto:bebemaster@xxxxxxxxx>>;
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
*Subject:* Re: [manet] AODVv2 reivew
Â
The question is, is that important for AODVv2? Should
it allow it? Are there any problems?
Â
As I've just said in another post, the step beyond
that of routers sharing an address is a problem, but I
don't expect it to be relevant as people shouldn't do
it (it could be explicitly said). Though what I didn't
address there is the impact on gateways. We resolved
that in OLSRv2 with two different kinds of advertised
address, one shareable among routers, not tied to an
interface, one shareable among interfaces but only on
the same router and only if not commonly hearable.
-- Â
Christopher Dearlove
christopher.dearlove@xxxxxxxxx
<mailto:christopher.dearlove@xxxxxxxxx> (iPhone)
chris@xxxxxxxxxxxxxxxxxxxxx
<mailto:chris@xxxxxxxxxxxxxxxxxxxxx> (home)
On 2 Mar 2016, at 14:17, Ratliff, Stanley
<sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>>
wrote:
Chris,
Â
The use case comes from routers implementingip
unnumbered. It can cause the same address to be
placed on multiple interfaces. From what I recall,
its especially prevalent with PPPoE interfaces, as
they are virtual; cloned from a common template.
Â
Regards,
Stan
Â
Â
Â
In NHDP, we added (following requests from the WG,
Stan in particular IIRC) the more tricky case of
the same address used on different interfaces. We
had to limit that, so any receiving interface
would only ever receive one or the other (which
otherwise is not a requirement in NHDP) - which
might in a real case be e.g. different frequencies
(timeslots, codes, etc.) I have no idea whether
this is easy or hard in AODVv2 (the devil is in
the details). I don’t know if Stan (for example)
still has this requirement.
Â
*-- *
************************
_____________________________________________________
This electronic message and any files transmitted
with it contains
information from iDirect, which may be privileged,
proprietary
and/or confidential. It is intended solely for the
use of the individual
or entity to whom they are addressed. If you are
not the original
recipient or the person responsible for delivering
the email to the
intended recipient, be advised that you have
received this email
in error, and that any use, dissemination,
forwarding, printing, or
copying of this email is strictly prohibited. If
you received this email
in error, please delete it and immediately notify
the sender.
_____________________________________________________
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
This electronic message and any files transmitted with
it contains
information from iDirect, which may be privileged,
proprietary
and/or confidential. It is intended solely for the use
of the individual
or entity to whom they are addressed. If you are not
the original
recipient or the person responsible for delivering the
email to the
intended recipient, be advised that you have received
this email
in error, and that any use, dissemination, forwarding,
printing, or
copying of this email is strictly prohibited. If you
received this email
in error, please delete it and immediately notify the
sender.
_____________________________________________________
_____________________________________________________
This electronic message and any files transmitted with it
contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of
the individual
or entity to whom they are addressed. If you are not the
original
recipient or the person responsible for delivering the
email to the
intended recipient, be advised that you have received this
in error, and that any use, dissemination, forwarding,
printing, or
copying of this email is strictly prohibited. If you
received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
