Subject: PPPoE & IPv6: packet too long?

From: "Christian Huitema" <[email-masked]>
Date: Mon, 17 Sep 2001 15:19:41 -0700

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?

-- Christian Huitema
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Sep 2001 16:06:22 -0700

> MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6.

fix the code

randy

---

From: Robert Elz <[email-masked]>
Date: Tue, 18 Sep 2001 08:28:44 +0700

Date:        Mon, 17 Sep 2001 15:19:41 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | What should we do?

The rational solution is that when the PPPoE implementations are enhanced
to support IPv6 (since it is PPP, it knows about address negotiation, and
hence needs to be updated), then simultaneously update the implementation
to be able to handle a more sensible MTU for IPv6 .. this has to be a much
more trivial change than supporting IPv6 in the first place.

But also, since any PPP can have almost any MTU configured into it, I would
assume that IPv6 over PPP will be (or has already) defining some link level
fragmentation scheme, as required for any link level for IPv6 with an MTU
less than 1280.   Since PPPoE is more or less just PPP, it should be able
to use the same mechanisms, if it finds its link MTU happens to have been
set < 1280.

The only other option for IPv6 over PPP would be to define that the minimum
MTU for a PPP link carrying IPv6 is 1280 - in which case PPPoE will just
have to follow along.

kre

---

From: Matt Crawford <[email-masked]>
Date: Tue, 18 Sep 2001 09:00:04 -0500

> MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6.

Require RFC1990 multilink capability.  End of story.

1.2.  Functional Description

   The method discussed here is similar to the multilink protocol
   described in ISO 7776 [4], but offers the additional ability to split
   and recombine packets, thereby reducing latency, and potentially
   increase the effective maximum receive unit (MRU).  Furthermore,
   there is no requirement here for acknowledged-mode operation on the
   link layer, although that is optionally permitted.
[...]
   The effective MRU for the logical-link entity is negotiated via an
   LCP option.  It is irrelevant whether Network Control Protocol
   packets are encapsulated in multilink headers or not, or even over
   which link they are sent, once that link identifies itself as
   belonging to a multilink arrangement.
[...]
5.1.1.  Multilink MRRU LCP option

                   Figure 4:  Multilink MRRU LCP option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 17   |   Length = 4  | Max-Receive-Reconstructed-Unit|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The presence of this LCP option indicates that the system sending it
   implements the PPP Multilink Protocol.  If not rejected, the system
   will construe all packets received on this link as being able to be
   processed by a common protocol machine with any other packets
   received from the same peer on any other link on which this option
   has been accepted.

   The Max-Receive-Reconstructed unit field is two octets, and specifies
   the maximum number of octets in the Information fields of reassembled
   packets.  A system MUST be able to receive the full 1500 octet
   Information field of any reassembled PPP packet although it MAY
   attempt to negotiate a smaller, or larger value.  The number 1500
   here comes from the specification for the MRU LCP option in PPP; if
   this requirement is changed in a future version of RFC 1661, the same
   rules will apply here.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------