Subject: [manet] #29 (aodvv2): Choice of IP address

From: "manet issue tracker" <[email-masked]>
Date: Thu, 03 Apr 2014 21:19:57 -0000

#29: Choice of IP address

 (Thomas Clausen) In a great many places, it is stated "IP address of the
 (node, Adjacent Node, Adjacent Router) sending the message".  If a router
 has multiple interfaces, and/or if these interfaces have multiple
 addresses, which of these (any? one matching the interface over which the
 message is sent?) should be used or assumed here? The relationship
 node/interface/address is, at best, unclear.  It seems to me that this
 specification is written with the assumption that each router has
 *exactly* one interface participating in the routing protocol, with
 *exactly* one IP address - and that that router *never* use anything but
 that IP Address for anything.

 If that is correct, then it should be written clearly in the applicability
 statement that multiple interfaces and multiple addresses are *NOT*
 supported, and that this protocol MUST NOT be used in deployments where
 any router can have more than one interface or more than one IP Address.

 If that's not true, then a major rework of the protocol and the
 specification is required.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/29>
manet <http://tools.ietf.org/manet/>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 24 Apr 2014 09:24:42 -0700

Hello folks,

>   that IP Address for anything.

When an application launches and has to send packets to a
destination, the application selects a source IP address.

That IP address is used by AODVv2 to indicate the originating
node, when initiating the Route Discovery operation (in the
case that a route to the intended destination is not found in
the route table).

When intermediate routers disseminate AODVv2 control
messages, they can use any IP address that is convenient
for the interface transmitting the message, as long as that
address is unique from the standpoint of the receiver(s).
Since the nodes are mobile, link-local addresses should be
excluded from use for this purpose.  I will clarify that in the
draft.  If, somehow outside the scope of the draft, it is
known that link-local addresses are unique for all time
for all ad hoc nodes that may enter the ad hoc network,
then perhaps that restriction could be disregarded, but
uniqueness is tough to guarantee for arbitrary mobile
nodes that might come into contact.

I will re-read the draft to see how to prevent the inference
that an interface can only have one IP address.

>   specification is required.

As far as I can tell, there is not really a problem here.

-- 
Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 24 Apr 2014 19:05:42 +0200

>>   that IP Address for anything. 

Just reflecting on what is quoted here, and without looking back at the I-D, talking about "the IP address of the adjacent node/router" very clearly indicates that the "adjacent node/router" has exactly one IP address (or, at least, uses exactly one IP address when participating in this routing domain).

> destination, the application selects a source IP address. 

User applications run on hosts, not on routers. So, that with which we are concerned should be exclusively "when a router receives an IP Datagram, with a given source and destination address"....

> case that a route to the intended destination is not found in 

So, this routing protocol precludes the presence of hosts in the network? Or, requires that all hosts also run (parts of) this routing protocol? Or the router with an attached host is expected to generate RREQs with the source address of the host as "source address" (i.e., IP spoofing)?  In the latter case, are RREP/RERRs sent "to" the IP Address  (i.e., with that as destination address) of the host (outside the routing domain)?

> address is unique from the standpoint of the receiver(s).

Just so that it is clear, that "convenient" IP address is used for what? The source IP address for the datagram that carries an RFC5444 packet? Or, something else....

Also, what happens in the case where A and B both have two interfaces (a1, a2) and (b1, b2) and all 4 interfaces can communicate with each other (so a1-b1, a1-b2, a2-b1, a2-b2)?

Any way for A to identify that b1 and b2 is, in fact, the same router? Are the consequences, if the answer is "there is no way" thought completely through?

> Since the nodes are mobile,

s/node/router

> link-local addresses should be
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Teco Boot <[email-masked]>
Date: Fri, 25 Apr 2014 16:54:15 +0200

Op 24 apr. 2014, om 19:05 heeft Thomas Heide Clausen <[email-masked]> het volgende geschreven:

> User applications run on hosts, not on routers.

???

Teco

(sent from router :-))

> So, that with which we are concerned should be exclusively "when a router receives an IP Datagram, with a given source and destination address"....
>

---

From: Jiazi YI <[email-masked]>
Date: Mon, 28 Apr 2014 00:29:59 +0200

On Fri, Apr 25, 2014 at 4:54 PM, Teco Boot <[email-masked]> wrote:

>
> Op 24 apr. 2014, om 19:05 heeft Thomas Heide Clausen <
> [email-masked]> het volgende geschreven:
>
> >
> > Just reflecting on what is quoted here, and without looking back at the
> I-D, talking about "the IP address of the adjacent node/router" very
> clearly indicates that the "adjacent node/router" has exactly one IP
> address (or, at least, uses exactly one IP address when participating in
> this routing domain).
> >

Or, I would rather say, a machine that runs as a host (when you are sending
the mail above).
The same machine may connect several networks and forward packets for
others - and it plays as a router :)

Jiazi

