Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proxy Arp -- How is it Implemented? Keywords: RFC925 Message-ID: Date: 29 Mar 89 19:50:34 GMT References: <2552@ssc-vax.UUCP> Distribution: usa Organization: Rutgers Univ., New Brunswick, N.J. Lines: 30 RFC 925 does not describe how proxy ARP is implemented. The RFC proposes a new kind of packet switch, which is somewhere between a normal IP gateway and a bridge. ARP is used as part of the design, but this is *not* proxy ARP as currently used. (Indeed that term does not occur in the RFC.) RFC 925 is describing something that looks a lot like a learning bridge. Like a bridge, there is no mapping between IP address and network topology, i.e. no subnetting. Like a bridge, hosts are listed individually in the routing tables, unlike gateways, which only keep track of routes to nets and subnets (except for the directly connected subnets, which need ARP caches). It's an interesting proposal, but it isn't proxy ARP as currently used. Proxy ARP is used with conventional IP gateways (routers). It is exactly as you describe: a gateway responds to ARP requests for targets on the other side of the gateway. It decides whether to respond to an ARP by looking in its routing tables. There are two uses for proxy ARP - some gateways implement it only for subnets of the local network. The intention is to handle the problem of hosts that do not understand subnets. - some gateways implement it for all destinations. In that case it is possible for a host to use ARP as a gateway discovery technique for all destinations. I believe proxy ARP was originally invented only to handle hosts that don't implement subnets. However we use the second approach at Rutgers: where possible our hosts are set to issue ARP requests for all destinations.