Subject: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt

From: Ron Bonica <[email-masked]>
Date: Tue, 12 Jun 2018 14:22:41 +0000

Please review and comment

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, June 11, 2018 12:32 PM
To: Ron Bonica <[email-masked]>; John Leddy <[email-masked]>
Subject: New Version Notification for draft-leddy-6man-truncate-03.txt

A new version of I-D, draft-leddy-6man-truncate-03.txt has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-leddy-6man-truncate
Revision:	03
Title:		Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages
Document date:	2018-06-11
Group:		Individual Submission
Pages:		14
URL:       https://tools.ietf.org/html/draft-leddy-6man-truncate-03     

Status:  https://datatracker.ietf.org/doc/draft-leddy-6man-truncate/
Htmlized:  https://tools.ietf.org/html/draft-leddy-6man-truncate-03
Htmlized:  https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate    

Diff:       https://www.ietf.org/rfcdiff?url2=draft-leddy-6man-truncate-03    

Abstract:
   This document defines procedures that enhance Path MTU Discovery
   (PMTUD), so that it no longer relies on the network's ability to
   deliver an ICMP Packet Too Big (PTB) message from a downstream router
   to an IPv6 source node.  According to these procedures, selected
   packets carry a new IPv6 Destination option.  When a downstream
   router cannot forward one of these packets because of MTU issues, it
   truncates the packet, marks it to indicate that it has been
   truncated, and forwards it towards the destination node.

   When the destination node receives a packet that has been truncated,
   it sends an ICMP PTB message to the source node.  The source node
   uses MTU information contained by the ICMP PTB message to update its
   PMTU estimate.

   The destination node also examines the new Destination option to
   determine whether it should discard the truncated packet or deliver
   it to an upper-layer protocol.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ron Bonica <[email-masked]>
Date: Tue, 19 Jun 2018 16:36:12 +0000

Hi  Tom,

Thanks for the thoughtful review. Responses inline.....

                                  Ron

> From: Tom Jones <[email-masked]>
> Sent: Friday, June 15, 2018 5:18 AM
> To: Ron Bonica <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-
> truncate-03.txt
> 
> Hello,
> 
> I have read this draft and think it proposes an interesting probing mechanism
> for PMTUD. I have some questions and comments:
> 
> 1.
> 
>     IPv6 allows fragmentation at the source node only.
> 
> This needs a ref to Section 3 of RFC2460 and I suspect a reference to draft-
> bonica-intarea-frag-fragile-01. It would help to expand a little and explain
> some of the issues with fragmentation.

The previous paragraph already has a reference to RFC 8200. RFC 8200 obsoletes RFC 2400. 

A reference to draft-bonica-intarea-frag-fragile may be appropriate. However, I am reluctant to add that reference before  draft-bonica is adopted by the INTAREA WG. Let's add that reference if an when draft-bonica is adopted.

> 
> 2.
> 
> PTB delivery might also fail if the IPv6 PTB does not carry enough information
> to validate the PTB packet. This is discussed in Section 1.1. (Classical Path
> MTU Discovery) of Datagram PLPMTUD.
> 
> Appendix C of [RFC4960] also has some considerations for PTB verification.

Good point. I will add text to the final bullet list in Section 3 of draft-ledd-6man-truncate.

> 
> 3.
> 
>           0                   1                   2
>           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |  Option Type  |  Opt Data Len |T|D|R| Reserved|
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                                  Figure 2
> 
> TCP does not carry a length field in its header, instead it uses the total length
> field in IPv4 and the payload length in IPv6, modifying this value may make it
> difficult or impossible for the receiving TCP to find the intended end of
> segment.  This option needs to carry enough information to reproduce the
> original payload length field.
> 
> I suggest adding the original payload length to the option, like so:
> 
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 0
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+
> |  Option Type  |  Opt Data Len |T|D|R| Reserved|   Original Payload Length
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+
> 
>                              Figure 2
> 
> This will require increasing the option length from 1 to 3.
> 

Does TCP need to know the Original Payload Length? What would it do with this information if it had it?

I suspect that there is a good use for this data, but I am curious to know what it is.

> 4.
> 
>    o  T - Indicates that the packet has been truncated.  If the packet
>       has not been truncated, it SHOULD be delivered to an upper-layer
>       protocol.
> 
>    o  D - Indicates that the packet SHOULD be delivered to an upper-
>       layer protocol even if it has been truncated.  If the D-bit is set
>       to zero, the packet MUST NOT be delivered to an upper-layer
>       protocol if it has been truncated.
> 
>    o  R - Request to deliver truncated packets.
> 
> It is not clear to me what the R bit is for. Is it for the sending node to indicate
> that packets sent to it may have the D bit set?
> 
> This text from section 8 makes me think it is a negotiation flag.
> 
>    Alternatively, other upper-layer protocols developed
>    in the future might set the D-bit only after receiving a Truncation
>    option with the R-bit set.
> 
> 
Yes, it is used for negotiation. But is this flag useful to upper-layer protocols? If it is not, I would be happy to remove it.

> 5.
> 
>    NOTE 1: The highest-order two bits of the Option Type (i.e., the
>    "act" bits) are 10.  These bits specify the action taken by a
>    destination node that does not recognize Truncation option.  The
>    required action is to discard the packet and, regardless of whether
>    or not the packet's Destination Address was a multicast address, send
>    an ICMP Parameter Problem, Code 2, message to the packet's Source
>    Address, pointing to the unrecognized Option Type.
> 
> Is this not the expected behaviour now?

Yes, this paragraph quotes RFC 8200. The act bits specify the action taken by a destination node that does not recognize Truncation option. Bits 10 indicated that the destination node must discard the packet and send and ICMP message.

I am quoting RFC 8200 a) for those who haven't memorized the bit-values and b) to satisfy my obsessive-compulsive tendencies ;-)

> 
> Would a future rev have the destination node modify these bits to indicate it
> supports the option and there was another error?
> 

I'm not sure that I understand the question. Could you elaborate?

> 6.
> 
>    NOTE 2: The third highest-order bit of the Option Type (i.e., the
>    "chg" bit) is 1.  This indicates that Option Data can be modified
>    along the path between the packet's source and its destination.
> 
> In which circumstances would this be used? It seems strange to me that the
> sending node would set bits and then allow them to not be end to end.

The truncating node sets the T-bit. It wouldn't be allowed to do that unless the chg bit was set.
> 
> 7.
> 
> In the second example in section 2 are the T D R bits set as they were in the
> first example?
> 
I think that you mean Section 7.

In this example, the T D and R bits are the same as in the previous section. I will make that clear in the next version of the document.

> 8.
> 
>    A truncated packet MUST contain the basic IPv6 header, all extension
>    headers and the first upper-layer header.  When a router cannot
>    forward a packet through the next-hop link 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-hop link, the
>    router MUST discard the packet and send and ICMP PTB message to the
>    source.
> 
> Ref RFC7112 here.

RFC 7112 has been obsoleted by RFC 8200. RFC 8200 includes the above-mentioned rule.

> 
> What does a router do when it receives a truncated packet without the full
> header chain?
> 

It MUST discard the packet. I will add that in the next revision.

                                                                   Ron

> - [tj]
> --
> - [tj]