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.
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.
Regards
Ashutosh
> Ashutosh Dutta writes:
> >
> > Karl, in a 3GPP2 environment where the client gets an IP address from
> > PDSN over PPP link, my PDSN acts like a NAS which is also a PPP
> > server, and I may not have a DHCP server in that case.
>
> A "DHCP server" is no more difficult than an IP node that can send and
> receive UDP packets. If you don't have that, then it seems unlikely
> to me that you've got a functioning IP network at all.
>
> Note that you don't need stateful behavior to solve the problem. A
> simple DHCPINFORM will do the trick.
>
> > I have used DHCP in LAN environment with SIP option.
>
> And that's a good reason why it should *not* be added to PPP. It's
> redundant work.
>
> A much better reason to avoid adding it to PPP is that it won't work
> right. Consider the following network:
>
> N1 <---PPP---> N2 <---Ethernet/other---> SIP server
>
> 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.
>
> 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.
>
> The same problem afflicts the ill-considered DNS name server address
> option, and I don't think we need to replicate that mistake. Once, I
> think, was plenty.
>
> --
> James Carlson, KISS Network <james.d.carlson@xxxxxxx>
> 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
Ashutosh
_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
