IPv6 TCP Configuration
IPv6 supports TCP configuration. You use the same commands to configure TCP on IPv6 as you do to configure TCP on IPv4.
Setting MSS for TCP Connections
MSS is used by TCP to define the maximum amount of data that a TCP interface can accept in any single packet (or segment size). The MSS value is typically negotiated during connection establishment and is not renegotiated.
By default, the router uses an MSS value of 1280 bytes and the advertised MSS is derived from the MTU of the transmitting interface. However, you can use the tcp mss command to set the MSS for TCP use.
tcp mss
- Use to specify the MSS value for TCP to use.
NOTE: The MSS value is equal to the MTU value minus the IPv6 and TCP headers, so the MSS value is generally 60 bytes less than the MTU.
- Use the vrfName variable to specify a VRF to which you want to assign the TCP MSS value.
- Example
host1(config)#tcp mss 1000Use the no version to remove the MSS value so that the router uses the advertised MSS derived from the MTU of the output interface. Configuring Path MTU Discovery
IPv6 hosts transmit large amounts of data to other hosts using a series of IPv6 datagrams. To best use resources, increase performance, and avoid difficult reassembly, hosts try to send datagrams that are as large as possible without requiring fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the path MTU (PMTU), and it is equal to the smallest MTU for each hop in the path.
Path MTU discovery is the process of discovering the PMTU value and using that value when transmitting IP datagrams.
Enabling PMTU Discovery
Use the tcp path-mtu-discovery command to enable PMTU discovery on the active virtual router.
tcp path-mtu-discovery
- Use to enable and configure path MTU discovery on the virtual router.
- Issue the command without any keywords to enable path MTU discovery.
- Issue the age-timer keyword to set the time (minutes) that TCP waits before attempting to increase the path MTU after receiving an ICMP Too Big message or after previously increasing the PMTU successfully (minutes2). The range of these two timers is 130 minutes. The timer defaults to 10 minutes.
- Issue the age-timer indefinite keyword to disable PMTU aging functions.
- Example 1Enables path MTU discovery
host1:VR1(config)#tcp path-mtu-discoveryExample 2Sets path MTU discovery age timers differently host1:VR1(config)#tcp path-mtu-discovery age-timer 20 15Example 3Sets path MTU discovery age timers to the same value
(5 minutes)host1:VR1(config)#tcp path-mtu-discovery age-timer 5Example 4Disables path MTU discovery age timers host1:VR1(config)#tcp path-mtu-discovery age-timer indefiniteUse the no version with a keyword to return the values to their defaults. Issue the no version without any keywords to disable path MTU discovery on the virtual router. Limiting PMTU
You can limit calculated PMTU values within a range by using the tcp path-mtu-discovery max-mtu and tcp path-mtu-discovery min-mtu commands. When specifying PMTU limits, keep the following in mind:
- If a PMTU discovery value is lower than the configured minimum MTU setting, PMTU discovery is disabled for that connection.
- If a PMTU discovery value is larger than the configured maximum MTU setting, the configured maximum MTU setting is used.
- The maximum MTU setting must be greater than the minimum MTU setting.
tcp path-mtu-discovery max-mtu
host1:VR1(config)#tcp path-mtu-discovery max-mtu 512Use the no version to remove any limitation so that the virtual router uses the path MTU discovery value. tcp path-mtu-discovery min-mtu
- Use to specify the minimum MTU value used for the path MTU. If the discovered PMTU value is less than the minimum setting, path MTU discovery is disabled for this connection.
- Example
host1:VR1(config)#tcp path-mtu-discovery min-mtu 255Use the no version to remove any limitation so that the virtual router uses the discovered path MTU value. Specifying Black Hole Thresholds
Some domains might be configured not to generate certain ICMP messages (like an ICMP destination unreachable message) or to filter all ICMP messages. Under these conditions, the source of oversized ICMP packets never learns that it is sending oversized packets. The device continues sending oversized packets that never get through. This behavior is often referred to as a black hole.
A black hole threshold is a limit to the number of times a virtual router can retransmit identical sequences of datagrams before the retransmissions are identified as a problem.
tcp path-mtu-discovery black-hole-detect-threshold
- Use to specify the number of permitted retransmissions before the retransmissions are determined to be a problem.
- Example
host1:VR1(config)#tcp path-mtu-discovery black-hole-detect-threshold 200Use the no version to disable black hole threshold detection. Protecting Against TCP RST or SYN DoS Attacks
You can use the tcp ack-rst-and-syn command to help protect the router from denial of service (DoS) attacks.
Normally, when it receives an RST or SYN message for an existing connection, TCP attempts to shut down the TCP connection. This action is expected under normal conditions, but someone maliciously generating otherwise valid RST or SYN messages can cause problems for network applications and the network as a whole.
When you enable the tcp ack-rst-and-syn command, the router challenges any RST or SYN messages that it receives by sending an ACK message back to the expected source of the message. The source reacts in one of the following ways:
- If the source did send the RST or SYN message, it recognizes the ACK message to be spurious and resends another RST or SYN message. The second RST or SYN message causes the router to shut down the connection.
- If the source did not send the RST or SYN message, the source accepts the ACK message as part of an existing connection. As a result, the source does not send another RST or SYN message and the router does not shut down the connection.
NOTE: Enabling this command slightly modifies the way TCP processes RST or SYN messages to ensure that they are genuine.
tcp ack-rst-and-syn
host1(config)#tcp ack-rst-and-synUse the no version to disable this protection (the default mode). Preventing TCP PAWS Timestamp DoS Attacks
The TCP Protect Against Wrapped Sequence (PAWS) number option works by including the TCP timestamp option in all TCP headers to help validate the packet sequence number.
Normally, in PAWS packets that have the timestamps option enabled, hosts use an internal timer to compare the value of the timestamp associated with incoming segments against the last valid timestamp the host recorded. If the segment timestamp is larger than the value of the last valid timestamp, and the sequence number is less than the last acknowledgement sent, the host updates its internal timer with the new timestamp and passes the segment on for further processing.
If the host detects a segment timestamp that is smaller than the value of the last valid timestamp or the sequence number is greater than the last acknowledgement sent, the host rejects the segment.
A remote attacker can potentially determine the source and destination ports and IP addresses of both hosts that are engaged in an active connection. With this information, the attacker might be able to inject a specially crafted segment into the connection that contains a fabricated timestamp value. When the host receives this fabricated timestamp, it changes its internal timer value to match. If this timestamp value is larger than subsequent timestamp values from valid incoming segments, the host determines the incoming segments as being too old and discards them. The flow of data between hosts eventually stops, resulting in a denial of service condition.
Use the tcp paws-disable command to disable PAWS processing.
tcp paws-disable
- Use to disable the Protect Against Wrapped Sequence (PAWS) number option in TCP segments.
- You can specify a VRF context for which you want PAWS disabled.
- Example
host1(config)#tcp paws-disableUse the no version to restore PAWS processing (the default mode). Protecting Against TCP Out of Order DoS Attacks
You can use the group of tcp resequence-buffers commands to help protect the router from TCP out-of-order packet DoS attacks.
TCP guarantees that applications receive data in order. This means that TCP buffers any out-of-order packets it receives until ordered delivery can occur.
To prevent connections from consuming too many resources, TCP limits the amount of data it accepts to the number of data bytes that the receiver is willing to receive and buffer. TCP does not take into account the buffering scheme that the receiver uses. If the receiver uses a fixed-size receive buffer (that is, buffering all packets) regardless of length, a packet that contains only one data byte might consume many data bytes of buffer space, but only one byte of TCP space.
Under these conditions, an attacker can send a large number of 1-byte packets to an E-series router in which each packet is buffered, consuming an entire packet buffer and eventually consuming a large amount of resources.
To defend against this sort of attack, you can set defaults and limits on the number of outstanding buffers on reordering queues. You can configure these defaults and limits on a per-router, per-virtual router, or per-connection within the virtual router basis.
Limiting Buffers per Router
The tcp resequence-buffers global-maximum command enables you to limit the number of outstanding buffers on the entire router.
tcp resequence-buffers global-maximum
- Use to specify a router-wide maximum number of buffers that resequencing queues can contain.
- Specify a value of zero (0) to turn off the limit.
- Example
host1(config)#tcp resequence-buffers global-maximumUse the no version to revert the global maximum buffer value to its default, 1000 buffers. Limiting Buffers per Virtual Router
The tcp resequence-buffers vr-maximum command and tcp resequence-buffers default-vr-maximum command allow you to limit the number of outstanding buffers on existing or newly established virtual routers.
tcp resequence-buffers default-vr-maximum
- Use to specify the default buffer limit assigned to all virtual routers when the virtual router is established.
- Specify a value of zero (0) to turn off the limit assignment.
- Example
host1(config)#tcp resequence-buffers default-vr-maximum 200Use the no version to revert the virtual router maximum value to its default, 100 buffers. tcp resequence-buffers vr-maximum
- Use to define the maximum number of buffers that the current or specified virtual router can use.
- Specify a value of zero (0) to turn off the limit assignment.
- Example
host1(config)#tcp resequence-buffers vr-maximumUse the no version to revert the virtual router maximum value to its default, 100 buffers. Limiting Buffers per Connection
The tcp resequence-buffers connection-maximum command and tcp resequence-buffers default-connection-maximum command allow you to limit the number of outstanding buffers on existing or newly established connections.
tcp resequence-buffers connection-maximum
- Use to define the maximum number of buffers that connections on the current or specified virtual router can use.
- Specify a value of zero (0) to turn off the connection maximum.
- Example
host1(config)#tcp resequence-buffers connection-maximum 50Use the no version to revert the connection maximum value to its default,
10 buffers.tcp resequence-buffers default-connection-maximum
- Use to specify the default buffer limit assigned to all TCP connections on a virtual router unless a specific limit is set for the VR in which the connection is established.
- Specify a value of zero (0) buffers to turn off the default limit.
- Example
host1(config)#tcp resequence-buffers default-connection-maximum 100Use the no version to revert the connection maximum value to its default, 10 buffers.