Skip to main content

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

Yes

(Benoît Claise)

No Objection

Alvaro Retana
(Alia Atlas)
(Barry Leiba)
(Deborah Brungard)
(Martin Stiemerling)
(Stephen Farrell)

Recuse


Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

(Benoît Claise; former steering group member) Yes

Yes (for -04)

                            

(Brian Haberman; former steering group member) Yes

Yes (2015-10-14 for -04)
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?

(Alia Atlas; former steering group member) No Objection

No Objection (for -04)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -04)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (2015-10-14 for -04)
I agree with Spencer's comment about not using the word "Ideally" when talking about payload inspection.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2015-10-15 for -04)
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.

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-10-14 for -04)
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.

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -04)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (2015-10-13 for -04)
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 ...

(Stephen Farrell; former steering group member) No Objection

No Objection (for -04)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (2015-10-15 for -04)
Really nice document, Thanks for writing it!

(Joel Jaeggli; former steering group member) (was Abstain) Recuse

Recuse (2015-10-12 for -04)
it's mine, what can I say.