Hemant,
 
Forgive me if I've misunderstood, but it sounds like you're saying that we 
should require protocols or applications above IP to always send data in 
messages small enough to avoid IP fragemntation.
 
I agree it makes sense for a higher layer to use the PMTU information in IP's 
cache when it can. Expecting TCP to use the PMTU is perfectly reasonable, as 
it's already chopping up a byte stream into packets. For protocols which are 
already packetized, though, I think it's less advantageous to burden them (or 
the application using them) with the problem of fragmentation and reassembly, 
to avoid IP fragmentation.
 
For example, if a user does a "ping -s 1500" to a destination whose PMTU is 
1280, the only way to avoid IP fragmentation is for the ping application to 
split the data into multiple messages, or for IPCMPv6 to do so. Either way, you 
have to introduce some way to identify them as "ping fragments" and reassemble 
them in order. That will require changes to the ICMPv6 protocol, I think. 
Furthermore, you're no longer really doing a "ping 1500", but two pings of 1280 
and 220 bytes, respectively.
 
In the case of an application which sends records in single UDP frames, to 
avoid fragmentation is must split its messages into MTU-sized chuncks, and come 
up with a way at the destination to identify and reassemble the chunks in 
order. This seems a bit unreasonable, given that IPv6 has a perfectly good 
mechanism to do this already.
 
So I think the behaviour observed by Thomas during his testing is correct. I 
don't think ping or ICMPv6 should reduce the ICMP message size to avoid IP 
fragmentation.
 
Peter Hunt
Software Engineer
Nokia S&S.
 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to