3 ms·
Yes. If the path changes to one with a lower MTU, there might be a problem. Could be solved by truncating the packet instead of dropping it. Actually, I think t
by ambrop7 10y ago
Yes. If the path changes to one with a lower MTU, there might be a problem. Could be solved by truncating the packet instead of dropping it. Actually, I think this would be an even better approach. No extra field in the IP header, just truncation of packets that are too large, without changing the packet length field in the IP header. Upon seeing a truncated packet, the receiver could inform the sender of the detected path MTU (the length of the received packet).
EDIT: Well, if the MTU in the other direction also decreased, we might have an issue, as the stack might decline to interpret the transport layer payload. Don't know how to solve that right now, but probably there are ways. Maybe some mechanism to allow the protocol layer (TCP) to still successfully validate the TCP checksum knowing that the packet was truncated.
- lucb1e 10y agoYou're receiving lots of criticism from people that (correctly) see issues with your proposal. I just wanted to say that I like your thinking. Rather than going "doesn't work because scenario x" you work the problem and try to find something that does work. It sounds like a good idea, an MTU header in IP. The header can be extended if I remember correctly, so it might even be feasible to implement with backwards compatibility (avoiding another v6 to v7 transition). I don't know how v6 was designed exactly, but if it's open, did you search back to see if someone proposed this and why it was rejected (if ever proposed)?