RFC 768 UDP ? [7:26283]
Just been reading the above RFC. To quote Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP. This business about a pseudo header is bothering me. If the IP header has already had a checksum that runs across the source and destination address then why does UDP do this again ? It also creates an obvious dependancy of UDP on IP also. Another question about padding making a multiple of two octets. I seem to remember Novell IPX requiring even numbered packets (2.X) maybe. Is this something to do with 16 bit processors working more efficiently with an even packet sizes i.e reading two bytes at a time was less expensive processor-wise than reading an odd byte ? Phil. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=26283t=26283 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: RFC 768 UDP ? [7:26283]
Oh, my. One's head reels! Phil Barker 11/14/2001 12:55:16 PM Just been reading the above RFC. To quote Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP. This business about a pseudo header is bothering me. If the IP header has already had a checksum that runs across the source and destination address then why does UDP do this again ? It also creates an obvious dependancy of UDP on IP also. Another question about padding making a multiple of two octets. I seem to remember Novell IPX requiring even numbered packets (2.X) maybe. Is this something to do with 16 bit processors working more efficiently with an even packet sizes i.e reading two bytes at a time was less expensive processor-wise than reading an odd byte ? Phil. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=26307t=26283 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: RFC 768 UDP ? [7:26283]
Comments inline Patricia Leeb-Hart wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Oh, my. One's head reels! Phil Barker 11/14/2001 12:55:16 PM Just been reading the above RFC. To quote Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP. This business about a pseudo header is bothering me. If the IP header has already had a checksum that runs across the source and destination address then why does UDP do this again ? It also creates an obvious dependancy of UDP on IP also. You're correct, it isn't necessary, and this has been acknowledged by the standards writers. Some TCP/IP implementations ignore the UDP checksum ( they will not reject a packet that does not have a UDP checksum, as long as the IP header checksum is OK). Another question about padding making a multiple of two octets. I seem to remember Novell IPX requiring even numbered packets (2.X) maybe. Is this something to do with 16 bit processors working more efficiently with an even packet sizes i.e reading two bytes at a time was less expensive processor-wise than reading an odd byte ? Phil. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=26318t=26283 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: RFC 768 UDP ? [7:26283]
At 09:37 PM 11/14/01, nrf wrote: Phil Barker 11/14/2001 12:55:16 PM Just been reading the above RFC. To quote Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP. This business about a pseudo header is bothering me. If the IP header has already had a checksum that runs across the source and destination address then why does UDP do this again ? It also creates an obvious dependancy of UDP on IP also. You're correct, it isn't necessary, and this has been acknowledged by the standards writers. Some TCP/IP implementations ignore the UDP checksum ( they will not reject a packet that does not have a UDP checksum, as long as the IP header checksum is OK). True, but TCP does the same thing (i.e. uses a checksum based on a pseudo header) and TCP's checksum is required. So the question still remains, why? The only clue is that the RFC says this gives protection against misrouted packets. It's hard to fathom what they were getting at, but what are some situations where the IP addresses inserted by the sender might be different from those that are in the packet that arrives at the recipient? I can think of one major case that has become very popular in modern networks.. (It supposedly handles the issue by recalculating the checksum, but it could be buggy). Another question about padding making a multiple of two octets. I seem to remember Novell IPX requiring even numbered packets (2.X) maybe. Is this something to do with 16 bit processors working more efficiently with an even packet sizes i.e reading two bytes at a time was less expensive processor-wise than reading an odd byte ? Sounds like a good guess. Phil. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=26330t=26283 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
