Why UDP checksum contains the UDP length twice?

Question

I was trying to understand UDP checksum mechanism. I am using this packet. I saw an example that in summation of all field, UDP length is included twice. Why we need to include UDP length twice in the checksum ?

This is the example I saw

IP header: Source IP address c0a8
… 0291
IP header: Destination IP address c0a8
… 0101
IP header: Protocol number(zero padded on left) 0011
16 bit UDP Length 0032
UDP header: source port 0618
UDP header: destination port 0035
UDP header: length 0032
UDP Data 
0001
0100
0001
0000
0000
0000
0131
0131
0331
3638
0331
3932
0769
6e2d
6164
6472
0461
7270
6100
000c
0001

• Sum all hex values 181e
• Carry 4
• Add in the carry 1822
• 1s complement = checksum! E7dd

Answer 1

Because that's what it says in RFC 768. No other answer is really possible.

Answer 2

The real reason is that the pseudo header was not written for UDP. It was defined for TCP, and used for UDP by inclusion.

TCP does not have a separate length field in the TCP header. The payload size of a TCP packet is the size of the IP packet minus the size of the headers. To protect against certain kinds of corruptions, the TCP designers decided to include the actual payload length in the pseudo header.

UDP decided not to define anything of its own. Instead, it simply incorporated the TCP pseudo header as is. Since UDP does have a length field in its header, it turns out that the same field is now used twice in order to calculate the UDP checksum.

It can be argued that the UDP length in the UDP header is, itself, redundant, for the same reason that TCP does not contain a similar field. I am given to understand that the reason for that is also historic, and has to do with UDP being defined before IPv4 was finalized. This is corrberated by the fact that the UDP RFC carries the date of August 1980, while the IP RFC carries the date of September 1981 (i.e. - more than a year later).