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

[Ron Bonica <[e-mail]>]

Hi  Tom,

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

                                  Ron

> -----Original Message-----
> From: Tom Jones <[e-mail]>
> Sent: Friday, June 15, 2018 5:18 AM
> To: Ron Bonica <[e-mail]>; [e-mail]
> Cc: [e-mail]
> 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]