96x1H-IPI.5.1.604: Dynamic Host Configuration Protocol for IPv4 (DHCP or DHCPv4)
Approved
DHCP will be supported as specified by IETF RFCs 2131 [7.3-20d] and 2132 [7.3-20e] and by requirements below.
DHCP will use UDP as a transport-layer protocol (see 96x1H-IPI.5.1.400), but messages received on the DHCP UDP port will only be processed if they are received in response to a message transmitted by the telephone.
When DHCP is first initiated after a power-up, the telephone will wait a random time between zero and four seconds before broadcasting the first DHCPDISCOVER message.
Rationale:
Section 4.4.1 of RFC 2131 states that “the client SHOULD wait a random time between one and ten seconds to desynchronize the use of DHCP at startup,” but ten seconds is too long, especially for systems with fewer endpoints. Congestion Characteristics of DHCP and TFTP [7.1-12], Section 4.6.3, states that an initial randomized delay can be beneficial in spreading the load when demand is large, but can be detrimental when the load is small.
Approved
Before each DHCPDISCOVER and DHCPREQUEST message is transmitted, any LLDP messages that have been received will be processed as specified in 96x1H-IPI.5.1.260.
Rationale:
Processing received LLDP messages before each DHCPDISCOVER and DHCPREQUEST message is transmitted was a step that was specified in multiple places in the DHCP flowcharts in COMPAS ID 110716 for the 96xx telephones.
Approved
The header fields of transmitted DHCP messages will have values as specified in RFC 2131 p.37 and below:
field
value
htype
1
hlen
6
flags
all zeroes
chaddr
MAC address
sname
unused
file
unused
Rationale:
Even though an htype value of 1 means “Ethernet (10Mb)” as specified on p.163 of RFC 1700, an htype of 6 (“IEEE 802 Networks”) is used for Token Ring (IEEE 802.5) devices.
Approved
The options field of transmitted DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages will contain the following options:
option name
option code
length
value(s)
Host Name
12
9
AVohhhhhh
where o has one of the following values based on the OID (first three octets) of the telephone’s MAC address:
“A” if the OUI is 00-04-0D,
“B” if the OUI is 00-1B-4F,
“E” if the OUI is 00-09-6E,
“L” if the OUI is 00-60-1D,
“T” if the OUI is 00-07-3B, and
“X” if the OUI is anything else, and where hhhhhh are ASCII characters for the hexadecimal representation of the last three octets of the telephone’s MAC address
(see 9xxxHW.2.6.100 in [7.1-2])
DHCP message type
53
1
1 (DHCPDISCOVER) or
3 (DHCPREQUEST) or
8 (DHCPINFORM)
parameter request list (DHCPDISCOVER and DHCPREQUEST messages)
55
5
1 (subnet mask)
3 (router IP address(es))
6 (domain name server IP address(es))
15 (domain name)
NVSSON (site-specific option number)
parameter request list (DHCPINFORM messages)
55
3
6 (domain name server IP address(es))
15 (domain name)
NVSSON (site-specific option number)
where NVSSON is the value of the persistent parameter NVSSON (see 96x1H-IPI.2.1.500).
Rationale:
Option 12 is intended for use with DDNS (Dynamic DNS, see [7.3-11c, 7.3-11d]), in which the DHCP server updates the DNS server with a client’s DNS host name and IP address when the IP address is assigned. Since DNS host names must be unique (at least within the local domain), it is based on the telephone’s MAC address, but since DNS host names must begin with an alphabetic letter, the first two letters will always be “AV” (Avaya’s stock symbol), the third letter will be “A” if the MAC address has the original Avaya OUI, “B” if the MAC address has Avaya’s second OUI, “E” if the MAC address has the Elite OUI, “L” if the MAC address has the Lucent OUI, “T” if the MAC address has the Tenovis OUI, and “X” if the MAC address has any other OUI.
Option 60 uses a value of “ccp.avaya.com” because that is the same value used by the 46xx and 96xx telephones; “ccp” stood for “Converged Communication Products”, which was the name of the telephone development organization when the value was first specified.
Approved
Received DHCP messages with a length (including IP and UDP header octets) of up to at least 1000 octets will be correctly processed.
Note:
Assuming an IP header length of 20 octets, a UDP header length of 8 octets, and a DHCP header length of 236 octets, this leaves 736 octets for options. However, if the DHCP sname and file header fields are “overloaded” using DHCP option 52, up to 928 octets could be used for options.
Rationale:
Option 57 (maximum DHCP message size) was originally set to a value of 576 because 576 is the maximum datagram size guaranteed to work on all IP networks (see RFC 879, Sections 1 and 2), although larger datagrams could be fragmented and reassembled. However, many DHCP servers ignore the maximum size specified in option 57, so the phone should be able to process longer messages.
Approved
Received DHCPOFFER messages will be processed as specified below.
Approved
If a DHCPNAK message is received, “DHCPNAK: message” will be displayed on the reserved text lines for approximately one second, where message is as much of the content of the text field of the message option (#56), if included, as will fit on the remainder of reserved text lines, then the DHCP client will return to the DHCP INIT state, and the appropriate text as specified in flowchart 96x1H-IPI.5.1.600_.___Approved'>96x1H-IPI.5.1.600'>DHCP 1 of 96x1H-IPI.5.1.600 will be redisplayed.
Rationale:
The display of the DHCPNAK message text was a step that was specified in flowchart DHCP 3 in COMPAS ID 110716 for the 96xx telephones.
Approved
Duplicate Address Detection will be performed, as specified in 96x1H-IPI.5.1.700, on any address received in a DHCPACK message before the address is used.
Approved
for R6.3+
However, if the value of DOT1XSTAT is not “0”, Duplicate Address Detection will not be initiated until after 802.1X authentication has completed.
Approved
If an address is found to be in use, a DHCPDECLINE message will be transmitted as specified in Section 4.4.4 of RFC 2131 and “DHCP: CONFLICT” will be displayed on the top reserved text line for approximately 5 seconds, then the DHCP client will return to the INIT state, and the appropriate text as specified in flowchart DHCP 1 of 96x1H-IPI.5.1.600 will be redisplayed.
Rationale:
Performing Duplicate Address Detection on addresses received in Reply messages is a SHOULD requirement in Section 4.4.1 (p.38) of RFC 2131, and was a step that was specified in flowchart DHCP 3 in COMPAS ID 110716 for the 96xx telephones.
Approved
A gratuitous ARP message will not be transmitted if an address conflict is not detected.
Rationale:
Even though broadcasting an ARP Reply “to announce the client’s new IP address and clear any outdated ARP cache entries in hosts on the client’s subnet” is a SHOULD requirement at the end of Section 4.4.1 of RFC 2131, it is not required for proper protocol operation, and the processing of received gratuitous ARP messages (which is disabled by default by the GRATARP parameter) is usually considered to be a poor security practice because it can be used to “poison” ARP caches to spoof an IP address by mapping it to a different MAC address.
Approved
DHCP is considered to have completed successfully only after Duplicate Address Detection has been performed on an IP address received in a DHCPACK message and has completed without detecting a conflict. The content of the DHCPACK message will be retained for further processing as specified in 96x1H-IPI.5.1.600.
The sname and file fields in a received DHCPACK will be interpreted per RFC 2132, Section 9.3 (p.26) if option 52 (Option Overload) is received in the same message.
The DHCP lease time will be set to the value of option #51. If option #51 has a value of FFFFFFFF hex, the IP address lease will be assumed to be infinite (see RFC 2131, Section 3.3 (p.20)), such that renewal and rebinding procedures are not necessary, even if options #58 and/or #59 are received. The DHCP lease renew time will be set to the value of option #58 (if received), and the DHCP lease rebind time will be set to the value of option #59 (if received). If options #58 and/or #59 are not received, or if their values are greater than that of option #51, the default values of T1 (renewal timer) and/or T2 (rebinding timer) will be used per RFC 2131, Section 4.4.5 (p.41).
If and only if the value of NVVPNMODE is “0”, the values of the following parameters will be set based on the fields and options received in the DHCPACK message when DHCP is in the INIT state (converting from binary to ASCII as necessary):
the parameter IPADD will be set to the value of the yiaddr field,
the parameters TLSSRVR and HTTPSRVR will be set to the value of the siaddr field if and only if the siaddr field is non-zero,
the parameter NETMASK will be set to the value of option #1 (if received),
the parameter GIPADD will be set to the value of option #3
(if received, which may be a list of IP addresses),
the parameter DNSSRVR will be set to the value of option #6
(if received, which may be a list of IP addresses),
the parameter DOMAIN will be set to the value of option #15 (if received),
the DHCP lease time will be set to the value of option #51 (if received),
the DHCP lease renew time will be set to the value of option #58 (if received), and
the DHCP lease rebind time will be set to the value of option #59 (if received).
If the value of NVVPNMODE is “1” and the value of VPNACTIVE is “0”, the values of the following parameters will be set based on the fields and options received in the DHCPACK message when DHCP is in the INIT state (converting from binary to ASCII as necessary):
the parameter EXTIPADD will be set to the value of the yiaddr field,
the parameter EXTNETMASK will be set to the value of option #1 (if received),
the parameter EXTGIPADD will be set to the first value of option #3
(if received, which may be a list of IP addresses),
the parameters DNSSRVR and EXTDNSSRVR will be set to the value of option #6
(if received, which may be a list of IP addresses),
the DHCP lease time for EXTIPADD will be set to the value of option #51 (if received),
the DHCP lease renew time for EXTIPADD will be set to the value of option #58 (if received),
the DHCP lease rebind time for EXTIPADD will be set to the value of option #59 (if received).
If the value of NVVPNMODE is “1” and the value of VPNACTIVE is “1”, the values of the following parameters will be set based on the fields and options received in the DHCPACK message (converting from binary to ASCII as necessary):
the parameters TLSSRVR and HTTPSRVR will be set to the value of the siaddr field if and only if the siaddr field is non-zero,
the parameter DNSSRVR will be set to the value of option #6
(if received, which may be a list of IP addresses), and
the parameter DOMAIN will be set to the value of option #15 (if received).
When NVVPNMODE is “1” and VPNACTIVE is “0”, a DHCPACK should only be received in response to a DHCPREQUEST sent to the “outer” DHCP server. When NVVPNMODE is “1” and VPNACTIVE is “1”, a DHCPACK should only be received in response to a DHCPINFORM sent to an “inner” DHCP server (see the flowchart in 96x1H-IPI.4.2.200).
Rationale:
The DNS resolver (see 96x1H-IPI.5.1.750) always gets a DNS server IP address from the DNSSRVR parameter, so in VPN mode, DNSSRVR is first set to the option #6 value(s) received from the external (“outer”) DHCP server, to be used to resolve any DNS name values of NVSGIP (VPN Security Gateway IP addresses). However, once a VPN tunnel is established, DNSSRVR is set to value(s) received via the ISAKMP configuration method (see 96x1H-IPI.5.1.320) and/or via a configuration file, which should provide the address(es) of internal DNS servers that can resolve both internal and external DNS names (whereas an external DNS server will not be able to resolve internal DNS names). The option #6 value(s) received from the external DHCP server are also saved in EXTDNSSRVR because if the VPN tunnel fails, the value of DNSSRVR is set back to the external value(s) (see 96x1H-IPI.4.2.200).
Approved
The requested site-specific option will be processed (if it was received) as specified in 96x1H-IPI.5.1.600, unless the telephone is in the RENEWING, REBINDING or “extended” REBINDING state. Site-specific options that were not requested will not be processed.
When DHCP is in the RENEWING, REBINDING or “extended” REBINDING state, only the DHCP lease time values will be set as specified above.
If a parameter specified in 96x1H-IPI.2.1.600, 96x1H-IPI.2.1.650, 96x1H-IPI.2.1.800 or
96x1H-IPI.2.1.900 is set from a value in a DHCPACK field or option, a separate copy of that value will be saved in volatile memory as part of a set of all and only such values that were explicitly set from the DHCPACK.
Note:
H.323 requirements specify (see Step 24 of 96x1Tel.2.1.400 and Step 30 of 96x1Tel.2.1.500 in [7.1-6]) that this set of values be saved in non-volatile memory only after a successful registration with a call server, for potential reuse during a subsequent startup if a DHCPOFFER is not received.
Note:
The requirements listed above specify named parameters that can be set from a DHCPACK field or option, but do not include L2QVLAN or any values that are saved in a corresponding persistent (NV) parameter that is set whenever the parameter is set. IP address lease time, renew time and rebind time are set from options in a DHCPACK, but they are not named parameters and are not specified in the listed requirements, so they should also not be saved as part of this set of values.
Approved
If the value of the parameter DHCPSTD is “1” and the phone does not receive either a DHCPACK or a DHCPNAK by the time the IPv4 address lease expires, the phone will immediately cease use of the IPv4 address and IPADD will be set to null, if dual-stack operation is enabled the phone will also cease use of its IPv6 address and IPADDV6 will be set to null, and the name/logo screen will be displayed as specified in 96x1H-IPI.3.1.100 with “DHCP Lease Expired” on the top reserved text line for approximately 5 seconds. If a reset is required to enter the DHCP INIT state, “Resetting” will also be displayed on the bottom reserved text line and a reset will be executed as specified in 96x1H-IPI.3.1.100, otherwise, operation will proceed as specified in 96x1H-IPI.5.1.600.
If the value of the parameter DHCPSTD is “0” and the phone does not receive either a DHCPACK or a DHCPNAK by the time the IP address lease expires, it will continue to use the IP address and will enter an “extended” REBINDING state in which a DHCPREQUEST message will continue to be broadcast at the maximum retransmission interval and Duplicate Address Detection will be performed for the IP address, as specified in 96x1H-IPI.5.1.700, every 5 seconds. In this state, if a DHCPACK is received, it will be processed, Duplicate Address Detection will no longer be performed, and the phone will enter the DHCP BOUND state. If an IP address conflict is detected, the telephone will immediately stop using its current IP address, “DHCP: CONFLICT” will be displayed for approximately 5 seconds, IPADD will be set to null, Duplicate Address Detection will no longer be performed, the DHCP client will enter the DHCP INIT state, and operation will proceed as specified in 96x1H-IPI.5.1.600.
Approved
If a DHCPNAK is received in the RENEWING, REBINDING or “extended” REBINDING state, the telephone will immediately stop using its current IPv4 address, “DHCPNAK: message” will be displayed on the top reserved text line for approximately 5 seconds, where message is as much of the contents of the text field of the message option (#56), if included, as will fit, IPADD will be set to null, Duplicate Address Detection will no longer be performed, if dual-stack operation is enabled the phone will also cease use of its IPv6 address and IPADDV6 will be set to null, and operation will proceed as specified in 96x1H-IPI.5.1.600.
Note:
Setting the BROADCAST bit in the flags field to zero implies that the IP stack can receive unicast datagrams (layer 2 frames with the phone’s MAC address) before the IP address is established, as specified in 96x1H-IPI.5.1.304.
Note:
The maximum length of any option (including site-specific options and the Vendor Specific Information option) is 255 octets. The maximum length of parameter names and values is specified in 96x1H-IPI.2.1.50.
Note:
An example of a string of name=value pairs that could be used in the requested site-specific option could be:
Other values may also be set in this string, and would supercede any values received in any other DHCP fields or options for the same parameter.
Rationale:
BOOTP is not supported (even though Cisco supports it, or at least they did at one time) because it does not support the ability for an endpoint to decline an IP address if a conflict is detected, or to release an IP address if the phone needs to change VLANs.
IP address information received via DHCP is not stored in persistent parameters (non-volatile memory) because, with a finite lease, the telephone does not know at power-up whether the lease is still valid, and even with an infinite lease, the telephone may have been moved to another subnet while it was powered down and the address may no longer be valid. A client is not required to explicitly request a previously allocated IP address (see RFC 2131, Section 3.2), but a DHCP server should respond with the IP address previously allocated to the client if it is still valid (see RFC 2131, section 4.3.1). Because the exponential backoff algorithm used by DHCP can result in relatively long delays between DHCPDISCOVER attempts, the number of elapsed seconds is displayed so the telephone doesn’t look like it has “locked up”.
The telephone does not send a DHCPINFORM message if it is using a manually programmed IP address as described in RFC 2131, Section 4.4.3 (p.39) because it is not required and it could result in a long delay before the IP address could be used.
IETF STD 3 (RFC 1123, Section 6.2.2.1, p.88-89) recommends supplying the subnet mask using a BOOTP extension (option #1) defined in RFC 1084 (which was obsoleted by RFC 1497 which, in turn, was superceded by RFC 2132 for DHCP as well as BOOTP).
Option 7 (log server) is not used to set the value of LOGSRVR because it could cause telephone to send event messages to a log server that the customer may be using for other purposes.
Option 51 (IP address lease time) is not requested because it MUST be sent by a DHCP server, so it isn't necessary to request it. In fact, some DHCP servers will automatically use the requested lease time in the DHCPOFFER instead of the lease time set in the server by the LAN administrator, which defeats their ability to control lease times. Options 58 (lease renewal (T1) time value) and 59 (lease rebinding (T2) time value) are also not requested because default values are defined (see RFC 2131, Section 4.4.5, paragraph 6), so they only need to be sent if the server wants the client to use non-default values.
Option 61 (client identifier) is not transmitted by the telephone because there doesn’t seem to be any good reason to use an identifier other than the telephone’s MAC address, which is already provided in the ‘chaddr’ field, and servers MUST use the ‘chaddr’ field anyway if the client does not provide a ‘client identifier’ option (see RFC 2131, Section 4.2, p.26).
Continuing to use a leased IP address after the expiration of the lease violates the last paragraph of RFC 2131, Section 4.4.5. However, DHCP was standardized before IP was used for telephony and it seems somewhat drastic to cut off phone service if the lease renewal fails due to the DHCP server being out-of-service since, in that case, it also wouldn’t be assigning the IP address to another endpoint (although it could if a WAN connection to the server failed but other endpoints were still able to contact it). ARP REQUEST messages are transmitted in case the lease renewal fails due to a network outage, in which case the IP address could be assigned to another endpoint before network connectivity is restored.
