Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)
RFC 4638

Note: This ballot was opened for revision 03 and is now closed.

(Mark Townsley) Yes

(Jari Arkko) No Objection

Comment (2006-05-25)
No email
send info
> By default, the Maximum-Receive-Unit (MRU) option MUST follow the
> rules set forward in RFC1661 [2], but MUST NOT be negotiated to a
> larger size than 1492 to guarantee compatibility with Ethernet
> network segments limited to 1500 octets frames. In such a case, 
> the PPPoE header being 6 octets and the PPP Protocol ID being 
> 2 octets, the PPP MRU MUST NOT be greater than 1492.

The "MUST NOT be negotiated" actually comes from PPPoE. Perhaps you
could make this clearer, as RFC 1661 does allow > 1492 MRU.  For
instance, you can change the first sentence to "By default, the
Maximum-Receive-Unit (MRU) option MUST follow the rules set forward in
RFC 1661 [2] and RFC 2516 [1]. The latter RFC requires that the MRU
MUST NOT be negotiated to a larger size than 1492 to guarantee
compatibility with Ethernet network segments limited to 1500 octets
frames."

(This relates, by the way, to the discussion that the PPPEXT WG has
had about this protocol extension. It turns out that PPP MRU option
itself would have been sufficient to do this if a value > 1492 were
supplied - in theory. In practise, old PPPoE implementations do not always
get it right, so to confirm that the other side actually can handle a
larger MTU we need something.)

Editorial:

  * There are 4 instances of lines with non-ascii characters in the
    document.

(Lisa Dusseault) No Objection

Comment (2006-05-25)
No email
send info
I share the concerns about interoperability (how the large frames are exchanged) and IANA registry but I'm happy somebody else is already holding the discusses for those.

(Lars Eggert) (was Discuss) No Objection

Comment (2006-05-23)
No email
send info
Section 4., para. 1:

>    If a PPPoE client wants to use a higher MTU/MRU than 1492 octets,
>    then it MUST include an optional PPP-Max-Payload Tag in the PADI
>    and PADR packets.
>    If the PPPoE server can support a higher MTU/MRU than 1492 octets, it
>    MUST respond with an echo of the clients tag in the PADO and PADS
>    packets when the PPP-Max-Payload tag is received from the client.

        This text doesn't prohibit the inclusion of the tag with values
        less than 1492 octets - is it desired to allow this? (Seems like it,
        considering the text in Section 5.1.)

Section 1., para. 0:

>    If the PPP-Max-Payload tag isn?t present, or is present but below
>    1492, then the existing MRU constraint of 1492 octets MUST stay
>    applicable, hence preserving backward compatibility.

        Nit: s/isn?t/is not/

(Russ Housley) (was Discuss) No Objection

Comment (2006-05-24)
No email
send info
  A few words of introduction is Section 1 before the list of acronyms
  seems appropriate.  They are simply listed after the RFC 2119 boiler
  plate.

(Cullen Jennings) No Objection

(Dan Romascanu) (was Discuss) No Objection

Magnus Westerlund (was Discuss) No Objection

(Ted Hardie) Abstain

(David Kessens) Abstain

Comment (2006-05-25)
No email
send info
The write-up doesn't convince me that there is IETF consensus to move this
work further.

I also keep wondering why the solution of the problem described in 
this draft is sought in modifying the PPPoE protocol. Perhaps it would
be more appropriate to use the proper tool for the job and not use
PPPoE at all. I have been involved in very early deployments of DSL service
and we did not have any of these problems because we did not use PPPoE in
the first place.