Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS)

["Felipe Garrido (fegarrid)" <[e-mail]>]

Hi Dan,

Thank you for the text. It’s been added to the latest draft version.

Thanks,
-Felipe

From: Dan Wing <[e-mail]>
Date: Wednesday, October 30, 2019 at 10:44 PM
To: "Felipe Garrido (fegarrid)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS)
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Wednesday, October 30, 2019 at 10:43 PM

Sorry, I just noticed this message.  Filtering problem on my gmail configuration.  See below.

4.1.  Simple Probing Mechanism

   The Simple Probing mechanism is implemented by sending a Probe
   Request with a PADDING [RFC5780] attribute over UDP with the DF bit
   set in the IP header for IPv4 packets and IPv6 packets without
   the Fragment Header included.  A router on the path to the server can
  reject this request with an ICMP message or drop it.

The router could also forward the 'request' (actually, it's just an IP packet as far as the router is concerned, it isn't a "request"), so three things can happen to that packet.

[FG]. In my opinion this is implicit. Do you think specific language needs to be added? If so, what do you have in mind?

I suppose it's implicit.


Separately, we all know some routers are configured to strip DF bits (that is, set to zro), and some routers are configured to fragment even if DF=1.  Is there implementation guidance we can give to assist detecting such behavior and learning the real underlying MTU, or should we ignore that routers do this and would interfere with the MTU learned by STUN-PMTUD?

[FG] We’ve discussed this, and while we agree. we feels this is outside the scope of this document. If you have some (hopefully short) text that may convey this crisply let us know.

Perhaps something like,

  "Note: routers can be configured to clear the DF bit or ignore the DF bit which can be difficult or impossible to detect if reassembly occurs prior to receiving the packet, rendering PMTUD inaccurate."

-d



-d





4.2.2.  Receiving an ICMP Packet

   If an ICMP packet "Fragmentation needed" or "Packet Too Big" is received then this is
   interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5.

Suresh Krishnan has entered the following ballot position for
draft-ietf-tram-stun-pmtud-10: Discuss



Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.1.x and 4.2.x

Please specify how this simple probing mechanism will work with IPv6. It
shouldn't be too difficult to do (cleanup references to the DF bit, use Type 2
"Packet Too Big" to identify failures etc.). Similar treatment will be required
for the complete probing mechanism as well.






_______________________________________________
tram mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tram