Hi! I am pondering what recommendations/requirements we should set for maximum datagram sizes in syslog UDP transport protocol. Messages of certain size would have to be fragmented. I have done some research and want to propose that we set the following strict limits on datagram sizes:
- IPv4 - fragment to max datagram size of 512 bytes - IPv6 - fragment to max datagram size of 1196 bytes This means that the maximum size of non-fragmented syslog message would be about: - IPv4 - 499 bytes - IPv6 - 1183 bytes Now, the justification. At first, I was going to propose that the limit for non-fragmented message would be just the max IP datagram size of 65,536 bytes and then suggest the above only as a recommendation. However, it is quite clear from reading the literature that many UDP/IP implementations out there do not support large packet sizes even though they are allowed by specifications. This means that we will be risking low interoperability if we leave it up to implementors or administrators to figure out when fragmentation should kick in. The disadvantage of specifying low size limits is that fragmentation (and its huge overhead) kicks in faster. Many successful UDP protocols limit IPv4 datagrams to somewhere in the range of 512 bytes: TFTP, DNS, BOOTP, SNMP, RIP... So, if we go with that size, we will be safe. I presume they do it for the same reasons of interoperability and avoiding IP fragmentation. The 512 byte limit for IPv4 datagrams let you stay under the 576 minimum MTU for IPv4 with all the IP headers. I derived a similar number for IPv6 (1196), but taking its minimum MTU of 1280 and subtracting the same amount of padding for IP header + 20 bytes for the extra size of IPv6 header. This is the methodology suggested by IPv6 spec (rfc2460 sec 8.3). I think that most syslog messages should be smaller than 499 bytes and, therefore, it would good compromise between performance and interoperability consideration to specify the above datagrams size limits. Let me know if you agree or disagree. Thanks, Anton.
