Hi Erik,
There are many implementations that don't have the ability to reassemble a 65,353 byte packet, at least not without allocating a 64K buffer for this purpose. So, this seems to be a harsh restriction to place on RFC 2893 implementations. If we need to choose one or the other, I'd prefer limiting the MTU of these tunnels to 1280. Margaret At 08:10 AM 8/9/02 , Erik Nordmark wrote: > > since there's no standard, some implementation can be picky and > > assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU. > >How about: > A node implementing RFC 2893 MUST be able to reassemble IPv4 packets > of a size up to and including 65353 octets and MUST NOT place > any limits on the size of the received encapsulated packets. > In particular, it MUST NOT assume that the maximum size of > received packets has anything to do with the MTU for the tunnel. > >Of course, it might also make sense to add some SHOULD (or MUST?) to >section 3.2 in RFC 2893 to make IPv4 MTU discovery across the tunnel >seem less optional than what the current text says. > > Erik > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to [EMAIL PROTECTED] >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
