Proxy ARP

[Ryota Ozaki]

Hi,

I have questions about the Proxy ARP feature.

arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Thanks in advance,
ozaki-r

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

[Christos Zoulas]

Post by Ryota Ozaki
Hi,
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Proxy arp (rfc1027) was used decades ago to make hosts whose
networking stacks did not understand subnetworking and routing
work (in my environment those were SVR2 machine AT&T 3b{2,5,10,20}s).
Typically we used to run a daemon on the gateway host that
watched for bogus arp requests (requests for addresses not in the
local broadcast domain/subnet that could not be satisfied) and
reply to them by saying that the gateway host(*) had the address
required and add this address to the arp table as a proxy entry.

I don't remember what was special about proxy arp entries, but my
guess is probably nothing; it was just a special marker to recognize
that these were added manually just for proxying.

The two plausible reasons would be:
- not to time them out (but that would not make sense
because proxyarpd did not have any timeout code, so these
would become permanent
- not to consult them for local routing decisions, but this
is not done anyway

You can still get a copy of a proxyarpd implementation from:

ftp://mirror.ucsd.edu/pub/proxyarpd-1.7.shar

christos

(*) It ended being more complicated than that for hosts with multiple
gateways. There was a "proxytab" file which said which
interfaces/ip-addresses where responsible for what subnets.


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

[Joerg Sonnenberger]

Post by Christos Zoulas

Post by Ryota Ozaki
Hi,
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Proxy arp (rfc1027) was used decades ago to make hosts whose
networking stacks did not understand subnetworking and routing
work (in my environment those were SVR2 machine AT&T 3b{2,5,10,20}s).

I have used it much more recently for VMs and the like. If you
configure the host machine to provide proxy ARP and use point-to-point
links for the individual machines, you can avoid having to run a full
blown bridge and naturally get isolation of the individual VMs without
having further MAC filtering. The host has the correct routes to speak
with the VMs and proxy ARP allows other machine on the outside network
to be ignorant of the internal subnetting.

I don't think this needs proxy flags on the kernel side though.

Post by Christos Zoulas
ftp://mirror.ucsd.edu/pub/proxyarpd-1.7.shar

Roy has one as well, it can be found in pkgsrc under net/parpd.

Joerg

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

[Roy Marples]

Post by Joerg Sonnenberger

Post by Christos Zoulas

Post by Ryota Ozaki
Hi,
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Proxy arp (rfc1027) was used decades ago to make hosts whose
networking stacks did not understand subnetworking and routing
work (in my environment those were SVR2 machine AT&T 3b{2,5,10,20}s).

I have used it much more recently for VMs and the like. If you
configure the host machine to provide proxy ARP and use point-to-point
links for the individual machines, you can avoid having to run a full
blown bridge and naturally get isolation of the individual VMs without
having further MAC filtering. The host has the correct routes to speak
with the VMs and proxy ARP allows other machine on the outside network
to be ignorant of the internal subnetting.
I don't think this needs proxy flags on the kernel side though.

Post by Christos Zoulas
ftp://mirror.ucsd.edu/pub/proxyarpd-1.7.shar

Roy has one as well, it can be found in pkgsrc under net/parpd.

So there exists two implementations in userland, one of which at least
is in pkgsrc.
Could we remove this feature from arp itself and the kernel to trim it
down some? Or is the need still there?

Roy

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

[Greg Troxel]

Post by Roy Marples

Post by Joerg Sonnenberger

Post by Christos Zoulas

Post by Ryota Ozaki
Hi,
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Proxy arp (rfc1027) was used decades ago to make hosts whose
networking stacks did not understand subnetworking and routing
work (in my environment those were SVR2 machine AT&T 3b{2,5,10,20}s).

I have used it much more recently for VMs and the like. If you
configure the host machine to provide proxy ARP and use point-to-point
links for the individual machines, you can avoid having to run a full
blown bridge and naturally get isolation of the individual VMs without
having further MAC filtering. The host has the correct routes to speak
with the VMs and proxy ARP allows other machine on the outside network
to be ignorant of the internal subnetting.
I don't think this needs proxy flags on the kernel side though.

Post by Christos Zoulas
ftp://mirror.ucsd.edu/pub/proxyarpd-1.7.shar

Roy has one as well, it can be found in pkgsrc under net/parpd.

So there exists two implementations in userland, one of which at least
is in pkgsrc.
Could we remove this feature from arp itself and the kernel to trim it
down some? Or is the need still there?

How much would we save in the kernel? This feels like only a few lines
of code, and it would remove a feature that some still use that dates
back to at least 4.2BSD.

I think it's still necessary (Joerg's VM example is the modern analog of
old dialup), and the basic few flags, slight behavior change seems
pretty straighforward.

