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

Hi Dan,

Thanks for the comment. Responses inline.

Thanks,
-Felipe

From: Dan Wing <danwing@gmail.com>
Date: Tuesday, July 16, 2019 at 12:25 PM
To: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>, "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "gonzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com>, "tasveren@rbbn.com" <tasveren@rbbn.com>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS)

On Jul 15, 2019, at 7:09 AM, Felipe Garrido (fegarrid) <fegarrid@cisco.com<mailto:fegarrid@cisco.com>> wrote:

Hi Suresh,

Does the following language satisfy your Discuss? Similar references to IPv6 packets would be added to the other sections.

Thanks,
-Felipe

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?

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.

-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
tram@ietf.org<mailto:tram@ietf.org>
https://www.ietf.org/mailman/listinfo/tram