Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

[Joe Touch <[e-mail]>]

> On Nov 29, 2019, at 2:03 AM, Manoj Nayak <[e-mail]> wrote:
> 
> Hello Joe,
>  
> Sorry for the delayed response.
>  
> >> - why does this doc assume the max ICMP is 576?
> >>     we?re still talking IPv4 here; it?s still 68 (that?s why only 64 bits of the orig payload are guaranteed)
> >>     (yes, your note in the end of sec 1 is relevant, but given v4-in-v4 tunneling, it?s possible that
> >> paths might be smaller than the 576 assumption)
>  
> >> We use an unused field in first 8 bytes of ICMP error/reply message.
>  
> >> Please explain. Most ICMP messages have 4 bytes of unused field, but not all (one has only 3).
>  
>  
>       As per RFC 1191,  Destination Unreachable Message has 8 bytes unused field.

DU has only 4 bytes unused, per RFC792.

Destination Unreachable Message

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC1191 uses half that space:

   ...To support the Path MTU Discovery
   technique specified in this memo, the router MUST include the MTU of
   that next-hop network in the low-order 16 bits of the ICMP header
   field that is labelled "unused" in the ICMP specification [7 <https://tools.ietf.org/html/rfc1191#ref-7>].  The
   high-order 16 bits remain unused, and MUST be set to zero.

>      
>        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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   Type = 3    |   Code = 4    |           Checksum                                 |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           unused = 0          |         Next-Hop MTU                                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |      Internet Header + 64 bits of Original Datagram Data            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The diagram above  is from 1191 - there are 2 bytes unused.

>   Most of ICMP reply/error message need type, code and checksum in first four bytes.
>   So our new ICMP message for this draft has the above three fields in first four bytes.
>   We have used 1 byte for length and two bytes for Largest fragment. Our ICMP
>   Package looks as follows:
>  
>         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
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     Type      |     Code      |          Checksum             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     Unused    |    Length     |       Largest Fragment        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                      Original Datagram                                                        |
>        |                                                                                                              |
>        |                           //                                                                                |
>        |                                                                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

You’re not using 8 unused bytes. You are following RFC792 for the first three fields (first 4 bytes) and defining a new template for the next 4. 

>   If the packet mentioned in RFC 1191 does not have any issue with tunnel
>   then

It does because it doesn’t include the entire original datagram….

> how tunnel can create problem for our packet.
>     
> >> Sending the largest response possible given an untunneled MTU size is an invitation
> >> to black-hole the response itself if (when) an IPv4-in-IPv4 tunnel is encountered.
> >> In most situations, ICMP responses are received from small initial messages that don’t
> >> stress that limit. The use in this doc is the opposite - it relies on ongoing use of ICMP
> >> for max-sized packets and returns max-sized payloads. This isn’t helpful. It would be more
> >> useful to try to limit the size to the minimum expected to be useful and account for
> >> these other encapsulations.
>  
> We have mentioned that Original Datagram will be there in the third row of our ICMP packet.
> However Internet Header + 64 bits of Original Datagram Data is good enough for us
> to link our ICMP packet to the original packet that has generated this ICMP packet
> at the sender.

IH is a min of 20 bytes (for IPv4). The next 8 bytes of the tunnel header might not be enough to determine what to do with the ICMP message.

>  >> The issue is further down in that section:
> >>      One other fragmentation technique discussed was splitting the IP
> >>      datagram into approximately equal sized IP fragments, with the
> >>      size less than or equal to the next hop network's MTU. ...
> >> In that case, none of the fragments gives you the path MTU.
>  
> The first fragment is the largest fragment when all fragments are equal sized.

It is the largest - but not the path MTU.

You claim that this technique will find the path MTU, but it will not in that case - and you can’t know when case occurs.

Joe