Someone else might remember better, but I suspect is was to deal with length field issues. The "Payload Length" field of an IPv6 packet is not necessarily (e.g. in the case of extension headers) the same as the "Upper-Layer Packet Length" of the pseudo-header. So an implementation might have to put the pieces together anyway. And in the case of fragmentation, an implementation might not ever create a data structure in the form of an IPv6 header which would contain the entire payload length.
But the real advantage of the separate layout is that the "Upper-Layer Packet Length" is 32 bits, instead of the 16 of the regular IPv6 header. This allows the psuedo-header layout to be the same even when jumbograms (RFC 2675) are added to the mix. An implementation that always uses a 32-bit value internally to represent the "Upper-Layer Packet Length" wouldn't need to have separate code to handle the pseudo-header when a Jumbo Payload option is present. At least that's how I did it :-) --Brian > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Roy Smith > Sent: Friday, 28 October, 2005 19:46 > To: <[email protected]> <[email protected]> > Cc: Roy Smith > Subject: pseudo-header for checksum? > > Why does RFC 2460 defines a "pseudo-header" for checksum > calculations? > Why could a normal IPv6 IP header structure not been used, > setting the version, class, and label to zero? What's the > operational advantage to defining a different layout? > --------------------------------------------------------------------- The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
