Subject: Comments on <draft-leddy-6man-truncate-05>

From: Bob Hinden <[email-masked]>
Date: Sat, 3 Nov 2018 16:45:41 +0700

Hi,

I read the current version of this draft on the flight to Bangkok and have some comments.

First of all, I think this is a significant improvement from earlier versions.   It’s getting better.   I am still unsure about the mechanism proposed as tool to improve PMTU discovery, but we will have that discussion in the 6man session.

Comments below, these are both substantive and editorial.

Bob

General comments:

I don’t see the need for two option assignments (Truncation Eligible and Truncated Packet), IMHO it would be a lot simpler with one option that has a data field that could indicate if the packet was truncated.  It would eliminate the need for rewriting the option type, and make finding the option simpler.   Many few error cases as well.

I think the draft would be better if it just talked about routers, instead of intermediate nodes and middle boxes.  We have only defined routers and host in IPv6.

In several places the draft says “According to [RFC8200]”.  I think this would be better with something like “As specified in [RFC8200].

Specific comments:

Section 1 Introduction:

   In order to maintain a running estimate of the PMTU, IPv6 nodes can
   execute Path MTU Discovery (PMTUD) [RFC8201] procedures.

The requirement in RFC8201 is “should” implement PMTUD.   This doc should say that.

4.1.  The Truncation Eligible Option, I didn’t understand why:

   IPv6 packets that include the Fragment header MUST NOT include the
   Truncation Eligible option.”

Please explain the need for this.

4.2.  The Truncated Packet Option:

   NOTE 2: According to [RFC8200], the third-highest-order bit (i.e.,
   the "chg" bit) of the Option Type specifies whether Option Data of
   that option can change on route to the packet's destination.  Because
   this option contains no Option Data, IANA can assign this Option Type
   without regard to the "chg" bit.

I don’t think this work for an IANA assignment, it has to be zero or one.   I think you want it specified as unchangeable.

5.  Reference Topology

The figure in this section looks to be two wide to fit on a page.  Needs to be fixed.

6.  Truncation Procedures

   Subsequently, the same upper-layer protocol on the Source Node causes
   the IP layer to emit another packet.  This packet is identical to the
   first, except that the total packet length is 2000 bytes.  Because
   the packet length is greater than the actual PMTU, this packet cannot
   be delivered without encountering an MTU issue.

I found this confusing.  The packet isn’t identical, as it (as stated) has a different length, and I would assume different data in it.   I don’t understand this text, please clarify.

   The IP layer on the source node forwards the packet to Router 1.
   Router 1 forwards the packet to Router 2, but the Router 2 cannot
   forward the packet because its length exceeds the MTU of the next
   link in the path (i.e., 1500 bytes).  Because an MTU issue has been
   encountered, Router 2 examines the Destination Options header,
   searching for either a Truncation Eligible option or a Truncated
   Packet option.  (Normally, the Router 2 would ignore the Destination
   Options header).

Is this going to happen in the fast path of a router?   Please explain.

7.  Additional Truncation Considerations

   A truncated packet MUST contain the basic IPv6 header, all extension
   headers and the first upper-layer header.  When an intermediate node
   cannot forward a packet due to MTU issues, and the total length of
   the basic IPv6 header, all extension headers, and first upper-layer
   header exceeds the MTU of the next link in the path, the intermediate
   node MUST discard the packet and send and ICMP PTB message to the
   source node.  It MUST NOT truncate the packet.

I assume this is for a case with, for example, early link of 9000 getting to a smaller link.   Seems pretty unlikely to happen in practice that the headers wouldn’t fit in the packet.  Even a 1500 byte packet.

9.  Checksum Considerations

   When an intermediate node truncates a packet, it SHOULD update the
   upper-layer checksum, if possible.  This is desirable because it
   increases the probability that the truncated packet will be delivered
   to the destination node.

Saying SHOULD and using a modifier “if possible” is odd.  It should either be a SHOULD or MAY.

   Middleboxes residing downstream of the intermediate node may attempt
   to validate the upper-layer checksum.  If validation fails, they may
   discard the packet without sending an ICMP message.

The doc needs to show some analysis that routers that look at destination headers and validate transport checksums will pass these packets with or without checksum recalculation.   The Checksum part of this proposal seems problematic to me.   It’s a lot of work for the router having to do the checksum recalculation and it’s not clear if these truncated packets will make it to the destination host.

10.  Invalid Packet Types

This would get a lot simpler if there is only one option.

   o  Send an ICMP Parameter Problem, Code 2, message to the packet's
      Source Address, pointing to the first invalid option.

This needs text to say to not send too many of these.  Otherwise it can be used as an attack.

13.  Extension Header Considerations

   The Hop-by-hop option can be examined by each node along the path to
   a packet's destination.  Destination options are examined by the
   destination node only.  However, [RFC2473] provides a precedent for
   intermediate nodes examining the Destination options on an exception
   basis.  (See the Tunnel Encapsulation Limit.)

That’s a very creative interpretation of RFC2473.   RFC2473 is discussing tunnel end points, effectively they are the source and destination of the tunneled packet.   That very different from what is propose in this document.  I don’t think RFC2473 can be used to justify this.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Nov 2018 08:57:36 -0700

> The doc needs to show some analysis that routers that look at destination headers and validate transport checksums will pass these packets with or without checksum recalculation.   The Checksum par…

Not only that, after truncation the transport packet is corrupted.
Fixing up the checksum to hide that corruption just so that the packet
more deliverable is not correct and possibly dangerous. It is
conceivable that some device somewhere might try to process the
transport packet without regard to the extension headers. Be
conservative in what you send...

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>