96x1H-IPI.5.1.306: Internet Protocol version 6 (IPv6) and Internet Control Message Protocol for IPv6 (ICMPv6) |
Approved
|
When the value of IPV6STAT is “0”, IPv6 will not be supported.
When the value of IPV6STAT is “1”, IPv6 will be supported as specified by the IETF RFCs and other requirements below.
RFC 2460 (Internet Protocol, Version 6) [7.3-42a]
|
|
The Traffic Class field 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:
DSCPAUD (see 96x1H-IPI.2.1.1200) for transmitted audio (RTP, RTCP, SRTP and SRTCP) packets;
DSCPSIG (see 96x1H-IPI.2.1.1200) for transmitted H.323 signaling packets;
zero for all other transmitted packets (e.g., ICMPv6, DHCPv6, DNS, HTTP, SNMP, etc.).
Received DSCP information will be ignored.
The Flow Label field in the IPv6 header will be set to all zeroes in transmitted packets and will be ignored in received packets.
IPv6 packets with lengths of up to 1500 octets will be able to be transmitted and received
(i.e., the MTU will be 1500 octets).
|
Rationale:
|
Support of RFC 2460 is required by Requirement 2 in Section 5.3.5.4 of UCR 2008 [7.8-1d].
Support of RFC 2474 is required by Requirement 52 in Section 5.3.5.4.14 of UCR 2008.
Not using the Flow Label field is required by Requirements 7 and 7.1 in Section 5.3.5.4.2 of UCR 2008. Since the Flow Label value is obtained via RSVP, this implies that RSVP should not be supported for IPv6, which further implies that the DSCPBBE value not be supported for IPv6 either.
Section 5 of RFC 2460 requires an MTU of 1280 octets or greater, but it recommends an MTU of 1500 octets or greater. Ethernet can support an MTU of 1500 octets.
|
|
RFC 5095 (Deprecation of Type 0 Routing Headers in IPv6) [7.3-42t]
Type 0 Routing Headers (see Section 4.4) will not be included in packets transmitted by the telephone. Received packets that contain a Type 0 Routing Header will be processed as specified by Section 3 of RFC 5095.
|
Rationale:
|
Support of RFC 5095 is required by Requirement 2 in Section 5.3.5.4 of UCR 2008 [7.8-1d].
|
Note:
|
The upper-layer protocol carried in an IPv6 packet is specified by the value in the Next Header field of the Destination Options extension header, which uses the same values used in the IPv4 Protocol field:
|
|
|
decimal
|
hex
|
protocol
|
reference(s)
|
|
|
6
|
06
|
TCP
|
RFC 1700 p.8
|
|
|
17
|
11
|
UDP
|
RFC 1700 p.8, RFC 768 p.3
|
|
|
58
|
3A
|
ICMPv6
|
RFC 4443 p.3
|
Approved
|
RFC 1981 (Path MTU Discovery for IP version 6) [7.3-42a]
Path MTU Discovery will be supported. If a Packet Too Big message is received during Path MTU Discovery that requests a next-hop MTU that is less than the IPv6 link minimum of 1280 octets, the request for the smaller MTU will be ignored and a fragment header will be included in the packet.
|
Note:
|
Even though support Path MTU Discovery is not required for IP telephones (it is required for softphones) by Requirement 4 in Section 5.3.5.4.1 of UCR 2008 [7.8-1d], it is strongly recommended in Section 5 of RFC 2460, and it is supported for IPv4 (see 96x1H-IPI.5.1.304).
|
Rationale:
|
Ignoring a request for an MTU of less than the IPv6 minimum is to mitigate an attack where the path MTU is adequate, but the Packet Too Big messages are used to make the packet so small that it is inefficient. This is discussed in Section 6 of RFC 1981 and is required by Requirement 6 in Section 5.3.5.4.1 of UCR 2008 [7.8-1d].
|
Approved
|
RFC 2464 (Transmission of IPv6 Packets over Ethernet Networks) [7.3-42c]
RFC 2464 will be supported as necessary to support other required capabilities.
|
Rationale:
|
The frame format specified in Section 3 is required by Requirement 3 in Section 5.3.5.4 of UCR 2008 [7.8-1d], link-local address formation is specified in Section 5, the Source/Target Link-layer Address option format is specified in Section 6, and multicast address mapping is specified in section 7.
|
Issue:
|
Support of RFC 4007 (IPv6 Scoped Address Architecture) [7.3-42j] is required by Requirement 9 and 9.1 in Section 5.3.5.4.3 of UCR 2008 [7.8-1d], and WindRiver indicated that they support it in their Linux implementation, but it is not clear what support means on a device with only one interface. Until specific, testable requirements can be identified, support of RFC 4007 will not be required here.
|
Approved
|
RFC 4291 (IP Version 6 Addressing Architecture) [7.3-42l]
The IPv6 addressing architecture will be supported as specified in RFC 4291.
Neither an IPv4-Compatible nor an IPv4-Mapped IPv6 address will be created from the telephone’s IPv4 address, if it has one.
|
Approved
|
RFC 2710 (Multicast Listener Discovery (MLD) for IPv6) [7.3-42d]
Multicast Listener Discovery will be supported as specified in RFC 2710.
|
Note:
|
MLD is used by IPv6 routers to discover nodes that wish to receive multicast packets.
MLD uses ICMPv6 message types (see RFC 4443 below).
|
Rationale:
|
Support of MLD is required by Requirement 21 in Section 5.3.5.3.8 of UCR 2008 [7.8-1d]. A Note states that it is required in order to ensure that Neighbor Discovery multicast requirements are met.
|
Note:
|
Support of MLDv2 (RFC 3810) is not mentioned in UCR 2008.
|
Issue:
|
Support of the source address selection rules in RFC 3590 (which updated RFC 2710) is required by a dash item at the end of section 2.1 (Base Requirements) in the “DoD IPv6 Standard Profiles For IPv6 Capable Products Version 6, July 2011” in UCR 2008 Change 3 [7.8-1d].
|
Approved
|
RFC 4443 (Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6) [7.3-42o]
ICMPv6 will be supported as specified in RFC 4443 and below.
|
Rationale:
|
Support of ICMPv6 is required by Requirement 14 in Section 5.3.5.4.7 of UCR 2008 [7.8-1d].
|
Approved
|
A checksum calculated as specified in Section 2.3 of RFC 4443 will be included in every transmitted ICMPv6 message. The checksum will be validated in every received ICMPv6 message, and if it is not correct, the message will be discarded.
|
Rationale:
|
Validation of received ICMPv6 messages using the information contained in the payload prior to being processed is required by Requirement 14.4 in Section 5.3.5.4.7 of UCR 2008 [7.8-1d], however, while it is mentioned in item 6 in Section 5.2 of RFC 4443, no specific validation checks are specified. The U.S. Government has indicated that validating the checksum is sufficient.
|
Approved
|
If the value of the parameter PINGREPLYV6 (see 96x1H-IPI.2.1.1150) is “0”, ICMPv6 Echo Reply messages will not be sent.
If the value of the parameter PINGREPLYV6 is “1”, ICMPv6 Echo Reply messages will be sent only in response to received Echo Request messages with a Destination Address equal to one of the telephone’s unicast IPv6 addresses.
If the value of the parameter PINGREPLYV6 is “2”, ICMPv6 Echo Reply messages will be sent in response to received Echo Request messages with a Destination Address equal to one of the telephone’s unicast, multicast or anycast IPv6 addresses.
No more than 2 ICMPv6 Echo Reply messages will be sent per second to a maximum of 10 different IP addresses.
|
Rationale:
|
Supporting the enabling and disabling of sending Echo Reply messages in response to an Echo Request message sent to an IPv6 multicast or anycast address is required by Requirement 14.3 in Section 5.3.5.4.7 of UCR 2008 [7.8-1d].
|
Approved
|
RFC 4861 (Neighbor Discovery for IP version 6) [7.3-42q]
If a valid Neighbor Advertisement is received but there is no entry for the target in the Neighbor Cache, the Neighbor Advertisement will be silently discarded.
If a valid Neighbor Advertisement is received and there is an entry for the target in the Neighbor Cache but it is in the INCOMPLETE state, if the link layer has addresses but no Target Link-Layer Address option is included in the Neighbor Advertisement, the Neighbor Advertisement will be silently discarded.
|
Note:
|
When a Neighbor Solicitation message is transmitted, a Neighbor Cache entry for the target address is created in the INCOMPLETE state.
|
Rationale:
|
The two requirements above are SHOULD requirements in Section 7.2.5 of RFC 4861, but they are required by Requirements 11.3 and 11.4, respectively, in Section 5.3.5.4.5 of UCR 2008 [7.8-1d].
|
Approved
|
Received unsolicited Neighbor Advertisement messages will be processed if and only if the value of the parameter GRATNAV6 is “1” (see 96x1H-IPI.2.1.1200) and if an entry already exists for the target address in the Neighbor Cache. A received message will be considered unsolicited if the telephone did not send a corresponding Neighbor Solicitation message first, it will not be determined by the value of the Solicited flag in the received message.
|
Note:
|
An IPv6 unsolicited Neighbor Advertisement message is similar to a gratuitous ARP message in IPv4.
|
Approved
|
Address resolution will be initiated for unicast addresses that are not known to be on a different subnet.
|
Rationale:
|
While Section 7.2 of RFC 4861 states that "Address resolution is performed only on addresses that are determined to be on-link", if Router Discovery fails, it is not possible to determine whether a Global Unicast address is on-link. Therefore, in this case, address resolution will be initiated.
|
Note:
|
Global Unicast addresses are defined in Section 2.4 of RFC 4291 [7.3-42l].
|
Approved
|
If address resolution fails on a neighboring address, the entry will be deleted from the Neighbor Cache.
|
Rationale:
|
The requirement above is not mentioned in the last paragraph of Section 7.2.2 of RFC 4861 where address resolution failure is specified, but it is required by Requirement 11.5 in Section 5.3.5.4.5 of UCR 2008 [7.8-1d].
|
Approved
|
Router Solicitation messages will be transmitted as specified in Sections 6.3.7 and 10 of RFC 4861.
|
Rationale:
|
Sending Router Solicitation messages should result in faster startup than just waiting for periodic Router Advertisements.
|
Note:
|
The ‘M’ and ‘O’ bits in Router Advertisement messages are ignored.
|
Approved
|
Received Redirect messages will be processed if and only if the value of the parameter NDREDV6 is “1” (see 96x1H-IPI.2.1.1100), otherwise they will be ignored.
|
Rationale:
|
The ability to configure the telephone to ignore Redirect messages is required by Requirement 11.6 in Section 5.3.5.4.5.1 of UCR 2008 [7.8-1d].
|
Approved
|
Only Redirect messages that are received from the same router that is currently being used for that destination address will be considered valid.
|
Rationale:
|
This is already a MUST requirement in the sixth dash item in Section 8.1 of RFC 4861, but the US Government felt the need to require it again in Requirement 11.7 in Section 5.3.5.4.5.1 of UCR 2008 [7.8-1d].
|
Approved
|
If a valid Redirect message is received that also meets the requirements above, the Destination Cache will be updated with the information contained in the Redirect message.
An entry will be created for this information in the Destination Cache if one does not already exist.
|
Rationale:
|
The two requirements above are SHOULD requirements in Section 8.3 of RFC 4861, but they are required by Requirements 11.7.1 and 11.7.2 in Section 5.3.5.4.5.1 of UCR 2008 [7.8-1d].
|
Approved
|
Routers that are reachable will be preferred over routers whose reachability is suspect or unknown.
|
Rationale:
|
The requirement above is a SHOULD requirement in Section 6.3.6, item 1), of RFC 4861, but it is required by Requirement 11.8.1 in Section 5.3.5.4.5.2 of UCR 2008 [7.8-1d].
|
Approved
|
RFC 4862 (IPv6 Stateless Address Autoconfiguration) [7.3-42r]
Creation of a link-local address (Section 5.3 of RFC 4862) will be supported when the value of IPV6STAT is “1”. The value of IPADDV6LL will be set to the ASCII equivalent of the link-local address. The link-local address will be used as the Source Address only if the destination address is also a link-local address.
Duplicate Address Detection (Section 5.4 of RFC 4862) will be supported when the value of IPV6STAT is “1”.
Stateless creation of a global address (Section 5.5 of RFC 4862) will not be supported.
|
Question:
|
Is the above requirement on the usage of the link-local address sufficient for compliance with the source address selection requirements in RFC 3484 (Default Address Selection for IPv6)? That RFC is only required for softphones in UCR 2008 Change 3 Section 5.3.5.4.13, requirement 46.
|
Note:
|
Sections 4 and 5 of RFC 2464 specify how a link-local address is formed for Ethernet.
|
Note:
|
Section 16 of RFC 3315 requires that a DHCPv6 client use a link-local address as its IP source address.
|
Note:
|
The acronym “SLAAC” is used to refer to stateless creation of a global address, even though that acronym would seem to apply to the entire RFC.
|
Rationale:
|
Support of SLAAC is not required by UCR 2008 [7.8-1d] and if it is supported, it is required to support a configurable parameter to enable and disable it, the objective of this parameter being to prevent it from being used.
|
Rationale:
|
The initial IPv6 requirements are primarily intended for compliance with U.S. Government requirements as specified in UCR 2008 [7.8-1d].
|
