route command cannot set up route through point-to-point interface

[der Mouse]

Netbsd's route command seems to reject route through point-to-point
interface.

That's odd; it's always worked fine for me. Could you give a specific
example, showing the configuraitno, the route command attempted, and
the failure message?

I checked out difference of the source code between netbsd and
freebsd, and maked following patch.

I'm guessing here, trying to reverse-engineer the behaviour you don't
like from the patch, but it looks almost as though you're expecting to
specify the _local_, not _remote_, address of the .2. interface on the
route command. If so, I'd say the bug is in your expectations; in
other cases, the gateway given to route(8) is the (non-local) address
of the next-hop machine, not an address on the local machine.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by der Mouse

Netbsd's route command seems to reject route through point-to-point
interface.

That's odd; it's always worked fine for me. Could you give a specific
example, showing the configuraitno, the route command attempted, and
the failure message?

I checked out difference of the source code between netbsd and
freebsd, and maked following patch.

I'm guessing here, trying to reverse-engineer the behaviour you don't
like from the patch, but it looks almost as though you're expecting to
specify the _local_, not _remote_, address of the .2. interface on the
route command. If so, I'd say the bug is in your expectations; in
other cases, the gateway given to route(8) is the (non-local) address
of the next-hop machine, not an address on the local machine.

In principle, it should not be necessary to have local and remote
addresses on a point-to-point link at all. What route(8) incantation
sets the route in that case? Is it route add <destination> -interface
<something> ?

Dave

[der Mouse]

Post by David Young
In principle, it should not be necessary to have local and remote
addresses on a point-to-point link at all.

It's necessary if you expect to communicate between the nodes that
share the link, since otherwise they have no way to name one another.

For routing, addresses of some kind are necessary to tell the routing
code where to route packets, though there's no reason in principle it
couldn't be set up so as to make some kind of "the other end of
interface $IFNAME" thing a valid address for routing purposes. For our
purposes, use of (IP) addresses is compelled by the routing code's
insistence on using IP addresses to name route destinations.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven Bellovin]

Post by der Mouse

Post by David Young
In principle, it should not be necessary to have local and remote
addresses on a point-to-point link at all.

It's necessary if you expect to communicate between the nodes that
share the link, since otherwise they have no way to name one another.
For routing, addresses of some kind are necessary to tell the routing
code where to route packets, though there's no reason in principle it
couldn't be set up so as to make some kind of "the other end of
interface $IFNAME" thing a valid address for routing purposes. For our
purposes, use of (IP) addresses is compelled by the routing code's
insistence on using IP addresses to name route destinations.

It's not conceptually necessary to name both ends; indeed, if I
recall correctly Cisco routers are perfectly happy with unnumbered
interfaces. What is necessary is is that each node have one (or more)
IP addresses, and for the routing tables to point in the proper
direction. If I want to talk to host B, all I need to know is "send
it down this point-to-point link"; it's not really my concern whether
or not it's the host that's directly connected to that end.

Way back when, there was no parameter to route(8) to route to an
interface; you had to fake it by giving a 0 metric. The routing
subsystem was also organized to route to a gateway address, and all
interfaces had to have addresses. Given that, it was natural to
require two addresses when ifconfiging, but as you say, in principle
it's not necessary.

--Steve Bellovin, http://www.cs.columbia.edu/~smb






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

What is necessary is is that each node have one (or more) IP
addresses,

Even this much isn't really true, if (a) the node in question never
needs to be addressed directly (ie, it's just routing packets, not
being an endpoint), (b) you don't mind losing things like ICMPs that
might otherwise be emitted by it, and (c) all of its peers are content
without its having an address on the relevant interfaces.

Way back when, [...]. Given that, it was natural to require two
addresses when ifconfiging, but as you say, in principle it's not
necessary.

Even systems that do demand that .2. links have addresses don't always
demand that they have distinct addresses. I've got some systems on
which a single address is shared by multiple .2. endpoints. For
example, excerpted from "ifconfig -au" on one of my live systems just
now:

tun1: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1500
inet 10.0.5.1 --> 10.0.5.2 netmask 0xffffffff
tun2: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1500
inet 10.0.5.1 --> 10.0.5.3 netmask 0xffffffff
tun3: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
inet 10.0.5.1 --> 10.0.5.5 netmask 0xffffffff
tun4: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1500
inet 10.0.5.1 --> 10.0.5.6 netmask 0xffffffff
tun5: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1500
inet 10.0.5.1 --> 10.0.5.7 netmask 0xffffffff

I've also done something similar where the shared address also belongs
to a broadcast interface on the host, as in

le0: 10.0.1.1/24
tun0: 10.0.1.1 --> 10.0.2.1
tun1: 10.0.1.1 --> 10.0.3.1

For some purposes - eg, administrative purposes under some address
assignment schemes - a nondistinct address like this is as good as no
address.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de