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

[Manoj Nayak <[e-mail]>]

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.


       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



  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                                                        |
       |                                                                                                              |
       |                           //                                                                                |
       |                                                                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  If the packet mentioned in RFC 1191 does not have any issue with tunnel
  then 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.



>> 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.


Regards
Manoj Nayak


From: Joe Touch <[e-mail]>
Date: Saturday, 23 November 2019 at 9:32 PM
To: Manoj Nayak <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

You haven’t answered any of the questions I asked, including the one about tunnels.

The point about tunnels is that the numbers you’re assuming don’t account for the space needed for tunneling.

The portion of RFC2003 below acts like a router; it isn’t relevant to your mechanism. Sec 5.2 of draft-ietf-intarea-tunnels also points out several errors in that RFC, including those in how that RFC refers to and calculates MTUs.

Joe