> On Nov 29, 2019, at 2:03 AM, Manoj Nayak <[email protected]> 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_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
