96x1H-IPI.5.1.304: Internet Protocol version 4 (IPv4) and Internet Control Message Protocol (ICMP) |
Approved
|
IPv4 will be supported as specified by the IETF RFCs and other requirements below.
STD 5: RFC 791 (Internet Protocol) [7.3-4a]
STD 3: RFC 1122 (Requirements for Internet Hosts - Communication Layers) Section 3 [7.3-3a]
The Version field in transmitted IP datagrams will be set to 4.
The IHL (Internet Header Length) field will be set to 5 and the minimum size internet header (i.e., no options will be included) will be transmitted, except when responding to a source route option per RFC 1122, Section 3.2.1.8 (c), p.36. Any other options in received IP datagrams will be ignored.
Type of Service bits 0-5 will be set to a Differentiated Services Code Point (DSCP) value, as specified in Section 3 of RFC 2474 (Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers) [7.3-27a], that is the binary equivalent of the decimal value of one of the following:
|
|
DSCPBBE (see 96x1H-IPI.2.1.1400) for transmitted audio (RTP, RTCP, SRTP and SRTCP) packets if the value of the parameter RSVPCONT is “1” and a reservation has not been successfully obtained for the audio connection (see 96x1H-IPI.5.1.350);
DSCPAUD (see 96x1H-IPI.2.1.1200) for transmitted audio (RTP, RTCP, SRTP and SRTCP) packets if the value of the parameter RSVPCONT is “0”, or if the value of RSVPCONT is “1” and a reservation has been successfully obtained for the audio connection (the DSCP value will change from DSCPBBE to DSCPAUD if the reservation is obtained after the audio connection is established);
DSCPSIG (see 96x1H-IPI.2.1.1200) for transmitted H.323 signaling and RSVP packets;
zero for all other transmitted packets (e.g., ICMP, DHCP, DNS, HTTP, SNMP, etc.).
Received DSCP information will be ignored.
|
Note:
|
Support of the DiffServ QoS mechanism is provided through the use of the DSCPAUD and DSCPSIG values in the IP Type of Service (TOS) bit positions 0-5 (formerly the Precedence, Delay, Throughput and Reliability fields, now called the Differentiated Services Code Point), as specified in RFC 2474 [7.3-27a] and RFC 2475 [7.3-27b].
|
Note:
|
Avaya RSVP usage is specified in [7.1-15].
|
Approved
|
IP datagrams with lengths of up to 1500 octets will be able to be transmitted and received when the value of NVVPNMODE is “0”, and for “outer” IP datagrams (see 96x1H-IPI.5.1.310) when the value of NVVPNMODE is “1”. IP datagrams with lengths of up to 1372 octets will be able to be transmitted for “inner” IP datagrams when the value of NVVPNMODE is “1”.
|
Rationale:
|
The MTU size is set at 1500 octets because that is the maximum Ethernet data field length, so it is the maximum size that can be supported without fragmentation. For VPN operation, the MTU size of “inner” IP datagrams is set to 128 octets less than for “outer” IP datagrams to avoid fragmentation of outbound IPsec packets. The value 128 came from 108639.2.2.375 in COMPAS ID 108639 [7.1-28].
|
Approved
|
The Time to Live field will be set to 64 (40 hex) in all transmitted IP datagrams.
|
Rationale:
|
A default Time-To-Live field value of 64 is recommended in RFC 1700 [7.3-2] p.64.
|
Note:
|
The following values are specified for use in the Protocol field:
|
|
|
decimal
|
hex
|
protocol
|
reference(s)
|
|
|
1
|
01
|
ICMP
|
RFC 1700 p.8, RFC 792 p.2
|
|
|
2
|
02
|
IGMP
|
RFC 1700 p.8, RFC 2236 p.2
|
|
|
6
|
06
|
TCP
|
RFC 1700 p.8
|
|
|
17
|
11
|
UDP
|
RFC 1700 p.8, RFC 768 p.3
|
|
|
46
|
2E
|
RSVP
|
RFC 1700 p.9, RFC 2205 p.48 (Section 3.3)
|
|
|
50
|
32
|
ESP
|
RFC 1700 p.9, RFC 2406 p.3
|
|
|
51
|
33
|
AH
|
RFC 1700 p.9, RFC 2402 p.3
|
Approved__Any_fragmented_ICMP_messages_that_are_received_will_be_ignored._If_the_value_of_the_parameter_ICMPDU_(see_96x1H-IPI.2.1.1100'>Approved
|
The value of the parameter IPADD will be used as the Source Address in transmitted IP datagrams when the value of NVVPNMODE is “0”, and as the Source Address in transmitted “inner” IP datagrams (see 96x1H-IPI.5.1.310) when the value of NVVPNMODE is “1”. The value of the parameter EXTIPADD will be used as the Source Address in transmitted “outer” IP datagrams when the value of NVVPNMODE is “1”.
The Destination Address field will be ignored in received IP datagrams.
|
Rationale:
|
The IP Destination Address field will be ignored on received datagrams if the MAC layer destination address of the frame in which it is received exactly matches the MAC address of the phone in order to resolve the BOOTP/DHCP “chicken and egg” issue identified in RFC 1542, p.9. 96x1H-IPI.5.1.200 requires that only unicast frames that contain the telephone’s MAC address as the MAC layer destination address will be processed.
|
Approved
|
STD 5: RFC 950 (Internet Standard Subnetting Procedure) [7.3-4b]
The value of the parameter NETMASK will be used as the subnet mask when the value of NVVPNMODE is “0”, and the value of the parameter EXTNETMASK will be used as the subnet mask when the value of NVVPNMODE is “1”.
|
|
STD 5: RFC 919 (Broadcasting Internet Datagrams) [7.3-4c]
STD 5: RFC 922 (Broadcasting Internet Datagrams in the Presence of Subnets) [7.3-4d]
The “all ones” value (255.255.255.255) will be used in the Destination Address field in all broadcast IP datagram transmissions and will assume that an “all ones” value in the Destination Address field of a received IP datagram means that the datagram was broadcast.
|
|
STD 5: RFC 792 (Internet Control Message Protocol - ICMP) [7.3-4e]
|
Note:
|
Although, according to RFC 792, ICMP “must be implemented by every IP module,” it does not seem to require the generation of many of the messages (the wording used is that a host may send the message when some event occurs) or to do anything in particular when many of the messages are received. Some are required or strongly suggested by RFC 1122, Section 3.2.2.
|
Approved
|
Any fragmented ICMP messages that are received will be ignored.
If the value of the parameter ICMPDU (see 96x1H-IPI.2.1.1100) is “2”, a Destination Unreachable message with a code of 2 (Protocol Unreachable) will be transmitted if the designated transport protocol is not supported, and a Destination Unreachable message with a code of 3 (Port Unreachable) will be transmitted if a closed TCP or UDP port is designated (see 96x1H-IPI.5.1.400_and_96x1H-IPI.5.1.500'>96x1H-IPI.5.1.400 and 96x1H-IPI.5.1.500), per RFC 1122, Section 3.2.2.1, p.39-40, but no more than 2 such messages will be transmitted per second; additional messages that designate an unsupported transport protocol or port may be ignored.
If the value of the parameter ICMPDU is “1”, a Destination Unreachable message will not be transmitted in response to received datagrams for which the designated transport protocol is not supported, or in response to datagrams that designate closed TCP ports. A Destination Unreachable message with a code of 3 (Port Unreachable) will be transmitted only in response to datagrams that designate closed UDP ports with port numbers greater than 32,767 and less than 35,000, but no more than 2 such messages will be transmitted per second; additional messages that designate an unsupported transport protocol or port may be ignored.
If the value of the parameter ICMPDU is “0”, Destination Unreachable messages will not be transmitted.
Received ICMP Destination Unreachable messages will be ignored unless they are in response to a transmitted traceroute message (see 96x1H-IPI.5.1.450) or in response to a path MTU discovery attempt (an IP datagram transmitted with the Don’t Fragment bit set) per RFC 1191 (see 96x1H-IPI.5.1.500).
|
Note:
|
RFC 792 requires that Destination Unreachable messages include “The internet header plus the first 64 bits of the original datagram’s data. Some versions of traceroute (see 96x1H-IPI.5.1.450) depend on the return of this data for proper operation.
|
Rationale:
|
The parameter ICMPDU is supported to limit or eliminate the transmission of Destination Unreachable messages because they reveal information to hackers who scan for open ports against which to launch denial-of-service attacks. However, not sending Destination Unreachable messages in response to datagrams received for closed UDP port numbers in the 30,000 range will break many traceroute implementations (see 96x1H-IPI.5.1.400 and 96x1H-IPI.5.1.450). Rate-limiting to a specified number of messages per second complies with Section 4.3.2.8 of IETF RFC 1812 (Requirements for IP Version 4 Routers). Rate-limiting ICMP DU messages and ignoring many other types of ICMP messages (including any fragmented messages) is intended to enable the telephone to improve its resilience to denial of service attacks (see 96x1H-IPI.5.2.200 and [7.1-17a,b]).
|
Approved
|
ICMP Redirect messages will not be transmitted, but received Redirect messages will be supported per RFC 1122, Sections 3.2.2.2 (p.40-41) and 3.3.1.2 (pp.48-49) if and only if the value of the parameter ICMPRED is “1” (see 96x1H-IPI.2.1.1100).
|
Rationale:
|
The parameter ICMPRED is supported to control whether ICMP Redirect messages are processed, because they can be used by hackers to improperly redirect message traffic from the phone.
|
Approved
|
ICMP Echo messages will not be transmitted unless invoked by CNA (see 96x1H-IPI.5.1.920) or by H.323 procedures (e.g., by a manually-initiated remote ping diagnostic capability, see 96x1Tel.6.1.200 in [7.1-6]).
Received ICMP Echo Reply messages will be ignored unless they are in response to a transmitted ICMP Echo message.
An ICMP Echo Reply message will be transmitted in response to a received ICMP Echo message, per RFC 1122, Section 3.2.2.6, p.42-43, but no more than 2 replies per second will be transmitted to a maximum of 10 different IP addresses.
|
Note:
|
RFC 792 requires that “The data received in the echo message must be returned in the echo reply message”.
|
Note:
|
The ICMP Echo message is often referred to as a ‘ping’.
|
Rationale:
|
Transmission of pings is forbidden because they are often used in denial-of-service attacks, and customers are increasingly configuring their servers and even their routers to block pings. ARPs can usually be used in their place, but they are limited to the same subnet.
|
Approved
|
ICMP Time Exceeded messages will not be transmitted, and will be ignored unless received in response to a transmitted traceroute message (see 96x1H-IPI.5.1.450).
All other ICMP message types will not be transmitted, and will be ignored if received, including the following: Source Quench, Parameter Problem, Timestamp Request, Timestamp Reply, Information Request, Information Reply, Address Mask Request, Address Mask Reply, Router Solicitations, Router Advertisements.
|
Note:
|
Router discovery messages (Router Solicitations and Router Advertisements) are specified in IETF RFC 1256.
|
Rationale:
|
RFC 1122, Section 3.2.2.7, p.43, states that Information Request/Reply messages SHOULD NOT be implemented.
The ICMP Address Mask Request message (which is actually defined in RFC 950, Appendix I, p.10) will not be transmitted because the subnet mask is expected to be obtained from either DHCP (via the Subnet Mask option field) or via manual programming, as recommended by RFC 1123, Section 6.2.2.1, pp.88-89.
|
Approved
|
STD 5: RFC 1112 (Host Extensions for IP Multicasting) [7.3-4f]
Multicast support will conform to level 0 (no support for IP multicasting, which only requires that datagrams received with class D addresses be ignored) unless application-specific signaling and/or procedures specify host group address(es) and usage for the telephone.
Level 2 conformance (full support for IP multicasting) will be supported for UDP (see 96x1H-IPI.5.1.400) and for IGMPv2, which will be supported per RFC 2236 (Internet Group Management Protocol, Version 2) [7.3-4h].
|
Note:
|
IP multicast normally floods an entire subnet with multicast, unless other measures are taken. On switched networks, proprietary "IGMP snooping" can be used by switches to limit multicast traffic to ports that want to be in a group. Section 10 of IEEE 802.1D [7.2-4] defines a standard layer 2 protocol to do this called GMRP (GARP Multicast Registration Protocol, where GARP is the Generic Attribute Registration Protocol defined in Section 12 of that standard).
|
Note:
|
Multicast is expected to be used for some audio (RTP) push applications, as specified in [7.1-6].
|
Issue:
|
Does Linux support IGMPv3?
|
Approved
|
RFC 1191 (Path MTU Discovery) [7.3-6c]
Path MTU Discovery will be supported.
|
