Re: IPCP option for SIP server

Ashutosh Dutta writes:
> James, appreciate your thoughtful reply. As you have mentioned there
> is certainly better way around to take care of this scenario if one
> has a DHCP server sitting in the network where the NAS server is
> connected.

Where "DHCP server" is no more complex an answer than "new IPCP
option."  In fact, the former is *less* complex because it involves
existing standards, while the latter requires forcing manufacturers to
add the option of interest and then deploying brand new software
(and/or hardware) to solve the problem.

Using existing mechanisms is generally a better idea, if you have a
choice.

> I was refering to the case where the PPP server is configured to give
> away the addresses and may not have any DHCP server configured in the
> network to rely upon, in that case only way to provide SIP server, DNS
> server etc. to the mobile obtaining the IP address may need a
> mechanism where these parameters get stored locally in a NAS server
> and are given out as part of IP address dispensing.

As I wrote:

> > In this case, you'd want N1 to learn about the IP address of the SIP
> > server that exists behind N2.  But the PPP (and IPCP) negotiation on
> > the PPP link terminates with N2.  This means that N2 needs to somehow
> > "know" that the SIP server exists and what its address is.

You still have to have information on the SIP server's side of that
PPP link that somehow tells the PPP termination equipment the IP
address of the proper SIP server.

There are multiple ways to do this, but they're all much less robust
and less desirable than just using a simple DHCP exchange.

As I wrote:

> > This implies that either N2 behaves as a proxy between this new IPCP
> > configuration option and DHCP, or that N2 has fragile statically
> > configured data for that address.
> > 
> > Either way, you're committing all of us (collectively) to producing
> > new ad-hoc extensions to IPCP that are proxied one-by-one into DHCP or
> > some local configuration that must be managed.  That solution is far
> > more complex and much less extensible than just having N2 behave as a
> > generic DHCP/BOOTP relay on behalf of N1, and allowing those protocols
> > to do what they're already designed to do.

I don't see any good way out of that problem.  There are few ways for
N2 to have any *reliable* knowledge of the SIP server's address, and
the ways that do exist imply duplicative effort within IPCP to rebuild
all of the options currently available in DHCP.

I see no point to doing that, when sending and receiving UDP datagrams
is trivial.

-- 
James Carlson, KISS Network                    <[email protected]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext