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

From: "manet issue tracker" <[email-masked]>
Date: Tue, 23 Dec 2014 22:38:25 -0000

#29: Choice of IP address

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 On 4/24/2014 9:24 AM, Charles E. Perkins wrote:

 > On 4/3/2014 2:19 PM, manet issue tracker wrote:
 >> #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.
 >
 > 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.
 >>
 >>   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.
 >
 > As far as I can tell, there is not really a problem here.

 ============================================================================

 On 4/24/2014 10:05 AM, Thomas Heide Clausen wrote:
 > On 24 Apr 2014, at 18:24 , Charles E. Perkins <[email-masked]>
 wrote:

 >> On 4/3/2014 2:19 PM, manet issue tracker wrote:
 >>> #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.

 > 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).

 >> When an application launches and has to send packets to a
 >> 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"....

 >> 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).

 > 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)?

 >> 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).

 > 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

 ============================================================================

 On 4/25/2014 7:54 AM, Teco Boot wrote:
 >
 > Op 24 apr. 2014, om 19:05 heeft Thomas Heide Clausen
 >                    <[email-masked]> het volgende geschreven:

     .........
 >> On 24 Apr 2014, at 18:24 , Charles E. Perkins <[email-masked]>
 wrote:
     .........
 >>> When an application launches and has to send packets to a
 >>> destination, the application selects a source IP address.

 >> User applications run on hosts, not on routers.
 >
 > ???
 >
 > Teco
 >
 > (sent from router :-))

 ============================================================================

 On 4/27/2014 3:29 PM, Jiazi YI wrote:
 >
 >
 > 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:

 >     > User applications run on hosts, not on routers.
 >     ???
 >
 >     Teco
 >
 >     (sent from router :-))
 >
 > 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 :)

 ============================================================================

 On 4/27/2014 10:01 PM, Teco Boot wrote:
 >
 > 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

 ============================================================================

 On 4/28/2014 12:10 AM, Thomas Heide Clausen wrote:
 > 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.

 ============================================================================

 On 4/28/2014 12:53 AM, Teco Boot wrote:
 > 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

 ============================================================================

 On 4/28/2014 2:39 AM, Teco Boot wrote:
 >
 > Op 28 apr. 2014, om 09:59 heeft Thomas Heide Clausen
 <[email-masked]>
 > het volgende geschreven:
 >
 >>
 >>> On 28 avr. 2014, at 09:53, Teco Boot <[email-masked]> wrote:
 >>>
 >>> Can you refer to a document that describes "certain relatively well
 >>> defined characteristics”?
 >>
 >> 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.
 >
 >>
 >>> 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).
 >
 > I think you mix up things. Apps can run on host and routers. Routers
 forward
 > packets, hosts do not. Thats all.

 ==========================================================================

 Recent revisions of the specification should make this clear.  The
 distinction between hosts
 and routers may be determined to properly belong as a separate issue if
 further
 discussion is needed.  Therefore it is proposed to close this issue.

-- 
-----------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                 |      Status:  closed
 Priority:  minor                  |   Milestone:
Component:  aodvv2                 |     Version:
 Severity:  Active WG Document     |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+------------------------------------

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