I felt some deeper analysis on fragmentation seemed necessary after
volume of emails on the topic.
A couple of emails lay out the basics of the matter:
http://www1.ietf.org/mail-archive/web/int-area/current/msg01110.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01116.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01121.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01124.html
The facts in summary:
"For simplicity it is assumed that the BOOTP packet is never
fragmented." - RFC 951
According to [RFC3748 <http://tools.ietf.org/html/rfc3748>], lower
layers must provide an EAP MTU of 1020 bytes or greater.
"Also, not all EAP methods support fragmentation, and among those that
do, not all implementations support an MTU that varies on a per-packet
basis." - Bernard Aboba
Now this is all fine but from the thread I infer that people are making
two additional incorrect assumptions that actually introduce a problem
where none exists.
The first assumption is people assume the minimum DHCP message size,
which is not reasonable or accurate for the deployments use cases at
hand. The link MTU here can be reasonably assumed to be at least 1500
bytes as it is Ethernet.
Secondly people seem to assume that other DHCP options will be making
the space available for EAP options to stack vary, thus creating a
variable MTU for EAP. This is not the case, the draft has an option
which puts one-way chap onto the existing methods but for the EAP
alternative a new DHCP message is proposed just to carry the EAP message
option.
Thus in summary there is no fragmentation issue as DHCP Authentication
alternative for EAP.
- Ric
P.S. Also on a simple practical note but kind of off topic, I had a look
at EAPOL traces for the various methods nothing and in the sample I saw
nothing was near 500 bytes in length from the ones that do not support
fragmentation. The main two that are of a concern that do not support
fragmentation today are EAP-SIM and EAP-AKA, how large do these actually
get, in practice, I understand new messages could expact EAP-SIM but
what is it today?
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
