eap Mailing List: Ordered delivery of EAP messages

[Glen Zorn (gwz) (gwz]

Title: Ordered delivery of EAP messages

RFC 3748, section 3.1 says

   [6] Ordering guarantees.  EAP does not require the Identifier to be
       monotonically increasing, and so is reliant on lower layer
       ordering guarantees for correct operation.  EAP was originally
       defined to run on PPP, and [RFC1661] Section 1 has an ordering
       requirement:

           "The Point-to-Point Protocol is designed for simple links
           which transport packets between two peers.  These links
           provide full-duplex simultaneous bi-directional operation,
           and are assumed to deliver packets in order."

       Lower layer transports for EAP MUST preserve ordering between a
       source and destination at a given priority level (the ordering
       guarantee provided by [IEEE-802]).

       Reordering, if it occurs, will typically result in an EAP
       authentication failure, causing EAP authentication to be re-run.
       In an environment in which reordering is likely, it is therefore
       expected that EAP authentication failures will be common.  It is
       RECOMMENDED that EAP only be run over lower layers that provide
       ordering guarantees; running EAP over raw IP or UDP transport is
       NOT RECOMMENDED.  Encapsulation of EAP within RADIUS [RFC3579]
       satisfies ordering requirements, since RADIUS is a "lockstep"
       protocol that delivers packets in order.

My question is, since EAP is also a lockstep protocol, under what conditions could EAP messages be delivered out of order, regardless of  lower layer behavior WRT in-order delivery?