Are the programs more about answering for arbitrary addresses, vs
publishing arp for specific hosts? Are they needed on NetBSD, for some
other use case, or are they portable for other systems too? Do they
use bpf?

[Ryota Ozaki]

(I'm sorry for my lazy replying...)

On Thu, Feb 25, 2016 at 11:24 PM, Joerg Sonnenberger

Post by Joerg Sonnenberger

Post by Christos Zoulas

Post by Ryota Ozaki
Hi,
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Proxy arp (rfc1027) was used decades ago to make hosts whose
networking stacks did not understand subnetworking and routing
work (in my environment those were SVR2 machine AT&T 3b{2,5,10,20}s).

I have used it much more recently for VMs and the like. If you
configure the host machine to provide proxy ARP and use point-to-point
links for the individual machines, you can avoid having to run a full
blown bridge and naturally get isolation of the individual VMs without
having further MAC filtering. The host has the correct routes to speak
with the VMs and proxy ARP allows other machine on the outside network
to be ignorant of the internal subnetting.

Could you teach me how to set up the configuration and how routes
and arp entries look? I want to know whether the use case is "pub"
one or "pub proxy" one and if it's "pub" one, how the route for
a proxy arp entry acts.

Thanks,
ozaki-r

Post by Joerg Sonnenberger
I don't think this needs proxy flags on the kernel side though.

Post by Christos Zoulas
ftp://mirror.ucsd.edu/pub/proxyarpd-1.7.shar

Roy has one as well, it can be found in pkgsrc under net/parpd.
Joerg

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

[Robert Elz]

Date: Mon, 7 Mar 2016 19:31:34 +0900
From: Ryota Ozaki <ozaki-***@netbsd.org>
Message-ID: <CAKrYomjaaRzpSKaDCq6hy049ZV=rcMCh-***@mail.gmail.com>

| > On Thu, Feb 25, 2016 at 12:57:59PM +0000, Christos Zoulas wrote:
| >> In article <CAKrYomjukGiXD+COWino3rTDd_u+0o+q04aWxv_qn0GCM-***@mail.gmail.com>,
| >> Proxy arp (rfc1027) was used decades ago to make hosts whose
| >> networking stacks did not understand subnetworking and routing

| On Thu, Feb 25, 2016 at 11:24 PM, Joerg Sonnenberger
| <***@britannica.bec.de> wrote:

| > I have used it much more recently for VMs and the like. If you
| > configure the host machine to provide proxy ARP and use point-to-point
| > links for the individual machines,

Those two are both examples of the more modern (still relevant, at
least in the second case) use of some form of proxy arp. Many
commercial routers (still) do this to compensate for misconfigured
hosts. In both cases the host answering would be acting as a router,
and forwarding packets where they're intended.

The first of those (Christos' case) could in the very early days have
been an instance of the other use though - before the router (if it was not
a BSD host) understood any kind of proxy arp, some other host could send
the router's MAC address to the host that was arping for an address that
is not on the local subnet. Since these days all routers can manage that
for themselves, that (publish someone else's MAC address) form is not
longer likely to be required for this use either.

kre


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

[Greg Troxel]

Post by Ryota Ozaki
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Besides the use case Christos mentioned, the other one is when you have
an Ethernet with a subnet, and one host you have some link to another
host that you'd like to also be addressed within the subnet. Consider
10.0.0.0/8, with a host 10.0.0.20, and another computer without an
ethernet but with a SLIP or PPP link to 10.0.0.20, that you want to be
10.0.0.21.

On 10.0.0.20, you would publish a proxy arp entry for 10.0.0.21, using
10.0.0.20's ethernet address. This would be "pub", to cause replies to
be sent to queries (normally queries are processed without looking at
the arp cache, but only your addresses, I think). And "proxy", so that
10.0.0.20 would not use it.

Sometimes this would be done for dialup hosts, especially homegrown ad
hoc to one's computer at campus.

This setup does not require a proxy arp daemon, because there are small
numbers of non-changing entries.

Besides "why don't you plug .21 into the Ethernet", the other question
is "why don't you allocate a subnet for the PPP link and run a routing
protocol", and the answer was usually "I dno't have any subnets to
allocate" or "it's too hard to make it work".

[Christos Zoulas]

-=-=-=-=-=-

Post by Ryota Ozaki
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Besides the use case Christos mentioned, the other one is when you have
an Ethernet with a subnet, and one host you have some link to another
host that you'd like to also be addressed within the subnet. Consider
10.0.0.0/8, with a host 10.0.0.20, and another computer without an
ethernet but with a SLIP or PPP link to 10.0.0.20, that you want to be
10.0.0.21.

That is correct. This is another use case and pppd does this (sets SIN_PROXY)
in sys-bsd.c

On 10.0.0.20, you would publish a proxy arp entry for 10.0.0.21, using
10.0.0.20's ethernet address. This would be "pub", to cause replies to
be sent to queries (normally queries are processed without looking at
the arp cache, but only your addresses, I think). And "proxy", so that
10.0.0.20 would not use it.
Sometimes this would be done for dialup hosts, especially homegrown ad
hoc to one's computer at campus.
This setup does not require a proxy arp daemon, because there are small
numbers of non-changing entries.
Besides "why don't you plug .21 into the Ethernet", the other question
is "why don't you allocate a subnet for the PPP link and run a routing
protocol", and the answer was usually "I dno't have any subnets to
allocate" or "it's too hard to make it work".

Or I want to be in the same broadcast domain with my cable box
because cable providers are using that to figure out if I am
allowed to stream to my device or not.

christos


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

[Robert Elz]

When a host is answering ARP queries for an IP address that is not its
own, there are two ways (and reasons) for how it does that.

It can send its own MAC address (kind of claiming ownership of the
IP address, though all it will usually do with the packet is relay it
elsewhere.)

Or it can send someone else's MAC address - so that the host that sent
the query gets told the MAC address of the owner of the IP address (one
hopes.) This was used in the ancient times Christos mentioned when some
hosts existed that did not understand ARP (IP over ethernet existed before
ARP was invented.)

One of those was known as proxy ARP, the other wasn't - but I'm not sure
the nomenclature has remained consistent over time. Any rational need for
the second form vasnished long long ago, I can't imagine any host still
running which understands both IP and ethernet, but not ARP.

I suspect from a (very very) brief look at the code, the "proxy" option
to arp(8) is meaning the 2nd of the two.

kre


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

[Ryota Ozaki]

Post by Robert Elz
Date: Mon, 7 Mar 2016 19:43:58 +0900
| I agree proxy ARP can be used that case and we can do so with NetBSD,
| but in that case we also have to set up a machine to receive frames
| that have the destination of someone's MAC address....
No, that was never the method, and should not be necessary ever when
using arp (there are other use cases for things like that.) The idea
was just to provide an arp service that announced someone else's MAC
address, once the node making the ARP query received that info it would
send later packets to the MAC address it was told - for which there should
be a system on the net to receive those frames (we do not relay them). It
was used when that other (destination) host simply did not understand ARP,
but otherwise could handle IP just fine.

Oh, I see. I didn't image that...

Post by Robert Elz
| Anyway I'm not sure NetBSD's proxy ARP is intended for the case
In the early days, BSD ARP was most certainly used for that, and NetBSD
comes from that ancestry, and most likely has remnants of code for that
purpose left in it - whether it still works or not is a different question.
| and there are users for it.
There might easily be none, as I said, I really cannot imagine a real
host left working these days that supports IP and not ARP, it would have
to be truly ancient and running truly ancient code.

Agreed.

Post by Robert Elz
Cases where the host answering the ARP actually wants to receive the
packets to then relay to some other host (whether out some p2p link, or
to a virtual host on the same system makes no difference for this) are
much more common, and much more likely to remain relevant today.

I wrote some tests for the case using tap. I hope the tests are applicable
to p2p links.

ozaki-r

Post by Robert Elz
Certainly the integration of ARP into the routing table is (relatively) new,
when the first case above was in actual use, it was not implemented that way.
kre

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

[Robert Swindells]

Post by Robert Elz
When a host is answering ARP queries for an IP address that is not its
own, there are two ways (and reasons) for how it does that.
It can send its own MAC address (kind of claiming ownership of the
IP address, though all it will usually do with the packet is relay it
elsewhere.)
Or it can send someone else's MAC address - so that the host that sent
the query gets told the MAC address of the owner of the IP address (one
hopes.) This was used in the ancient times Christos mentioned when some
hosts existed that did not understand ARP (IP over ethernet existed before
ARP was invented.)
One of those was known as proxy ARP, the other wasn't - but I'm not sure
the nomenclature has remained consistent over time. Any rational need for
the second form vasnished long long ago, I can't imagine any host still
running which understands both IP and ethernet, but not ARP.

I have an emulated host that runs on NetBSD that doesn't understand
ARP but will talk BOOTP and TFTP to a tap(4) interface.

I'm fairly sure I only used the 'pub' keyword to arp(8) on the server
to get things to work. Can check this.

Robert Swindells

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

[Ryota Ozaki]

Post by Robert Elz
When a host is answering ARP queries for an IP address that is not its
own, there are two ways (and reasons) for how it does that.
It can send its own MAC address (kind of claiming ownership of the
IP address, though all it will usually do with the packet is relay it
elsewhere.)
Or it can send someone else's MAC address - so that the host that sent
the query gets told the MAC address of the owner of the IP address (one
hopes.) This was used in the ancient times Christos mentioned when some
hosts existed that did not understand ARP (IP over ethernet existed before
ARP was invented.)
One of those was known as proxy ARP, the other wasn't - but I'm not sure
the nomenclature has remained consistent over time. Any rational need for
the second form vasnished long long ago, I can't imagine any host still
running which understands both IP and ethernet, but not ARP.
I suspect from a (very very) brief look at the code, the "proxy" option
to arp(8) is meaning the 2nd of the two.

I agree proxy ARP can be used that case and we can do so with NetBSD,
but in that case we also have to set up a machine to receive frames
that have the destination of someone's MAC address by say putting
an interface into promiscuous mode or a feature of MAC address
filtering that is implemented in recent NICs for virtual functions.

Anyway I'm not sure NetBSD's proxy ARP is intended for the case and
there are users for it.

Thanks,
ozaki-r

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

[Ryota Ozaki]

Post by Robert Swindells

Post by Robert Elz
When a host is answering ARP queries for an IP address that is not its
own, there are two ways (and reasons) for how it does that.
It can send its own MAC address (kind of claiming ownership of the
IP address, though all it will usually do with the packet is relay it
elsewhere.)
Or it can send someone else's MAC address - so that the host that sent
the query gets told the MAC address of the owner of the IP address (one
hopes.) This was used in the ancient times Christos mentioned when some
hosts existed that did not understand ARP (IP over ethernet existed before
ARP was invented.)
One of those was known as proxy ARP, the other wasn't - but I'm not sure
the nomenclature has remained consistent over time. Any rational need for
the second form vasnished long long ago, I can't imagine any host still
running which understands both IP and ethernet, but not ARP.

I have an emulated host that runs on NetBSD that doesn't understand
ARP but will talk BOOTP and TFTP to a tap(4) interface.
I'm fairly sure I only used the 'pub' keyword to arp(8) on the server
to get things to work. Can check this.

Could you provide your setup and netstat -nr and arp -na outputs?
I try your setup and write some tests for it if possible.

Thanks,
ozaki-r

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

[Robert Elz]

Date: Mon, 7 Mar 2016 19:43:58 +0900
From: Ryota Ozaki <ozaki-***@netbsd.org>
Message-ID: <CAKrYomi9fEaC5BO64Rw==jujXPZaMJQXmVc=U=HX-***@mail.gmail.com>

| I agree proxy ARP can be used that case and we can do so with NetBSD,
| but in that case we also have to set up a machine to receive frames
| that have the destination of someone's MAC address....

No, that was never the method, and should not be necessary ever when
using arp (there are other use cases for things like that.) The idea
was just to provide an arp service that announced someone else's MAC
address, once the node making the ARP query received that info it would
send later packets to the MAC address it was told - for which there should
be a system on the net to receive those frames (we do not relay them). It
was used when that other (destination) host simply did not understand ARP,
but otherwise could handle IP just fine.

| Anyway I'm not sure NetBSD's proxy ARP is intended for the case

In the early days, BSD ARP was most certainly used for that, and NetBSD
comes from that ancestry, and most likely has remnants of code for that
purpose left in it - whether it still works or not is a different question.

| and there are users for it.

There might easily be none, as I said, I really cannot imagine a real
host left working these days that supports IP and not ARP, it would have
to be truly ancient and running truly ancient code.

Cases where the host answering the ARP actually wants to receive the
packets to then relay to some other host (whether out some p2p link, or
to a virtual host on the same system makes no difference for this) are
much more common, and much more likely to remain relevant today.

Certainly the integration of ARP into the routing table is (relatively) new,
when the first case above was in actual use, it was not implemented that way.

kre


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

[Christos Zoulas]

-=-=-=-=-=-

Post by Roy Marples
So there exists two implementations in userland, one of which at least
is in pkgsrc.
Could we remove this feature from arp itself and the kernel to trim it
down some? Or is the need still there?

How much would we save in the kernel? This feels like only a few lines
of code, and it would remove a feature that some still use that dates
back to at least 4.2BSD.
I think it's still necessary (Joerg's VM example is the modern analog of
old dialup), and the basic few flags, slight behavior change seems
pretty straighforward.
Are the programs more about answering for arbitrary addresses, vs
publishing arp for specific hosts? Are they needed on NetBSD, for some
other use case, or are they portable for other systems too? Do they
use bpf?

I don't even understand what is the proposal for removing code in
the kernel? Don't set SIN_PROXY? It does not seem like a worthwhile goal.

christos


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

[Ryota Ozaki]

Post by Christos Zoulas

-=-=-=-=-=-

Post by Roy Marples
So there exists two implementations in userland, one of which at least
is in pkgsrc.
Could we remove this feature from arp itself and the kernel to trim it
down some? Or is the need still there?

How much would we save in the kernel? This feels like only a few lines
of code, and it would remove a feature that some still use that dates
back to at least 4.2BSD.
I think it's still necessary (Joerg's VM example is the modern analog of
old dialup), and the basic few flags, slight behavior change seems
pretty straighforward.
Are the programs more about answering for arbitrary addresses, vs
publishing arp for specific hosts? Are they needed on NetBSD, for some
other use case, or are they portable for other systems too? Do they
use bpf?

I don't even understand what is the proposal for removing code in
the kernel? Don't set SIN_PROXY? It does not seem like a worthwhile goal.

Less features, easier to keep the system work correctly and keep
backward compatibility :)

