David, Andrew & all: > If I remember correctly, the 484 byte limit of SNMP was the > amount available within the UDP message. So your numbers may > be slightly high still. Did you calculate in the overhead of > the transport layer headers? If you plan to allow different > transport mappings you should probably calculate the limit > for each mapping.
Indeed, I am proposing specific limits for UDP over IPv4 and IPv6. This is the scope of my transport draft. IPv4 hosts must support IP datagrams of at least 576 bytes per RFC791. IPv4 header is min 20 bytes and max of 60 bytes. UDP header is fixed at 8 bytes. This leaves 508-548 bytes for UDP data. So, I am not clear where the 484 byte SNMP's minimum supported size comes from. I can't find any rational in SNMP RFCs I looked over. Let me know if you can shed any light or give me pointers on whom to ping. Here is some more details on various UDP protocols I have mentioned: DNS (RFC1035) - Hard limit: 512 bytes + UDP/IP headers RIP (RFC1058) - Hard limit: 512 bytes + UDP/IP headers TFTP (RFC1350) - Hard limit: 512 bytes + 4 byte header + UDP/IP header SNMP (RFC3417) - Hosts must support 484 bytes messages, support for up to 1472 bytes recommended and larger values are encouraged. It is not clear to me how it can be larger. The maximum with UDP over IPv4 and over Ethernet is: 1500(ethernet data) - 20(ip header) - 8(udp header) = 1472. SNMP RFC does not clearly define what a "message" is. I assume it is the customary meaning of protocol message without UDP and IP headers. DHCPv4 (RFC2131) - Hosts must supports IP datagram size of 576 bytes (this includes UDP/IP headers) + negotiable to higher size through DHCP protocol exchange. Path MTU discovery is mentioned in related work, but it is not clear if its use is suggested. DHCPv6 (RFC3315) - refers readers to IPv6 RFC2460 recommendations for packet size. IPv6 RFC sets the minimum MTU hosts must support at 1280 bytes and suggests Path MTU discovery for determining optimal MTU. I am not sure if this will be different for IPv6, but at least for IPv4 people have not been using Path MTU discovery for UDP much because of non-uniform support of ICMP errors and the need for retransmissions. BOOTP (RFC951) - can’t find any restrictions in RFCs, although 512 byte limit was mentioned in some literature about this protocol. Based on the above, I think I'd go with what DNS and RIP do and declare that UDP transport message over IPv4 must be within 512 bytes without UDP/IP headers. Given the basic header size of syslog UDP transport of 5 bytes, this would leave 507 bytes for the maximum non-fragmented syslog message size. Alternatively, we can go with what I suggested earlier: 512 (or 516) bytes including UDP header, or 504 bytes for syslog transport message and 499 for maximum non-fragmented syslog message. The advantage of this approach is that even with the largest supported IPv6 header of 60 bytes, we will fit fine. Doing what DHCPv4 does is a more flexible alternative, but it would be more complicated for implementors to figure the exact size of IP header (which varies), so that they don't violate the 576 byte limit including the UDP/IP header. So, I'd rather not do it. Anybody know of any UDP protocols that specifically talk about size of datagrams over IPv6? Anton. > > dbh > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > > Sent: Tuesday, May 04, 2004 2:39 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: RE: syslog transport fragmentation > > > > I think this is reasonable, so I agree. Probably -protocol > > should recommend that the message is below 500 bytes - an > > efficiency hint... > > > > Rainer > > PS: I am out of office during most of this month with limited > > connectivity. > > > > ----- Ursprüngliche Nachricht ----- > > >Von: "Anton Okmianski"<[EMAIL PROTECTED]> > > >Gesendet: 03.05.04 21:37:23 > > >An: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> > > >Betreff: syslog transport fragmentation > > > > > >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. > > > > > > > > > > > > > > >
