Dialup subnet configuration -Reply
Kester Fong <kfong@novell.com> Tue, 17 December 1996 18:30 UTC
Received: from cnri by ietf.org id aa12729; 17 Dec 96 13:30 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa18222;
17 Dec 96 13:30 EST
Received: from reef.bucknell.edu by mail.bucknell.edu;
(5.65v3.2/1.1.8.2/17Jul96-0109PM)
id AA25542; Tue, 17 Dec 1996 13:14:35 -0500
Date: Tue, 17 Dec 1996 13:14:35 -0500
Message-Id: <s2b663a0.096@novell.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Kester Fong <kfong@novell.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Dialup subnet configuration -Reply
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
X-Mailer: Novell GroupWise 4.1
Mike, please include me in your dicussion "thread". Two observations for scenario 1: - your Network Terminal Server needs to generate a unique client ID or a hardware address equivalent that is unique over the lifetime of the corresponding dhcp server session. Do you have any suggestion as to what the proper strategy should be? - To be conservative on IP address allocation, effective lease time is probably the connection time by default. Termination of a remote connection is the termination of a lease. Kester Novell >>> Mike Carney - SunSoft Internet Engineering <mwc@atlantic.east.sun.com> 12/16/96 07:46pm >>> 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 -Reply Kester Fong