Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))
RFC 7690

[Ballot comment]
Thanks for a useful document.

I'd probably have expanded ECMP in the abstract, and included a reference to the relevant RFC in Section 1.

[Ballot comment]
Given the current state of affairs, I think this is a quite useful document.  I just have a question for my own knowledge.

Is there any data that indicates how many of these PTB messages are due to tunneling?

[Ballot comment]
The following sentence int he Security Considerations section is hard to read, can you adjust it?

  The proxy replication results in devices not associated with the flow
  that generated the PTB being recipients of an ICMPv6 message which
  contains a fragment of a packet.

[Ballot comment]
In section 3, "Mitigation", I'm reading this.

  Mitigation of the potential for PTB messages to be mis-delivered
  involves ensuring that an ICMPv6 error message is distributed to the
  same anycast server responsible for the flow for which the error is
  generated.  Ideally, mitigation could be done by the mechanism hosts
              ^^^^^^^
  use to identify the flow, by looking into the payload of the ICMPv6
  message (to determine which TCP flow it was associated with) before
  making a forwarding decision.  Because the encapsulated IP header
  occurs at a fixed offset in the ICMP message it is not outside the
  realm of possibility that routers with sufficient header processing
  capability could parse that far into the payload.  Employing a
  mediation device that handles the parsing and distribution of PTB
  messages after policy routing or on each load-balancer/server is a
  possibility.
 
Most of the document is about using other mitigations that make this mitigation unnecessary, but it's still a bit odd to see Deep Packet Inspection characterised as "ideally", now that RFC 7258 is now BCP 188, and we've chartered TCPINC to make that DPI fail as often as possible.

Could that one word go away?

I see in email that Fred asked if any reviews were needed before submitting this draft for publication, and David Black suggested reviews from INT and TSV, and that made it as far as the shepherd writeup, but I'm not seeing a request for review popping up in TSV (at least not with "PMTUD" and "V6OPS" in an e-mail). I don't have concerns about this particular draft, but I wish it hadn't slipped through that particular crack.

Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, and yes, there was an IETF Last Call, so I'm not hitting "Defer" to chase that. Just something to watch for, in the future.

And yes, Martin and I have a call set up to talk with the TSVdir triage team next week ...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-pmtud-ecmp-problem-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Close encounters of the ICMP type 2 kind (near misses with ICMPv6
PTB)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in
the title page header?

This is an informational draft, identifying a problem and proposing
operational mitigations.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up.
Recent examples can be found in the "Action" announcements for
approved documents. The approval announcement contains the following
sections:

Technical Summary

  This document calls attention to the problem of delivering ICMPv6
  type 2 "Packet Too Big" (PTB) messages to the intended destination
  in ECMP load balanced or anycast network architectures.  It
  discusses operational mitigations that can be employed to address
  this class of failures.

Working Group Summary

  The draft has been accepted with enthusiasm.

Document Quality

  This is not a protocol. The operational mitigations proposed have
  been implemented in various places, but are not uniformly
  implemented.

Personnel

  The Document Shepherd is Fred Baker. Joel Jaeggli, one of the
  authors, is the obvious Area Director. He may prefer to defer to
  his co-AD.

(3) Briefly describe the review of this document that was performed
by the Document Shepherd.

I have read the draft in various incarnations, and discussed its
recommendations with Matt Mathis, the originator of RFC 4821, and
with some of his colleagues.

(4) Does the document Shepherd have any concerns about the depth
or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or
from broader perspective, e.g., security, operational complexity,
AAA, DNS, DHCP, XML, or internationalization? If so, describe the
review that took place.

Not really, as it is specifically operational. However, the topic
has come up in intarea and tsvwg. It would be worth asking for their
comments on it.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of?

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of
BCP 78 and BCP 79 have already been filed.

They have been asked, and are unaware of IPR issues.

(8) Has an IPR disclosure been filed that references this document?

No IPR disclosure has been filed as of 7/7/2015.

(9) How solid is the WG consensus behind this document?

There is widespread agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to
be thorough.

The idnits tool identifies two issues. One is that the code snippet
in section 3.2 doesn't have brackets saying "" or
"". The code is, however, clearly identified and delimited
in the text. I don't view this as an issue; if the IESG does, I'm
sure the authors can add it. The other is that the code contains
the string "pkt[Ether].dst", and the tool picks up [Ether] as an
apparent dangling reference. It's not.

(13) Have all references within this document been identified as
either normative or informative?

Yes. There is one reference, and it is informative.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section...

It is correct.