home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / ibmpc / 6272 < prev    next >
Encoding:
Text File  |  1992-11-12  |  3.0 KB  |  69 lines
  1. Newsgroups: comp.protocols.tcp-ip.ibmpc
  2. Path: sparky!uunet!ukma!rsg1.er.usgs.gov!darwin.sura.net!sgiblab!newsun!donp
  3. From: donp@novell.com (don provan)
  4. Subject: Re: Fragmented IP packets: any PD implementations?
  5. Message-ID: <1992Nov12.223215.5263@novell.com>
  6. Keywords: IP fragments TCP/IP
  7. Sender: news@novell.com (The Netnews Manager)
  8. Nntp-Posting-Host: na.sjf.novell.com
  9. Organization: Novell, Inc., San Jose, California
  10. References: <BxM5tu.Jws@watserv1.uwaterloo.ca>
  11. Date: Thu, 12 Nov 1992 22:32:15 GMT
  12. Lines: 55
  13.  
  14. In article <BxM5tu.Jws@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
  15. >As you may have known, I initially wrote much of
  16. >my TCP without a real network around...
  17.  
  18. What a coincidence!  Me, too!  (Of course, in my case it was because
  19. at the time there was no real TCP/IP network *anywhere*....)
  20.  
  21. >A very common oversight from practically everyone who answerred was the
  22. >assumption that using 576 byte packets is the answer.
  23.  
  24. To be honest, i've found that it's usually counter productive to bring
  25. up networks with MTUs smaller than 576.  It's typically very hard to
  26. change the mind of someone that's convinced 576 is the minimum legal
  27. MTU, and someone like yourself that understands what the 576 byte
  28. limit really means don't need to be reminded of smaller MTUs.
  29.  
  30. >I believe that the RFCs recommend against router reassembly, however it is
  31. >never listed as verboten, just impractical.  The only statement I can find
  32. >is in RFC 1009:
  33.  
  34. OK, you caught me.  I was being vague not because i don't have a
  35. specific reference, but because the reference is rather complicated.
  36. The reference is Almquist, P., Editor, "Requirements for IP Routers",
  37. Internet Draft (draft-ietf-rreq-iprouters-03.txt), October 1, 1991.
  38. As far as i can piece together, about a year ago when this draft was
  39. released, it was on the verge of being published as the RFC replacing
  40. RFC-1009.  Suddenly, all interest in it was lost and the RFC was never
  41. published.  I don't know what the deal is, but i still use it as the
  42. latest thinking in router requirements.  The applicable quote from
  43. page 62 of that document follows:
  44.  
  45.          4.2.2.7  Reassembly: RFC-791 Section 3.2
  46.  
  47.            As specified in Section 3.3.2 of [INTRO:2], a router MUST
  48.            support reassembly of datagrams which it delivers to itself.
  49.  
  50.            A router MUST NOT reassemble any datagram before forwarding
  51.            it.
  52.  
  53.            DISCUSSION:
  54.                 A few people have suggested that there might be some
  55.                 topologies where reassembly of transit datagrams by
  56.                 routers might improve performance.  In general,
  57.                 however, the fact that fragments may take different
  58.                 paths to the destination precludes safe use of such a
  59.                 feature.
  60.  
  61.                 Nothing in this section should be construed to control
  62.                 or limit fragmentation or reassembly performed as a
  63.                 link layer function by the router.
  64.  
  65. So that's my justification for saying that reassembly by routers is
  66. forbidden.
  67.                         don provan
  68.                         donp@novell.com
  69.