96x1H-IPI.5.1.500: Transmission Control Protocol (TCP)
Approved
TCP will be supported as specified in IETF STD 7 (RFCs 793 and 879) [7.3-6a,b], IETF STD 3 (RFC 1122) Section 4.2 [7.3-3a], RFC 1948 [7.3-6e], and RFC 2581 [7.3-6f].
All SHOULD requirements in RFC 2581 will be treated as MUST requirements.
TCP timestamps (see IETF RFC 1323 [7.3-6d]) will not be supported.
TCP segments with a length up to and including 1460 octets will be able to be received, and the Maximum Segment Size option will be transmitted with a value of 1460.
TCP segments with a length up to and including 1456 octets will be able to be transmitted, and TCP segments longer than 1456 octets will not be transmitted.
Rationale:
Older Ethernet switches that do not support 802.1Q tagging (see 96x1H-IPI.5.1.220) may drop frames that are longer than 1518 octets. Assuming a layer 2 tagged header and FCS of 22 octets, an IP header of 20 octets and a TCP header of 20 octets, this results in a TCP maximum segment size (MSS) of 1456 octets. While it seems that the Maximum Segment Size option should also be transmitted with a value of 1456, that reportedly causes other networking problems.
Approved
Port numbers used with TCP will be as specified below and as specified in H.323 requirements. Messages will not be transmitted to unspecified TCP destination ports. Unspecified TCP destination ports on the IP telephone will remain closed at all times. TCP messages received for closed ports will be discarded without transmitting any TCP message(s) in response (e.g., TCP RST messages).
Received packets (the IP telephone is the Destination):
The port number received in the TransportAddress field in the RCF message
1720
H.323 signaling messages
Note:
If a port number is specified by the optional port part of the value of SLMSRVR, the SLA Monitor agent will only initiate registration if the discovery message from the server contains that same port number.
Note:
Some data networking equipment supports a quality of service (QOS) mechanism called ‘port selection’ by which packets with port numbers in a certain range are given priority over other packets. Because this range is not standardized, the telephone needs to be able to be told by the server what port(s) to use.
Note:
The use of TCP keep-alives is permitted, but not really encouraged, by RFC 1122, p.101-102. Any use of TCP keep-alives should be specified by protocol-specific requirements.
Rationale:
The TCP Maximum Segment Size option communicates the maximum receive segment size. The transmission of the TCP Maximum Segment Size option is required in RFC 1122, Section 4.2.2.6 and is defined to be the IP maximum datagram size minus 40 in RFC 879, p.1. The maximum IP datagram size is the same as the MTU (Maximum Transmission Unit, defined in RFC 1122 [7.3-3a], p.19), which is 1500 octets for an Ethernet frame and 1492 for an IEEE 802.3 frame (specified in RFC 1122, p.25). Therefore, the TCP Maximum Segment Size for Ethernet is 1500 – 40 = 1460.
A security vulnerability was identified with TCP timestamps in a CERT advisory (see 5/17/05 email from Jason Shirk).
All of the display messages specified in this requirement will be displayed with the priority specified for Generic Startup screens by 96x1COPS.7.2.200 in [7.1-4], unless otherwise specified.
DHCP will be initiated as specified in the flowcharts below.
Approved
If only the DHCPv4 client was initiated, upon successful completion the information in the DHCPACK message will be processed as specified in 96x1H-IPI.5.1.604 and below, but instead of changing the actual values, a list of potential value changes resulting from the message will be created.
If only the DHCPv6 client was initiated, upon successful completion the information in the Reply message will be processed as specified in 96x1H-IPI.5.1.606 and below, but instead of changing the actual values, a list of potential value changes resulting from the message will be created.
If both the DHCPv4 and DHCPv6 clients were initiated, upon successful completion the information in the DHCPACK and Reply messages will be processed as specified in 96x1H-IPI.5.1.604 and 96x1H-IPI.5.1.606, respectively, but instead of changing the actual values, separate lists of potential value changes resulting from each message will be created. The two lists will then be combined into a single list, and any conflicts over new values will be resolved based on the value of the parameter DHCPPREF. If the value of DHCPPREF is “4”, values from the DHCPACK message will override values from the Reply message. If the value of DHCPPREF is “6”, values from the Reply message will override values from the DHCPACK message. All values for which there is no conflict will be included in the final list.
If the value of ReuseCheck is 1 (as set in flowchart DHCP 2b) and the list of potential value changes contains a value for L2QVLAN that is also a value of NVVLANLIST, all IP addresses that were obtained via DHCP or DHCPv6 will be released, the list of values will be discarded, and processing will continue at flowchart entry point DHCP 2c. Otherwise, the values on the list will be used to set the corresponding parameters.
Rationale:
The ReuseCheck test prevents infinite looping if separate DHCP servers are used for voice and data VLANs and a response is received from the DHCP server on the data VLAN, but a response is not received from the DHCP server on the voice VLAN (this really happened at a customer site).
Note:
If the content of a DHCPACK is used to configure the telephone, a copy of all of the settings used must be saved in volatile memory for potential saving in non-volatile memory as specified in Step 24 of 96x1Tel.2.1.400 and Step 30 of 96x1Tel.2.1.500 in [7.1-6], for potential reuse during a subsequent startup if a DHCP server cannot be contacted, as specified in flowchart DHCP 2b above. Reuse is not currently supported for DHCPv6.
Approved
If a reset is not initiated, and if the value of NVVPNMODE is “1”, the in-use router IP address will be set to the value of EXTGIPADD, and VPN procedures will be initiated as specified in 96x1H-IPI.4.2.200.
If the value of NVVPNMODE is “0”, processing will continue at flowchart 2 in 96x1H-IPI.3.1.100.
Rationale:
The above requirement was previously at the bottom of flowchart DHCP 3 in COMPAS ID 110716 for the 96xx telephones.
Approved
The content of a DHCP site-specific option (see 96x1H-IPI.5.1.604) and the content of the option-data portion of a DHCPv6 vendor-specific option (see 96x1H-IPI.5.1.606) will be processed as specified below.
Approved
If any portion of the content does not match the format of name=value pairs separated by commas, or if there is no parameter with a name that matches name, or if setting that parameter via DHCP name=value pairs is not allowed, or if value is not valid for that parameter, that portion of the content will be ignored.
If a parameter is supported with a name that matches the name in a name=value pair, its value will be set equal to the value of the pair, if setting that parameter via DHCP name=value pairs is allowed and if the value is valid as specified in Section 2.1 of this document. All names will be treated as case-insensitive. The case of values will be preserved. To include spaces, tabs or commas in a value, the entire value will be enclosed in double quotes. Spaces preceding and following commas and equals signs outside of double quotes will be ignored.
The parameters L2Q and L2QVLAN will not be set from a value received in a name=value pair if the parameter was previously set via LLDP, and SIG will not be set from a value received in a name=value pair if it was previously set via the SIG Craft Local procedure (see 96x1LA.6.2.1600H in [7.1-5].
Note:
Indications as to whether the values of non-volatile parameters (L2Q, L2QVLAN and SIG) were set via a specific mechanism must also be maintained in non-volatile memory, and should be reset to “no” when the parameter is initialized to its default value by the CLEAR or the Reset Values procedures.
Note:
Since the site-specific (DHCPv4) or vendor-specific (DHCPv6) option is processed after the DHCP fields and standard options, any values set in the site-specific or vendor-specific option will supersede any values set via DHCP fields or standard options, as well as any other previously set values.
