Dialup subnet configuration
Mike Carney - SunSoft Internet Engineering <mwc@atlantic.east.sun.com> Tue, 17 December 1996 03:58 UTC
Received: from cnri by ietf.org id aa05535; 16 Dec 96 22:58 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa01456;
16 Dec 96 22:58 EST
Received: from reef.bucknell.edu by mail.bucknell.edu;
(5.65v3.2/1.1.8.2/17Jul96-0109PM)
id AA19583; Mon, 16 Dec 1996 22:47:09 -0500
Date: Mon, 16 Dec 1996 22:47:09 -0500
Message-Id: <Roam.SIMC.2.0.Beta.850792514.15451.mwc@atlantic.east>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Mike Carney - SunSoft Internet Engineering <mwc@atlantic.east.sun.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Dialup subnet configuration
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
As promised at the San Jose WG meeting, here are the notes I produced during
discussions with Krishnan and Jim: (What's missing is a suggestion by Jim to
use IP tunneling as an additional method). If you're interested in following a
thread on this topic, let me know.
96/10/29 1.1
mwc
ABSTRACT:
This note describes two DHCP management scenarios for the support of
intermittently connected, remote clients. The first (Scenario #1)
discusses the connection of single remote clients to the
Corporate Network. The second (Scenario #2) discusses the
connection and configuration of remote networks so that these
remote networks can interact with the Corporate Network (as well
as other remote networks).
Scenario #1:
============
DHCP management of Network Terminal Server IP addresses - single remote
client.
Discussion:
No concept of remote network. Clients dial directly into Corporate
network's Network Terminal Server (NTS), using PPP/IP. NTS serves as DHCP
relay agent, and also uses DHCP to manage IPCP address pool.
--------------------------
| Corporate Network |
| (DHCP servers) |
--------------------------
|
|
|
---------------------------
| Network Terminal Server |
---------------------------
/ \
/ \
/ \
/ \
/ \
----------/------------------------\--------------
| / Remote Site \ |
| / \ |
| / \ |
| / \ |
| Client 1 Client 2 |
| |
| |
| |
| |
--------------------------------------------------
Upon connection request, the NTS performs a DHCP transaction to acquire an
address for the remote client. The address is communicated to the client
through IPCP. If the client has software which implements DHCP, it can later
issue a DHCPINFORM packet, which the NTS will relay to the DHCP server(s). If
the client network software doesn't support DHCPINFORM, then NTS will need to
provide proxy DHCP services (DHCPREQUEST for extending lease). Optionally,
NTS could generate a DHCPRELEASE message when a client disconnects, although
short lease times could accomplish the much of the same thing asynchonously.
Advantages:
1) No changes to PPP required (IPCP).
2) Works for clients who do not support DHCP.
3) LCP security maintained (CHAP), although physical client access
still a concern.
4) Remote IP addresses (IPCP) managed by DHCP.
5) Corporate routing tables protected. (only expose default route)
Disadvantages:
1) Single client connection. No concept of remote network.
Scenario #2:
============
DHCP management of remote networks.
Discussion:
Remote site consists of a remote network which is intermittently connected
to the corporate network. Consider the following diagram:
--------------------------
| Corporate Network |
| (DHCP servers) |
--------------------------
|
-
______________|A|________________
( - )
( . )
( . )
( . )
( . )
( . )
( . )
( Remote Connectivity Service )
( . )
( . )
( . )
( . )
( . )
(________________________________)
.
-
-----------------------|B|------------------------
| - |
| | |
| | |
| | |
| | |
| Remote Site | |
| | Remote Network |
| ------------------------------------- |
| | | |
| Client 1 Client 2 |
| |
| |
| |
| |
--------------------------------------------------
Connectivity between the Corporate network and the remote network is
provided by the ISP represented by the Remote Connectivity Service
(RCS), the simplest RCS being the telephone network. The devices of
interest are Device A, which serves as the connection point between
the RCS and the Corporate Network, and Device B, which serves as the
connection point between the RCS and the Remote Network.
Device A
========
Device A has the following requirements:
1) Must be able to identify (authenticate) various
instances of B devices. Note that this could simply
be done using a dial-back handshake.
2) Network connection to the Corporate network of
Device A will likely be manual for security
reasons, although I suppose the adventurous
could use DHCP to do this.
3) Must provide routing and BOOTP relay agent
functionality to authenticated B devices. Note that
this includes multicasting various Corporate
Network routing information.
4) When a Device B disconnects, Device A must
attempt to purge the route to the Device B
network from the Corporate Network.
Device B
========
Instances of Device B have the following requirements:
1) Must be configured to appropriately establish an
authenticated link-level connection to Device A.
2) Should use IPCP/BOOTP/DHCP to acquire the IP
address and network mask for the LAN connection
connecting to the Remote Network. If such devices
are configured through DHCP, they may identify
themselves using an appropriate DHCP Client Class
Identifier so that the DHCP administrators can
configure parameters appropriate to devices of
this type.
3) Must provide routing and BOOTP relay agent
functionality to the connected LAN.
4) NB: Clients of the Remote Network need to use
BOOTP or DHCP to configure their IP stacks.
Advantages:
1) Supports the connection and DHCP configuration of Remote Networks
to the Corporate Network.
2) Configuration of Device B's (and potentially Device A's) through
DHCP, thus allowing for easy
renumbering/partitioning/administration.
Disadvantages:
1) Doesn't work for clients who do not support BOOTP/DHCP.
2) Security is maintained between Device A and Device B, although
there is no security on the Remote Network LAN (and thus the
Corporate Network.)
3) Corporate routing tables exposed
Security:
Corporations could limit exposure by using an IP-level encryption
facility such as Oakley or SKIP. This would prevent the attachment of
devices to the local LAN for the purpose of snooping network traffic,
although the authenticated LAN devices must be secured in some
fashion. (mwc: Geez, I can see why more people implement Scenario #1)
Mike Carney
SunSoft Internet Engineering
Sun Microsystems, Inc.
2 Elizabeth Drive
Chelmsford, MA 01824
- Dialup subnet configuration Mike Carney - SunSoft Internet Engineering
- Re: Dialup subnet configuration bound