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 <[email protected]>
Date: Saturday, 23 November 2019 at 9:32 PM
To: Manoj Nayak <[email protected]>
Cc: "[email protected]" <[email protected]>
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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
