At 3:19 PM -0700 9/17/01, Christian Huitema wrote:
>According to RFC 2516, PPPoE, the Maximum-Receive-Unit (MRU) option MUST
>NOT be negotiated to a larger size than 1492. If PPPoE implementations
>actually negotiated an MRU size of 1492 bytes, we would not have an
>issue. However, many implementations of PPPoE servers only support an
>MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6.
>
>What should we do?
Two choices: either get those implementations fixed, or decide on a
below-IP-layer method for segmenting and reassembling IPv6 packets
sent over such PPPoE links. Isn't there a PPP-based segmentation/
reassembly mechanism already defined (in the context of "PPP
multilink" or something)? Such a mechanism would be useful to
have for very low-speed links to allow small, higher-priority,
jitter-sensitive packets (as determined by diffserv codepoints
or intserv signalling) to be sent interleaved with lower-priority,
full-size packets (the same rationale as for ATM's small cell size,
but applied only where really needed, i.e., on very low-speed links).
However, given that we are talking about PPP over *ethernet*, the
very-low-speed issues do not arise and it seems a shame to cruft
up the link with even more complexity and overhead, so maybe it's
worth the effort to get the implementations fixed to negotiate an
MRU >= 1280 -- I can't imagine what would prohibit that, given that
the implementations must be able to cope with receiving ethernet
packets with up to 1500 bytes of payload. (On the other hand, anyone
advocating the use of PPPoE obviously doesn't care about complexity
or overhead...)
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
