283 lines
8.7 KiB
HTML
283 lines
8.7 KiB
HTML
<!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>
|
|
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>
|
|
Exit Point Name: QIBM_QTOD_DHCP_ABND<br>
|
|
<!-- iddvc RMBR -->
|
|
<br>
|
|
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 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>
|
|
|