96x1H-IPI.5.1.606: Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Approved
DHCPv6 will be supported as specified by IETF RFC 3315 [7.3-42e] and by requirements below.
Rationale:
Support of DHCPv6 as specified in RFC 3315 is required by Requirements 10 and 10.2 in Section 5.3.5.4.4 of UCR 2008 [7.8-1d].
Approved
DHCPv6 will use UDP as a transport-layer protocol (see 96x1H-IPI.5.1.400), but messages received on the DHCPv6 UDP port will only be processed if they are received in response to a message transmitted by the telephone.
Before each Solicit and Request 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(v4) flowcharts in COMPAS ID 110716 for the 96xx telephones.
Note:
Section 17.1.2 of RFC 3315 states that the client transmits Solicit messages according to Section 14, with a Maximum Retransmission Count (MRC) and a Maximum Retransmission Duration (MRD) of 0, and Section 14 states that if both MRC and MRD are zero, the client continues to transmit the message until it receives a response, so compliance with the requirement above to support RFC 3315 also provides compliance with UCR 2008 Change 3 Section 5.3.5.4.4 requirement 10.2.2, because a solicitation message exchange will never fail, it will continue until a response is received.
Approved
The telephone will use a DHCP Unique Identifier (DUID) based on the link-layer (MAC) address in the value of MACADDR (a DUID-LL), as specified in Section 9.4 of RFC 3315.
Approved
Received DHCPv6 messages that contain options that are not allowed to appear in the received message type will be discarded. All options contained in such messages will be ignored.
Rationale:
Discarding received messages that contain disallowed options is a SHOULD requirement in Section 15 of RFC 3315 (even though specific message requirements in subsections of Section 15 specify that they MUST be discarded if an inappropriate option is included), but it is required by Requirement 10.1 in Section 5.3.5.4.4 of UCR 2008 [7.8-1d].
Approved
If the first Retransmission Timeout has elapsed since a Solicit message was transmitted and one or more Advertise message(s) have been received but none of the Advertise message(s) have a preference value of 255, a Request message will be sent to the server whose Advertise message had the highest preference value.
Rationale:
Sending a Request message to a server whose Advertise message has a preference value less than 255 if no Advertise message with a preference value of 255 is received by the expiration of the first Retransmission Timeout is a SHOULD requirement in Section 17.1.2 of RFC 3315, but is required by Requirement 10.2.1 in Section 5.3.5.4.4 of UCR 2008 [7.8-1d].
Issue:
Does the requirement above preclude support of the Rapid Commit option specified in Section 22.14 of RFC 3315?
Approved
In addition to the mandatory options as specified in RFC 3315, each Solicit and Request message transmitted by the telephone will contain:
an Option Request Option (option 6) that contains option codes of 3 (Identity Association for Non-Temporary Addresses), and 17 (Vendor-Specific Information),
a Vendor Class Option (option 16) with an enterprise-number of 6889 and two vendor-class-data instances, one that contains the value of the parameter MODEL, and one that contains the value of the parameter APPINUSE.
Options received in valid DHCPv6 messages that were not specifically requested in the Option Request Option, and for which processing is not specified, will be ignored.
Rationale:
Section 17.1.1 of RFC 3315 states that Solicit messages may not contain options except as specifically allowed in the definition of the individual option. An Option Request option SHOULD (per Section 17.1.1) and MAY (per Section 22.7) be included in a Solicit message. While there is no text in the definition of the Vendor Class option (Section 22.16) that specifically allows it to be included in a Solicit message, the table in Section A (p.98) indicates that it is allowed.
Approved
Authentication of DHCPv6 messages will not be supported.
Rationale:
Authentication of DHCPv6 messages is not required by UCR 2008 [7.8-1d], and it would require an out-of-band key distribution mechanism that is not specified by RFC 3315 (see Section 21.4.3 of RFC 3315).
Approved
The telephone will not transmit Information-Request messages.
Rationale:
Since the telephone will request configuration information by including an Option Request option in transmitted Request messages, there is no need to send Information-Request messages.
Approved
Reconfigure messages will not be supported. The telephone will not transmit a Reconfigure Accept option, and it will ignore a received Reconfigure Accept option.
Rationale:
Since Authentication of DHCPv6 messages is not supported (see above), and since clients MUST discard any received Reconfigure messages that do not include or pass authentication (see Section 15.11 of RFC 3315), Reconfigure messages cannot be supported.
Approved
If a Reply message is received with a Status Code option that contains a status-code of 1 (UnspecFail), “DHCPv6 Failure: message” will be displayed on the reserved text lines for approximately one second, where message is as much of the content of the status-message field as will fit on the remainder of reserved text lines, then DHCPv6 will be restarted and the appropriate text as specified in flowchart DHCP 1 of 96x1H-IPI.5.1.600 will be redisplayed.
If an IPv4-Mapped IPv6 address is received in an IA Address option in a Reply message, a Decline message will be immediately sent for that address, and after a corresponding Reply message is received, another Request message will be sent to the same server.
Rationale:
The IPv6 stack being used uses IPv4-Mapped IPv6 addresses internally to represent IPv4 addresses when dual-stack mode is enabled. Because of this, IPv4-Mapped IPv6 addresses are always converted to IPv4 addresses and used in IPv4 packets when they are transmitted. Therefore, IPADDV6 cannot be allowed to have a value that is an IPv4-Mapped IPv6 address. A Note following Requirement 8 in Section 5.3.5.4.3 of UCR 2008 [7.8-1d] also states that” the use of “IPv4 Mapped” addresses “on the wire” is discouraged due to security risks raised by inherent ambiguities.”
Approved
Duplicate Address Detection will be performed as specified in 96x1H-IPI.5.1.306 on any address received in a Reply 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 Decline message will be sent for that address, and the telephone will restart sending Solicit messages.
Rationale:
Performing Duplicate Address Detection on addresses received in Reply messages is a SHOULD requirement in Section 18.1.8 of RFC 3315, but UCR 2008 Change 3 [7.8-1d] requires that it be able to be enabled and disabled. See 96x1H-IPI.5.1.306 for further clarification.
The server SHOULD mark a declined address so that it is not assigned to any clients for some period of time (see Section 18.2.7 of RFC 3315), so requesting another address from the same server should be more appropriate than sending another Solicit message. RFC 3315 does not specify what to do in this case.
Approved
DHCPv6 is considered to have completed successfully only after Duplicate Address Detection has been performed on an IP address received in a Reply message and has completed without detecting a conflict. The parameter IPADDV6 will be set to the IPv6 address contained in the IA Address option in the Reply message, and the content of the Reply message will be retained for further processing as specified in 96x1H-IPI.5.1.600.
If a Vendor-Specific Information option (option 17) is received in a Reply message with an enterprise number of 6889, and if it contains a vendor-specific option with an opt-code of 242, the option-data portion of that option will be processed as specified in 96x1H-IPI.5.1.600. All other Vendor-Specific Information options and vendor-specific options will be ignored.
Rationale:
The Avaya Chief Technical Officer organization was contacted via email on 10/16/09 to inquire whether anyone in Avaya was responsible for managing the DHCPv6 Vendor-Specific Information opt-code numbers for Avaya’s enterprise number, and they replied that it was not yet being managed. Opt-code 242 was chosen because it corresponds to the default DHCPv4 site-specific option number (NVSSON).
Approved
If a response has not been received to any of the transmitted Rebind messages by the time the IP address lease expires, the phone will immediately cease use of the IP address and IPADDV6 will be set to null, if dual-stack operation is enabled the phone will also cease use of its IPv4 address and IPADD will be set to null, and operation will proceed as specified in 96x1H-IPI.5.1.600.
If a Reply message is received in response to a Renew or Rebind message with a Status Code option that contains a status-code value other than 0 (Success) or 5 (UseMulticast), “DHCPv6 Failure: message” will be displayed on the top reserved text line for approximately 5 seconds, where message is as much of the content of the status-message field as will fit, IPADDV6 will be set to null, if dual-stack operation is enabled the phone will also cease use of its IPv4 address and IPADD will be set to null, and operation will proceed as specified in 96x1H-IPI.5.1.600.
A retry timer/mechanism is not specified for ARP; however, IETF RFC 1122, Section 2.3.2.1, states that, “A mechanism to prevent ARP flooding (repeatedly sending an ARP Request for the same IP address, at a high rate) MUST be included. The recommended maximum rate is 1 per second per destination.”
Note:
ARP is used at power-up and after a reset to try to determine whether IPADD, as initialized from a manually-programmed value or as set from a value obtained via DHCP (see 96x1H-IPI.5.1.600), is already in use by another endpoint. ARP is also used to obtain the MAC address for any endpoint on the telephone’s own IP subnet for which the MAC address is not already known.
Rationale:
The use of ARP for address translation from Internet addresses to link-layer addresses is required by IETF STD 3 (RFC 1122, Section 2.3.3).
Approved
The ARP cache will be cleared after every power-up or reset.
Note:
The ARP cache is a table of entries that contain information obtained via ARP. Each ARP cache entry maps an IP address to a MAC address. ARP cache entries may also contain a timeout value per Section 2.3.2.1 of RFC 1122 [7.3-3a].
Approved
An ARP REQUEST will only be sent for a unicast IP address, and an ARP cache entry will only be created or updated if the source hardware address (ar$sha) field in the ARP REPLY contains a unicast MAC address.
Note:
ARP is not used for multicast. Multicast host group (class D) IP addresses are directly mapped to MAC addresses as specified in Section 6.4 of RFC 1112 [7.3-4f].
Note:
A unicast MAC address always has a first bit equal to zero. The first bit is the least significant bit of the first octet, which is transmitted first.
Approved
The MAC address associated with an IP address in an ARP cache entry will only be set to a unicast MAC address contained in the source hardware address (ar$sha) field in the first unicast ARP REPLY message received in response to a ARP REQUEST message transmitted by the telephone for that IP address.
If the value of GRATARP is "1", the MAC address associated with an IP address in an ARP cache entry will also be set to a unicast MAC address contained in the source hardware address (ar$sha) field received in an unsolicited ("gratuitous") broadcast ARP REQUEST or ARP REPLY in which the source protocol address (ar$spa) and target protocol address (ar$tpa) fields both match the IP address in the ARP cache entry.
Note:
A “gratuitous” ARP is a broadcast ARP REQUEST or ARP REPLY message in which the sender includes its own MAC and IP addresses in the appropriate source address fields and also includes its own IP address (but not its MAC address) in the target IP address field. These are sometimes sent by a device for the sole purpose of keeping other devices informed of its current IP address, and some failover mechanisms that reuse an existing IP address with a different MAC address also use gratuitous ARP messages to “announce” the address change, such as the Processor Ethernet Duplication capability specified in COMPAS ID 134539. However, they can also be used to “poison” ARP caches by changing the mapping of an IP address to a different MAC address in an attempt to cause messages intended for that IP address to be sent to a different MAC address (sometimes called “spoofing”).
Rationale:
Received gratuitous ARP messages are ignored by default because of their potential use for ARP cache poisoning.
Approved
Only the time-to-live attribute of an existing ARP cache entry will be refreshed based on the reception of any frame that has the same source MAC address and source IP address as the ARP cache entry; the MAC address associated with the IP address will not be changed based on the reception of a frame with a different source MAC address if it contains the same source IP address.
Approved
for R6.0.4+
An entry will be removed from the ARP cache if and only if 20 minutes have elapsed since a message was received with a source MAC address and source IP address that correspond to that entry.
Rationale:
It is important to remove stale ARP cache entries because, for example, if a telephone is removed from the subnet and its IP address is given to a new telephone by DHCP, other telephones sending RTP packets to that IP address would send them to the old MAC address (which would be perceived as a one-way audio path) until they happen to reset and clear their ARP cache.
Section 2.3.2.1 of RFC 1122 specifies that ARP implementations MUST provide a mechanism to flush out-of-date cache entries, but that if the mechanism involves a timeout, that it SHOULD be possible to configure the timeout value. It also recommends that if a timeout is used, that it be on the order of a minute or less. However, it also states that in the absence of proxy ARP (which is now obsolete; see the Note below), that a timeout this short could create noticeable overhead traffic on a very large Ethernet and that, therefore, it may be necessary to configure a host to lengthen the ARP cache timeout. A short ARP cache timeout could also make a device more susceptible to ARP cache “poisoning”. Linux seems to have a default ARP cache timeout of 40 seconds, where VxWorks (used by the 96xx telephones) had a default value of 20 minutes.
Note:
A mechanism was introduced in RFC 925: Multi-LAN Address Resolution, October 1984 (status currently listed as UNKNOWN by the IETF) that was later called “proxy ARP” on p.21 of RFC 1009: Requirements for Internet Gateways, June 1987 (but RFC 1009 was obsoleted by RFC 1812: Requirements for IP Version 4 Routers, June 1995, which does not mention proxy ARP at all). Proxy ARP is also mentioned in RFC 1027: Using ARP to Implement Transparent Subnet Gateways, October 1987, (status currently listed as UNKNOWN by the IETF).
Approved
An ARP REPLY will only be transmitted in response to a received broadcast ARP message with:
ar$op = 1 (ARP REQUEST),
ar$hrd = 1 (Ethernet),
ar$pro = 2048 (IPv4; 0800 hex),
ar$tpa equivalent to the parameter IPADD, and
ar$sha equivalent to a unicast MAC address,
and a reply need not be sent to more than 2 ARP REQUESTs per second from up to 10 different values of ar$spa (source IP address).
Rationale:
The intent of sending an ARP REPLY only to a unicast MAC address is to not propagate a denial of service attack by responding to a broadcast or multicast address.
The telephone is only required to respond to 2 ARP REQUESTs per second per source IP address to enable it to improve its resilience to denial of service attacks (see 96x1H-IPI.5.2.200). RFC 1122, Section 2.3.2.1, states that any single endpoint should not be sending more than 1 ARP REQUEST per second per IP address anyway.
Approved
Duplicate Address Detection (checking an IPv4 address for potential conflicts) will be performed by broadcasting an ARP message with:
ar$op = 1 (ARP REQUEST),
ar$hrd = 1 (Ethernet),
ar$pro = 2048 (IPv4 protocol; 0800 hex),
ar$tpa (target IP address) equivalent to the parameter IPADD,
ar$spa (source IP address) equivalent to 0.0.0.0, and
ar$sha (source hardware (MAC) address) equivalent to the telephone’s MAC address.
If a corresponding ARP REPLY is received within one second, an IP address conflict will be assumed. If a corresponding ARP REPLY is not received within one second, it will be assumed that there is no conflict.
Note:
Checking for conflicting use of the IP address in a DHCPACK message by sending the above ARP REQUEST (sometimes called a :DHCP ARP”) before actually starting to use the IP address is recommended by DHCP (see RFC 2131, Section 4.4.1, p.38). However, the gratuitous ARP REPLY that is recommended to be sent if an ARP REPLY is not received in response to the ARP REQUEST (see RFC 2131, Section 4.4.1, p.39) is not supported (see 96x1H-IPI.5.1.604).
A waiting time of one second was originally specified, somewhat arbitrarily, to give other endpoints a chance to reply to the IP address conflict check, but was kept short so as not to delay startup. It is assumed that DHCP will be used most of the time and that DHCP servers will do a competent job of managing IP addresses so that conflicts are rare.
