The information in this document is based on these software and
hardware versions:

Cisco IOS® Software Release 12.1(9) on a Cisco 5300 router.

The Cisco IOS DHCP server feature was introduced in Cisco IOS
Software Release 12.0(1)T. Use the
Software
Advisor to check if your current IOS version and platform support the
IOS DHCP server feature.

Note: You need Cisco IOS Software Release 12.0(2)T or later for use with
Cisco 1700 series routers.

The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.

There are several different mechanisms for delivering IP addresses to
dialin clients on Access servers. Some possible options for assigning IP
addresses to clients include:

Assigning an address from the local IP pool on the Access
server.

Using an external Dynamic Host Control Protocol (DHCP)
server.

Using RADIUS or TACACS.

This document focusses on how to use the Cisco IOS® server
functionality with Access servers to assign IP addresses and other DHCP
variables to dialin clients. This avoids using an external DHCP server and,
instead, uses the built-in DHCP server functionality from the Cisco IOS itself.
DHCP enables you to automatically assign reusable IP addresses to DHCP
clients.

The Cisco IOS DHCP server feature is a full DHCP server implementation
that assigns and manages IP addresses from specified address pools within the
router to DHCP clients. If the Cisco IOS DHCP server cannot satisfy a DHCP
request from its own database, it can forward the request to one or more
secondary DHCP servers defined by the network administrator.

To learn more about Cisco IOS DHCP functionality, restrictions and
supported platforms, please refer to the
Cisco IOS
DHCP Server document. At this point, it is useful to know which
parameters can be passed to the PPP client.

Note: We are unable to use subnet masking to the PPP client. This is due to
a limitation with the Request For Comments (RFC). The reason for this is that,
when PPP negotiates with the PPP client, the following parameters are
negotiated via PPP and IP Control Protocol (IPCP):

IP address.

Primary and Secondary Domain Name System (DNS)
addresses.

Primary and Secondary NetBIOS Name Service (NBNS)
addresses.

TCP/IP Header Compression.

The function for passing a subnet mask to the PPP client is not part of
the protocol for PPP (RFC 1548) or IPCP (RFC 1332). The
async-bootp commands such as
async-bootp dns-server and async-bootp
nbns-server pass the information to the PPP client because these
fields are negotiated via PPP. The async-bootp
subnet-mask is not a parameter that is passed through PPP.

The async-bootp global configuration
commands enable support for extended Bootstrap Protocol (BOOTP) requests, as
defined in RFC 1084, when you configure the router for Serial Line Internet
Protocol (SLIP). When the Windows 95 or NT PC that is running dial-up
networking dials into your router, it is doing PPP, not BOOTP or SLIP. This
means that there is no way to pass the subnet mask to the Windows 95 or NT PPP
dial-up client, or the gateway for that matter. When you have a Windows dialin
client that gets its IP address dynamically from the Access server, you can see
that the subnet mask is set to 255.0.0.0. Since this is a point-to-point
connection, the subnet mask is not important, because the dialin client is
known to the Access server as a single host route (255.255.255.255 netmask).
The Access server has one host route for each of the connected dialin
clients.

If you have correctly implemented the IOS DHCP server funtionality, you
can look at the IP configuration, Windows IP Configuration program (winipcfg)
or appropriate commands on the dialin clients to check the received DHCP
parameters. We can get the following parameters from the DHCP server by using
winipcfg on the Windows 98 PC we are using for the
test: