Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))
RFC 7690
Internet Engineering Task Force (IETF) M. Byerly
Request for Comments: 7690 Fastly
Category: Informational M. Hite
ISSN: 2070-1721 Evernote
J. Jaeggli
Fastly
January 2016
Close Encounters of the ICMP Type 2 Kind
(Near Misses with ICMPv6 Packet Too Big (PTB))
Abstract
This document calls attention to the problem of delivering ICMPv6
type 2 "Packet Too Big" (PTB) messages to the intended destination
(typically the server) in ECMP load-balanced or anycast network
architectures. It discusses operational mitigations that can be
employed to address this class of failures.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7690.
Byerly, et al. Informational [Page 1]
RFC 7690 Misses with ICMPv6 PTB January 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Alternative Mitigations . . . . . . . . . . . . . . . . . 5
3.2. Implementation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Alternative Implementation . . . . . . . . . . . . . 6
4. Improvements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Operators of popular Internet services face complex challenges
associated with scaling their infrastructure. One scaling approach
is to utilize equal-cost multipath (ECMP) routing to perform
stateless distribution of incoming TCP or UDP sessions to multiple
servers or to middle boxes such as load balancers. Distribution of
traffic in this manner presents a problem when dealing with ICMP
signaling. Specifically, an ICMP error is not guaranteed to hash via
ECMP to the same destination as its corresponding TCP or UDP session.
A case where this is particularly problematic operationally is path
MTU discovery (PMTUD) [RFC1981].
Byerly, et al. Informational [Page 2]
RFC 7690 Misses with ICMPv6 PTB January 2016
2. Problem
A common application for stateless load balancing of TCP or UDP flows
is to perform an initial subdivision of flows in front of a stateful
load-balancer tier or multiple servers so that the workload becomes
divided into manageable fractions of the total number of flows. The
flow division is performed using ECMP forwarding and a stateless but
sticky algorithm for hashing across the available paths (see
[RFC2991] for background on ECMP routing). For the purposes of flow
distribution, this next-hop selection is a constrained form of
anycast topology, where all anycast destinations are equidistant from
the upstream router responsible for making the last next-hop
forwarding decision before the flow arrives on the destination
device. In this approach, the hash is performed across some set of
Show full document text