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