Mirja Kühlewind's No Objection on draft-ietf-6man-rfc1981bis-08: (with COMMENT)
Mirja Kühlewind <ietf@kuehlewind.net> Mon, 29 May 2017 12:38 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 262E3129553; Mon, 29 May 2017 05:38:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-rfc1981bis@ietf.org, Ole Troan <otroan@employees.org>, 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org
Subject: Mirja Kühlewind's No Objection on draft-ietf-6man-rfc1981bis-08: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149606149514.25348.10854422688090284741.idtracker@ietfa.amsl.com>
Date: Mon, 29 May 2017 05:38:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8DhXyKoss8-vrD7JpOdCcv3nT4E>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2017 12:38:15 -0000
Mirja Kühlewind has entered the following ballot position for draft-ietf-6man-rfc1981bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) 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-6man-rfc1981bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss. I believe there is an editing nit in section 5.4 now: "Alternatively, the retransmission could be done in immediate response to a notification that the Path MTU was decreased, but only for the specific connection specified by the Packet Too Big message, but only based on the message and connection. " Is it on purpose to have twice "but only" here? I leave my previous comments below for the record. I don't think all of them have been addressed but I aldo don't recognize any further discussion about those points: 1) I agree with Ekr on this sentence: "Nodes SHOULD appropriately validate the payload of ICMPv6 PTB messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to an IPv6 packet actually sent by the application) per [ICMPv6]." This sounds like it should be a MUST but I guess it depends on the upper layer protocol if such a validation is possible or not, e.g. if information are available that can be used for validation. Maybe you can be more explicit here and even say something like pmtu discovery should/must only be used if the upper layer protocol provides means for validation of the icmp payload (like a sequence number in TCP)…? Further also note that if the upper layer does the validation while the IP layer maintains EMTU_S, there must be an interface from the upper layer to the IP layer to tell if a packet is valid or not before the IP layer updates the MTU estimate. This seems actually more complicated than this one sentences indicates. 2) Also as Ekr says, I also have problems to fully understand this normative text in section 4: "After receiving a Packet Too Big message, a node MUST attempt to avoid eliciting more such messages in the near future. The node MUST reduce the size of the packets it is sending along the path. Using a PMTU estimate larger than the IPv6 minimum link MTU may continue to elicit Packet Too Big messages. Since each of these messages (and the dropped packets they respond to) consume network resources, the node MUST force the Path MTU Discovery process to end. Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast as possible." I especially don't understand the first part, given that a PTB message may still indicate a MTU that is larger than the minimum link MTU which then may cause another PTB message later on the path. This text reads like if you receive one PTB message you should better end discovery and fall back to the minimum link MTU to avoid any further PTB message and not waist any resources. I don't think that's the intention and as such I don't understand when it is recommended to end discovery here...? 3) Section 5.2 seems to be written with only single homed hosts in mind. It might be good to advise that the pmtu information should always be stored on a per interface basis...? 4) Also section 5.2: You only advise to store information per flow ID, however, if the flow label is not used, wouldn't it make really sense to just use the 5-tuple instead? Also note that EMCP is often done based on the 5-tuple or even 6-tuple (with the ToS field). 5) And more in section 5.2: "When a Packet Too Big message is received, the node determines which path the message applies to based on the contents of the Packet Too Big message. " MAYBE: "When a valid Packet Too Big message is received, the node determines which path the message applies to based on the contents of the Packet Too Big message." And further on: "If the tentative PMTU is less than the existing PMTU estimate, the tentative PMTU replaces the existing PMTU as the PMTU value for the path." This doesn't cover the case where a pmtu probe with a larger size was send and the PTB message returns a larger value then stored. Maybe state this explicitly. This applies similar to this sentence in section 6: OLD "A node, however, should never raise its estimate of the PMTU based on a Packet Too Big message, so should not be vulnerable to this attack.“ NEW "A node, however, MUST NOT raise its estimate of the PMTU based on a Packet Too Big message that is not a (validated) response to a PMTU probe that was previously send by this node, so should not be vulnerable to this attack." 6) Further section 5.2: Should this statement be maybe upper case MUST: "The packetization layers must be notified about decreases in the PMTU. " 7) Technical comment on section 5.3 in general: There is a difference between aging if a flow is active or not. While I maybe don't want to probe again for this connection because my application already decided to use a mode where it can live with the current pmtu and it's too much effect to switch, I really want to probe at the beginning of the next connection again to check if I can use a different mode now. While the IP layer does not have a notion of connection it can observe if packets are frequently send with the same 5-tuple and reset the cached pmtu after a certain idle time. 8) Section 5.4: should this maybe be normative, at least the last MUST NOT (be fragmented): "A packetization layer (e.g., TCP) must track the PMTU for the path(s) in use by a connection; it should not send segments that would result in packets larger than the PMTU, except to probe during PMTU discovery (this probe packet must not be fragmented to the PMTU). " Nit: The abbreviation PTB is only used once in section 4 (and never expanded).
- Mirja Kühlewind's No Objection on draft-ietf-6man… Mirja Kühlewind