>
>
> > So, that with which we are concerned should be exclusively "when a
> router receives an IP Datagram, with a given source and destination
> address"....
> >
> > So, this routing protocol precludes the presence of hosts in the
> network? Or, requires that all hosts also run (parts of) this routing
> protocol? Or the router with an attached host is expected to generate RREQs
> with the source address of the host as "source address" (i.e., IP
> spoofing)?  In the latter case, are RREP/RERRs sent "to" the IP Address
>  (i.e., with that as destination address) of the host (outside the routing
> domain)?
> >
> > Just so that it is clear, that "convenient" IP address is used for what?
> The source IP address for the datagram that carries an RFC5444 packet? Or,
> something else....
> >
> > Also, what happens in the case where A and B both have two interfaces
> (a1, a2) and (b1, b2) and all 4 interfaces can communicate with each other
> (so a1-b1, a1-b2, a2-b1, a2-b2)?
> >
> > Any way for A to identify that b1 and b2 is, in fact, the same router?
> Are the consequences, if the answer is "there is no way" thought completely
> through?
> >
> >

---

From: Teco Boot <[email-masked]>
Date: Mon, 28 Apr 2014 07:01:22 +0200

Op 28 apr. 2014, om 00:29 heeft Jiazi YI <[email-masked]> het volgende geschreven:

> Or, I would rather say, a machine that runs as a host (when you are sending the mail above). 
> The same machine may connect several networks and forward packets for others - and it plays as a router :)

The node is a router. It doesn’t run as a host.

Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 28 Apr 2014 09:10:35 +0200

Teco, don't read something from my mail, which I didn't write..

As I think I have said repeatedly, "host" implies that certain relatively well defined characteristics (interface configuration, connectivity properties, etc.) are presented to applications.

Some applications -- possibly, your email client -- can also function when presented with other characteristics. Good for them, but that doesn't make it true for all.

Some routers - possibly the one you have at hand - are facing characteristics that are identical to those of a "host". Good for them, also, but that also doesn't make it true for all.

Sent from my iPad

> On 28 avr. 2014, at 07:01, Teco Boot <[email-masked]> wrote:
> 
>

---

From: Teco Boot <[email-masked]>
Date: Mon, 28 Apr 2014 09:53:51 +0200

Can you refer to a document that describes "certain relatively well defined characteristics”?

Are you aware of applications that doesn’t run wel on routers? What are the problems?

Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 28 Apr 2014 09:59:27 +0200

> On 28 avr. 2014, at 09:53, Teco Boot <[email-masked]> wrote:
> 

Sadly, I do not think that a single such document exists - remember the debacles in this area in [autoconf]?

> Are you aware of applications that doesn’t run wel on routers? What are the problems?

I can think of applications that doesn't run well on interfaces, common in routers -- such as those we see in MANETS (lacking transitivity, for example).

Thomas

---

From: Teco Boot <[email-masked]>
Date: Mon, 28 Apr 2014 11:39:32 +0200

> Sadly, I do not think that a single such document exists - remember the debacles in this area in [autoconf]?

Then, use RFC 1122. Defines multi-homed hosts and strong and weak host model.

> I can think of applications that doesn't run well on interfaces, common in routers -- such as those we see in MANETS (lacking transitivity, for example).

I think you mix up things. Apps can run on host and routers. Routers forward packets, hosts do not. Thats all.

Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 28 Apr 2014 11:45:47 +0200

> I think you mix up things. Apps can run on host and routers. Routers forward packets, hosts do not. Thats all.

Nope, you're wrong here Teco: applications on hosts "expect" certain things as to how interfaces/links are configured.

Thomas

---

From: Teco Boot <[email-masked]>
Date: Mon, 28 Apr 2014 12:04:09 +0200

> Nope, you're wrong here Teco: applications on hosts "expect" certain things as to how interfaces/links are configured.

The apps "expect" the same on host and router nodes: connectivity. If there is no direct link between two host or router nodes, routers can help by forwarding. 

Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 28 Apr 2014 12:05:17 +0200

> The apps "expect" the same on host and router nodes: connectivity. If there is no direct link between two host or router nodes, routers can help by forwarding. 

Some apps expect something more: semantics of on-link prefixes, LL multi/broadcast, ...

---

From: Teco Boot <[email-masked]>
Date: Mon, 28 Apr 2014 13:49:09 +0200

> Some apps expect something more: semantics of on-link prefixes, LL multi/broadcast, ...

Do "semantics of on-link prefixes, LL multi/broadcast, …" on router and host differ?

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 28 Apr 2014 14:14:21 +0200

On 28 Apr 2014, at 13:49 , Teco Boot <[email-masked]> wrote:

> Do "semantics of on-link prefixes, LL multi/broadcast, …" on router and host differ

I think that iTunes (for example) would be really really unhappy running over an NBMA-type interface.....or over a "MANET interface" lacking transitive connectivity.....or over an unnumbered interface...

---

From: Teco Boot <[email-masked]>
Date: Mon, 28 Apr 2014 14:36:17 +0200

> I think that iTunes (for example) would be really really unhappy running over an NBMA-type interface.....or over a "MANET interface" lacking transitive connectivity.....or over an unnumbered interf…

