home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / protocol / tcpip / ibmpc / 6424 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  1.5 KB
  1. Path: sparky!uunet!ornl!rsg1.er.usgs.gov!darwin.sura.net!wupost!uwm.edu!linac!att!ucbvax!FTP.COM!jbvb
  2. From: jbvb@FTP.COM ("James B. Van Bokkelen")
  3. Newsgroups: comp.protocols.tcp-ip.ibmpc
  4. Subject: Re: Fragmented IP packets: any PD implementations?
  5. Message-ID: <9211191653.AA01396@ftp.com>
  6. Date: 19 Nov 92 16:53:11 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Reply-To: jbvb@ftp.com
  9. Distribution: world
  10. Organization: The Internet
  11. Lines: 23
  12.  
  13. 'Tis not my intent to jump on you, Erick, but I don't believe this is true
  14. either.
  15.  
  16.     For those interested, a good way to easily and reliably receive a fragment
  17.     for testing your code is to send a MTU sized ICMP echo request, the reply
  18.     will have to be fragmented if it bounces off of a properly implemented
  19.     system.
  20.  
  21. ICMP Echo Reply is supposed to be almost exactly the same header and data
  22. as found in the Echo Request (except for reversing the addresses and any
  23. source routes, and using the receiving system's default TTL).  Even if the
  24. IP header contained a Record Route option, the sender had to set an initial
  25. allocation and the receiver won't change the header length.  So I don't see
  26. why the reply would need to be fragmented.
  27.  
  28. I first tested IP fragmentation by increasing the PCs MTU to above the
  29. attached network's, and sending big UDP datagrams from a Unix box.  We
  30. now test it with two PCs on different large MTU networks (e.g. 802.5)
  31. talking across an intermediate Ethernet.
  32.  
  33. James B. VanBokkelen        2 High St., North Andover, MA  01845
  34. FTP Software Inc.        voice: (508) 685-4000  fax: (508) 794-4488
  35.  
  36.