>[Ralph Droms:]
>> Ouch.  This sounds like an ugly problem.  I think you're right - relay
>> agents, especially those not running in a router - could very easily
>> receive server responses for which the relay agnent has no corresponding
>> interface.
>> 
>> Anybody have a better suggestions?
>
>Afraid not.  Even on the graceful-renumbering stuff, I've basically
>been assuming that a relay agent has to be configured to speak on a
>subnet in order to handle passing requests back to that subnet.  It's
>clear that the router has to be configured for that subnet to make it
>worth assigning an address on that subnet, so I think the combined
>router-and-relay-agent case is the *most* obvious example.
>
Some relay agents are built into routers and some aren't.
The ones that are part of a router inherently know which subnets 
are on each interface.  And there are probably facilities for 
sending a datagram on a specific interface.

Those relay agents that are not built into routers are probably based
on some inexpensive machine (like a pc), or are running on a server
which is performing multiple functions.  The pc solution can be built
such that it's broadcast address is set to a limited broadcast (all-ones),
and the responses can be broadcast instead of unicast.  

The reflex solution for the multi-purpose server would be to make
an arp entry for the client, and unicast the response.  This won't
work on any subnet's which don't match the interface's subnet.  
Is there any problem with relay agents broadcasting a response packet
to the client?  This eliminates any nead of the relay agent to pay
attention to the destination at all...