jcurran@SH.CS.NET (John Curran) (11/07/90)
I'm sure I've overlooked something, and could use a push.. Why does UDP (when used with checksumming enabled) create a pseudo-header that contains both the port numbers and the source and destination IP addresses? Isn't it already protected from address changes by the datagram checksum? /John
gwilliam@SH.CS.NET (George Williams) (11/08/90)
I'm sure I've overlooked something, and could use a push.. Why does UDP (when used with checksumming enabled) create a pseudo-he ader that contains both the port numbers and the source and destination IP addresses? Isn't it already protected from address changes by the da tagram checksum? /John >Not an expert, but my best-guess-protocol-based response would be for possible fragmentation. >If I were writing a similar protocol...would take into account the data link level transmission >medium below IP. >Sounds like the above scheme allows for just that. A datagram is so logically, right. There is >nothing to say it has to stay physically intact....during transit. What's the real deal wizards out there ? George Williams
barmar@think.com (Barry Margolin) (11/08/90)
In article <9011070014.AA08334@ucbvax.Berkeley.EDU> jcurran@SH.CS.NET (John Curran) writes: >I'm sure I've overlooked something, and could use a push.. > >Why does UDP (when used with checksumming enabled) create a pseudo-header >that contains both the port numbers and the source and destination IP >addresses? The pseudo-header doesn't have port numbers in it. It contains the addresses, the protocol number (17 when used with IP as the network layer), and the length. > Isn't it already protected from address changes by the datagram >checksum? From RFC 768: "This information gives protection against misrouted datagrams." In other words, it's there to detect failure of the IP layer. For instance, if the receiving host is single-homed and the datagram isn't a broadcast, the destination IP address in the pseudo-header could be the address of the interface rather than the address in the IP header, and which will catch attempts by a broken IP layer to pass up packets intended for another host (an IP layer might not check the destination address of packets coming in through a point-to-point link, or it might not be prepared for an interface being in promiscuous mode). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
braden@VENERA.ISI.EDU (11/08/90)
There are two answers, one historical and the other architectural. Historically, the early versions of TCP/IP followed the original Cerk&Kahn paper in having a single protocol. Only later (version 4) was it split into an IP and a Transport layer. When it was split, the addressing information was split between the two layers. But who wants to change the checksum definition...? The architectural justification was that the transport layer should be able to verify the integrity of its addressing information no matter what lower-layer protocol it runs over. "Don't trust ANYBODY". The TCP and UDP specs say, "This gives protection against misrouted segments". Actually, all it probably gives you is protection against software bugs. Bob Braden