Anyway if we separate nexthop caches from the routing table, each cache
doesn't have a route so we stop relying on SIN_PROXY (a flag for a route)
and instead we have to have another way to provide the same feature.
(LLE_PUB, which comes from FreeBSD, will be used in my plan.)

I worry about how we provide proxy ARP for the "pub" case; if we separate
nexthop caches, creating a route by arp -s is not so much appropriate...

ozaki-r

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

[Ryota Ozaki]

Hi all,

Thank you for answering my questions!

Before replying individual mails I would like to explain some background
of my questions (I should write this in the first place obviously) and
some results of the survey by myself.

I'm working on separting nexthop caches(*). The change is likely to break
the proxy arp easily so I want to know about the feature well to not break
it and hopefully write some tests for it (I already wrote some but they're
not enough).

(*) http://wiki.netbsd.org/projects/project/nexthop_cache/

And here is what I investigated about why "pub proxy" was introduced
(I'm maybe wrong):

Originally there was only "pub" option; an added arp entry (a route)
acts like a ARP responder for a someone behind it (really?). (It has
a network route with /32 netmask.) If there is the same route entry
when a "pub" arp entry is added, the arp entry is automatically
changed into a something shadow route (SIN_PROXY avoids conflict
pre-existing one). A typical case is that there is a point-to-point
route (e.g., for ppp). The arp entry acts only a proxy for the
point-to-point destination; it doesn't provide a valid route. It worked
but at some point, the automatic change failed to work for some reason
(by some changes in the kernel?) and "pub proxy" option was added;
it forcibly sets SIN_PROXY to an arp entry (a route).

(FreeBSD and OpenBSD haven't introduced "pub proxy" option. Mac OS X
has it I guess because it was derived from NetBSD source code that
already added the option (I'm not sure though).)

In the context of separting nexthop caches, a "pub proxy" ARP entry
is easy to provide because what it should do is just to response to
ARP requests for the ARP entry. OTOH, "pub" one involves a network
route so I'm not sure how to deal with it after separting nexthop
caches because an ARP entry won't be a route anymore.

Anyway I'll reply your replies individually later,
ozaki-r

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

[Ryota Ozaki]

Post by Greg Troxel

Post by Ryota Ozaki
I have questions about the Proxy ARP feature.
arp(8) has two options: "pub" and "pub proxy".
What's the different between them and what
are expected behaviors of them?

Besides the use case Christos mentioned, the other one is when you have
an Ethernet with a subnet, and one host you have some link to another
host that you'd like to also be addressed within the subnet. Consider
10.0.0.0/8, with a host 10.0.0.20, and another computer without an
ethernet but with a SLIP or PPP link to 10.0.0.20, that you want to be
10.0.0.21.
On 10.0.0.20, you would publish a proxy arp entry for 10.0.0.21, using
10.0.0.20's ethernet address. This would be "pub", to cause replies to
be sent to queries (normally queries are processed without looking at
the arp cache, but only your addresses, I think). And "proxy", so that
10.0.0.20 would not use it.

I understand the "proxy" case but don't understand well "pub" case well.
In the above case, a route to 10.0.0.21 should direct to the other
computer while the proxy arp entry should be on an interface where
10.0.0.20 is assigned, to reply ARP requests for 10.0.0.21. IIUC, this
is "proxy" case and so I don't know when "pub" case is useful.

Thanks,
ozaki-r

Post by Greg Troxel
Sometimes this would be done for dialup hosts, especially homegrown ad
hoc to one's computer at campus.
This setup does not require a proxy arp daemon, because there are small
numbers of non-changing entries.
Besides "why don't you plug .21 into the Ethernet", the other question
is "why don't you allocate a subnet for the PPP link and run a routing
protocol", and the answer was usually "I dno't have any subnets to
allocate" or "it's too hard to make it work".

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