I didn’t see happy or unhappy apps. If iTunes can reach the Apple servers over whatever interface type (NBMA, "MANET interface”, unnumbered), why would the user be unhappy?
Tried bonjour in a subnetted network?

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 28 Apr 2014 14:39:01 +0200

[almost out of battery here, I may go quiet for a bit.....]

On 28 Apr 2014, at 14:36 , Teco Boot <[email-masked]> wrote:

> I didn’t see happy or unhappy apps

s/happy/able to work correctly/

> . If iTunes can reach the Apple servers over whatever interface type (NBMA, "MANET interface”, unnumbered), why would the user be unhappy?

Ah, but that is exactly the crux: what is the subnet model assumed by applications?

iTunes / bonjour et. al. assume that "the world looks like an Ethernet".

The interfaces of MANET routers do not look like an Ethernet.

---

From: Teco Boot <[email-masked]>
Date: Mon, 28 Apr 2014 16:21:42 +0200

Op 28 apr. 2014, om 14:39 heeft Thomas Heide Clausen <[email-masked]> het volgende geschreven:

> iTunes / bonjour et. al. assume that "the world looks like an Ethernet”.

Hmm, I’m using such apps a lot on non-Ethernet links. Again, as long as the destination is reachable, I am happy.
On bonjour, I don’t think you understand the problem. mDNS stuff doesn’t pass a router. So even interface type is Ethernet, users are not happy if destinations are unreachable.

> The interfaces of MANET routers do not look like an Ethernet.

I’m old enough to know old days ethernet doesn’t guarantee transitive connectivity.
I know the purpose of MANET routing. It helps solving problems with wireless links (written down in the valuable document Charlie and Emmanual produced in autoconf days). But let not mix up host and router. And let not pop up "host application”, it is meaningless.

---

From: Martin Heusse <[email-masked]>
Date: Tue, 29 Apr 2014 15:32:18 +0200

> nodes that might come into contact.

This is a bit self-contradictory: if you are able to ensure some kind of address uniqueness, then you should be able to ensure link-local uniqueness. This second condition is actually weaker: a link local address need only be unique over a possibly bridged domain. 

And then having link local uniqueness allows to follow the usual practice to use link local addresses as next hop, or as the source of routing messages. In this way, in case of network renumbering or whatnot, the neighbors'addresses don't change so the routing table does not have to be trashed. 

So it would seem much simpler to recommend the use of link local addresses, unless their uniqueness is not guaranteed -- and then anyway the recommendation is merely "good luck"!. I'm talking only about the addresses for further  dissemination of routing messages. 

Best regards,
Martin

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 29 Apr 2014 16:52:24 +0100

This (use of link local addresses) wasn't acceptable to several people whose opinions mattered during the autoconf discussions.

Doing this you end up making link local addresses visible throughout the MANET. Which is not link local, because to those people and their applications link local implies local on an ethernet-like subnet, i.e. with transitive, connectivity. Which the MANET does not have.

There are people to whom this is acceptable, and they can run their MANETs that way. But you are offering a massive hostage to fortune if you try recommending this, because if you find even one person on the IESG to whom this is not acceptable (and I think you will) you'll have at best a significant delay, at worst, an effectively blocked document.

(If you want to avoid problems with this or other documents, reading the not pretty history of autoconf and previous MANET RFCs may save you a lot of grief. Which as someone who has had some of it, i can advise avoiding.)

There are MANET local addresses in RFC 5498 IIRC. Might be worth looking at those. But how you ensure uniqueness, other than by centralised allocation before deployment, is a difficulty. It's worth noting that authentication (and you will need it to even get published) will also raise overlapping configuration questions.

---

From: Martin Heusse <[email-masked]>
Date: Tue, 29 Apr 2014 22:03:38 +0200

No. Not "throughout".
I was only talking about using link local address to exchange information with the "node" neighbors. And using them to identify the neighbor. 

Otherwise, I see your point. Thank you for the warning :-)

Martin

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 29 Apr 2014 23:47:45 +0100

Even then there is a danger. Suppose router A uses a link local address. If router B resends that link local address (for example to handshake with router A) then it can be heard by router C that can't hear (or be heard by) router A. Does that matter? Not to some, but it may to purists. Less likely to be a sticking point than a MANET-wide distribution of a link local address, but it might do. Care (and sounding things out, with your local friendly AD as a starting point) needed.

(That's what happens with NHDP. If you have any plan to allow use of NHDP as an option, then the issue arises.)

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

> On 29 Apr 2014, at 21:03, Martin Heusse <[email-masked]> wrote:
> 
> No. Not "throughout".

---

From: Martin Heusse <[email-masked]>
Date: Wed, 30 Apr 2014 11:31:20 +0200

Good point.

So, going back to my original remark, what it boils down to is:
- either one is able to enforce link local address uniqueness over the 2-hop neighborhood (at least) and then, link local addresses are the way to go;
- or you can't do that, and then one need some additional magic to attribute unique addresses to each node. And, in this case, the question is: why not apply this magic to link local addresses? 

Martin