DHCP and TCPaccess

Products

• TCPaccess

Issue/Introduction

Description:

Can TCPaccess utilize DHCP?

Solution:

DHCP (Dynamic Host Configuration Protocol), is used to assign dynamicIP addresses to devices on a network. With this dynamic addressing, a device can have a different IP address every time it connects to the network.

First some basic information regarding client vs. server in relation to DHCP:

• DHCP is normally used for work stations and client type systems.
• Servers typically need to have a permanent IP addresses.
• TCPACCESS does not have a DHCP client and cannot obtain an IP address using DHCP. The IP address must be hardcoded in the TCPCFG member.

DHCP and the network interface to the stack

TCPaccess is a mainframe server and cannot not use DHCP services to acquire an IP address.

The IP address for the stack is hard coded in the TCPCFGxx; it remains static.

This IP address actually is that of an OSA or CIP or other network device that provides the interface between a mainframe and the network. These devices require a static IP address. Another level of complexity occurs if a static VIPA address is defined, as this must be associated to the device IP address in order for it to work. That means that to involve the stack itself in DHCP would mean involving the OSA or CIP or other device in DHCP. Usually these devices must be cycled or manually reconfigured if the IP address is changed, which would disrupt service between the mainframe and the network.

A client goes out and actively tries to connect to a remote host.

TCPaccess does not have any processes that do so except to connect to the device that allows communication with the network. Any other activity is created by a client or command of some sort coming into the stack and eliciting a response.

That means that any client or application trying to connect must know the IP address or hostname of the stack.

In many situations, the hostname to IP resolution for the stack is done on the MVS system with help of the DNS server, but without influence from the stack, so if the IP address does not match, no connection can be made.

DHCP and the Telnet Server

TCPaccess supplies a Telnet server that awaits and enables connection requests from Telnet clients so that they may access mainframe applications through the stack.

When a Telnet session request comes in, the APPLUP is checked for any rules that may apply to that connection, using LU, USER, PORT, IPADDR or other criteria to determine what connectivity is allowed.

The only LURULE parameter where a problem may arise is in the use of the IPADDR parameter. TCPaccess sees the IP address of the incoming connection, and will map that to a matching LURULE, if one exists.

If DHCP is enabled on the network, each client may have a different IP address every time it tries to connect,

Using the one-to-one IPADDR correlation would result in random users being assigned to specific LURULEs, a most undesirable result. The stack cannot use a hostname instead of the IP address as there is no parameter defined for that, but even more, the hostname of the remote is not passed during Telnet session negotiation.

It would still be possible to define pools of IP addresses, if DHCP is configured such that any incoming Telnet request from that pool is subject to the same LURULE that uses the IP address as criteria.

If your APPLUP definitions currently do not utilize the IPADDR LURULE parameter, then implementing DHCP on the PCs in your network will not pose a problem for the TCPaccess Telnet server.

Environment

Release:
Component: NTCPAC