EAP fragment size clarification needed

Artur Hecker hecker at wave-storm.com
Mon Sep 24 11:46:34 CEST 2007


Hello



On 24 Sep 2007, at 09:58, Alan DeKok wrote:

> Stefan Winter wrote:
>> I wonder what the sentence about MAX packet size on APs is about.  
>> Is it their
>> maximum allowed length of a RADIUS packet? Frankly, that would be  
>> quite
>> stupid because packets can legitimately be much larger than that.  
>> (-> RADIUS
>> implementation problem on AP)

The problem is that neither EAP per se nor EAPOL support  
fragmentation/reassembly, only certain EAP methods do. These however,  
by design, are not implemented on the NAS (i.e. AP). So you get a  
problem on the link when exceeding link MTU.


>> So if the above holds true, I would much rather set fragment size  
>> to 1500, and
>> fix any upcoming impl problems that have nothing to do with EAP  
>> frag size,
>> rather than yield with my frag size.
>
>   That's why it's configurable.  Others have reported issues with
> fragment sizes larger than 1024.  Some even need it to be less.
>
>   Alan DeKok.

Set it to 1500 and try it out. If it works with your APs, fine. The  
RFC 3748 and the RFC 4017 only dictate Minumum MTU:


 From RFC3748 (interesting reading, explains the situation)


   [4] Minimum MTU.  EAP is capable of functioning on lower layers that
        provide an EAP MTU size of 1020 octets or greater.

        EAP does not support path MTU discovery, and fragmentation and
        reassembly is not supported by EAP, nor by the methods  
defined in
        this specification: Identity (1), Notification (2), Nak Response
        (3), MD5-Challenge (4), One Time Password (5), Generic Token  
Card
        (6), and expanded Nak Response (254) Types.

        Typically, the EAP peer obtains information on the EAP MTU from
        the lower layers and sets the EAP frame size to an appropriate
        value.  Where the authenticator operates in pass-through mode,
        the authentication server does not have a direct way of
        determining the EAP MTU, and therefore relies on the
        authenticator to provide it with this information, such as via
        the Framed-MTU attribute, as described in [RFC 3579], Section  
2.4.

        While methods such as EAP-TLS [RFC 2716] support  
fragmentation and
        reassembly, EAP methods originally designed for use within PPP
        where a 1500 octet MTU is guaranteed for control frames (see
        [RFC 1661], Section 6.1) may lack fragmentation and reassembly
        features.

        EAP methods can assume a minimum EAP MTU of 1020 octets in the
        absence of other information.  EAP methods SHOULD include  
support
        for fragmentation and reassembly if their payloads can be larger
        than this minimum EAP MTU.


However, I read once somewhere (cant' recall where) that in practice,  
it is *not* recommended to exceed approx. 1200 bytes MTU.


Artur




More information about the Freeradius-Users mailing list