Subject: (NAT) Locating RSIP servers

From: "Mike Borella" <[email-masked]>
Date: Fri, 5 Nov 1999 17:45:40 -0600

Suresh brought this issue up.  It's a very valid point, which goes beyond
the current TCP vs. UDP discussion.

Here's the problem: If we just do a UDP broadcast on the RSIP port (4455) then
we will not be able to locate servers that are more than 1 hop away.  The
intermediate
routers should drop the UDP broadcasts.  The only port that will get forwarded
is
BOOTP/DHCP, but if we use that one, we'll collide with DHCP, which would be
very, very
bad.

Take a look at draft-privat-dhc-doublephase-01.txt.  The author defines
proxy and redirect DHCP messages so that a host can check one DHCP server
but be assigned an address from another.  We can take advantage of this by
extending the redirect message so that one can redirect to an RSIP server.
So the RSIP server can be any number of hops away, or even run by a different
admin, and we could still find it.  No need to change routers.  I've brought
this
up with the author and he seems willing to work with us.

The process would be something like this:

1) RSIP client boots
2) RSIP client sends DHCP request
3) DHCP server returns private IP along with redirect to RSIP server.
4) When client needs RSIP, it contacts RSIP server directly.

This assumes the use of DHCP, but if you're going to bother with RSIP,
you'll need some way of assigning local IP's anyway. DHCP makes the
most sense.

-Mike

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 Nov 1999 22:40:27 -0800

>We can take advantage of this 

It's probably not a good idea to create a dependence on a draft that
is not yet on the standards track in DHC WG. What's wrong with just
using a DHCP option for this? 
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Nov 1999 15:07:35 -0500

RSIP server locating should be handled by either one of the server
location protocols that I'm told now exist, or by DHCP. RSIP should not
invent the wheel again.

  Alternatively, the RSIP request should be sent to the final destination,
a la SPP, and the RSIP server intercept it. That let's routers do their
job in load balancing and in providing failover. 

  If one wants to provide a multicast mode of discovery, that would be useful
in very small networks, ones where there are no routers, and intelligent
admins to setup DHCP or preconfigure RSIP. Perhaps RSIP servers should listen 
on the all-routers multicast address?

]                   At IETF46 in Washington, DC                 |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.