ibm-information-center/dist/eclipse/plugins/i5OS.ic.apis_5.4.0.1/xtodabnd.htm

283 lines
8.7 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Copyright" content="Copyright (c) 2006 by IBM Corporation">
<title>DHCP Address Binding Notification Exit Program</title>
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<!-- Begin Header Records ========================================= -->
<!-- XTODABND SCRIPT A converted by B2H R4.1 (346) (CMS) by KENTALA -->
<!-- at RCHVMW2 on 21 Oct 1998 at 18:19:34 -->
<!--File Edited Oct 2001 by Janet Brauckman -->
<!--End Header Records -->
<link rel="stylesheet" type="text/css" href="../rzahg/ic.css">
</head>
<body>
<a name="Top_Of_Page"></a>
<!-- Java sync-link -->
<script language="Javascript" src="../rzahg/synch.js" type="text/javascript">
</script>
<h2>DHCP Address Binding Notification Exit Program</h2>
<div class="box" style="width: 80%;">
<br>
&nbsp;&nbsp;Required Parameter Group:<br>
<!-- iddvc RMBR -->
<br>
<table width="100%">
<tr>
<td align="center" valign="top" width="10%">1</td>
<td align="left" valign="top" width="50%">Request type</td>
<td align="left" valign="top" width="20%">Input</td>
<td align="left" valign="top" width="20%">Binary(4)</td>
</tr>
<tr>
<td align="center" valign="top">2</td>
<td align="left" valign="top">Client IP address</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Char(*)</td>
</tr>
<tr>
<td align="center" valign="top">3</td>
<td align="left" valign="top">Length of IP address</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Binary(4)</td>
</tr>
<tr>
<td align="center" valign="top">4</td>
<td align="left" valign="top">Client identifier</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Char(*)</td>
</tr>
<tr>
<td align="center" valign="top">5</td>
<td align="left" valign="top">Length of client identifier</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Binary(4)</td>
</tr>
<tr>
<td align="center" valign="top">6</td>
<td align="left" valign="top">Lease duration</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Binary(4)</td>
</tr>
<tr>
<td align="center" valign="top">7</td>
<td align="left" valign="top">Response packet</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Char(*)</td>
</tr>
<tr>
<td align="center" valign="top">8</td>
<td align="left" valign="top">Length of response packet</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Binary(4)</td>
</tr>
</table>
<br>
&nbsp;&nbsp;Exit Point Name: QIBM_QTOD_DHCP_ABND<br>
<!-- iddvc RMBR -->
<br>
&nbsp;&nbsp;Exit Point Format Name: DHCA0100<br>
<!-- iddvc RMBR -->
<br>
</div>
<p>The DHCP Address Binding Notification exit program allows for notification
each time the DHCP server assigns an IP address to a specific client host. This
is known as address binding. The exit program will be called any time the DHCP
server sends an acknowledgement packet (known as a DHCP ACK) to a DHCP client
or sends a Bootstrap Protocol (BOOTP) reply packet to a BOOTP client. The two
possible client IP address binding packets follow:</p>
<ol>
<li>A DHCP ACK from the server tells a DHCP client that it has been granted a
lease to use a specific IP address for a specific period of time.
Acknowledgements are sent when a DHCP client accepts an initial offer of an IP
address made by the server, as well as each time that a DHCP client asks for
the renewal of an existing IP address lease and the server grants it.<br>
<br>
</li>
<li>A BOOTP reply packet is sent from the server in response to a BOOTP request
packet from a client if the server decides to assign an IP address to that
client. The BOOTP reply notifies the BOOTP client what IP address it has been
assigned. Unlike DHCP, the BOOTP protocol does not support the concept of
temporary leasing. Therefore, the address binding to the BOOTP client is
considered permanent and there will be no ongoing exchange of renewal bindings.
The DHCP server internally treats a BOOTP client binding as an infinite
lease.</li>
</ol>
<p>When an exit program is added to the exit point, it is called immediately
after the DHCP server has transmitted one of the client IP address binding
packets described above. This is for notification purposes only, and no data is
expected to be sent back to the DHCP server from the exit program. The exit
program will be sent information about the protocol type (DHCP or BOOTP), the
identity of the client, the IP address, and the duration of the lease. In
addition, a copy of the actual packet that was transmitted will be sent.</p>
<p><strong>Note:</strong> Since this is an exit point of the DHCP server, the
exit program can only be used to obtain notification of address bindings for
the BOOTP client if the DHCP server is running. It cannot be used to obtain
notification of IP address assignments for the BOOTP client made by the iSeries
BOOTP server.</p>
<br>
<!-- Please NOTE: DO NOT DELETE THIS SECTION if this API has no authorities and locks. -->
<!-- Instead, use the commented out coding below to indicate NONE. -->
<h3>Authorities and Locks</h3>
<!-- Use this if there are no authorities and locks. -->
<p>None.</p>
<br>
<h3>Required Parameter Group</h3>
<dl>
<dt><strong>Request type</strong></dt>
<dd>INPUT; BINARY(4)
<p>The type of request protocol being used between the client and server. The
possible values are:</p>
<table cellpadding="3">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">DHCP</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">BOOTP</td>
</tr>
</table>
<br>
</dd>
<dt><strong>Client IP address</strong></dt>
<dd>INPUT; CHAR(*)
<p>The Internet Protocol (IP) address that was bound to the client host. This
string is in dotted decimal format and left-justified.</p>
</dd>
<dt><strong>Length of client IP address</strong></dt>
<dd>INPUT; BINARY(4)
<p>The length (in bytes) of the client IP address.</p>
</dd>
<dt><strong>Client identifier</strong></dt>
<dd>INPUT; CHAR(*)
<p>The unique identifier of the client that the IP address has been bound to.
This is usually the hardware address of the client machine.</p>
</dd>
<dt><strong>Length of client identifier</strong></dt>
<dd>INPUT; BINARY(4)
<p>The length (in bytes) of the client identifier string.</p>
</dd>
<dt><strong>Lease duration</strong></dt>
<dd>INPUT; BINARY(4)
<p>The duration (in seconds) of the lease period for which the client may now
use the IP address.</p>
<p>This field should be treated as a 32-bit unsigned number. The special value
follows:</p>
<table cellpadding="3">
<!-- cols="15 85" -->
<tr>
<td align="left" valign="top"><em>hex&nbsp;FFFFFFFF</em></td>
<td align="left" valign="top">If all 32 bits are set to 1, this indicates that
the lease is an infinite lease, which does not expire.</td>
</tr>
</table>
<br>
</dd>
<dt><strong>Response packet</strong></dt>
<dd>INPUT; CHAR(*)
<p>This is the DHCP or BOOTP message response packet that was transmitted from
the DHCP server to the client host just prior to this notification exit program
being called.</p>
<p>The formats of the packets are defined and maintained by the Internet
Engineering Task Force (IETF) standards body. Refer to the following IETF
Request For Comments (RFC) documents for the specifications:</p>
<ul>
<li>RFC 951, Bootstrap Protocol (BOOTP)</li>
<li>RFC 1542, Clarifications and Extensions for the Bootstrap Protocol</li>
<li>RFC 2131, Dynamic Host Configuration Protocol</li>
<li>RFC 2132, DHCP Options and BOOTP Vendor Extensions</li>
</ul>
<p><strong>Note:</strong> Since the packet is presented to the exit program
just as it was transmitted on the network, it should be noted that any data
areas of the packet that are defined as type string or character by the RFCs
will be US-ASCII. On the iSeries, it is recommended that this data be treated as
CCSID 819.</p>
</dd>
<dt><strong>Length of response packet</strong></dt>
<dd>INPUT; BINARY(4)
<p>The length (in bytes) of the response packet.</p>
</dd>
</dl>
<br>
<hr>
Exit program introduced: V4R2
<hr>
<center>
<table cellpadding="2" cellspacing="2">
<tr align="center">
<td valign="middle" align="center">
<a href="#Top_Of_Page">Top</a> |
<a href="ss1.htm">Server Support APIs</a> |
<a href="aplist.htm">APIs by category</a></td>
</tr>
</table>
</center>
</body>
</html>