Isn't DHCP designed based on the same assumption as BOOTP in terms of IP fragmentation? BOOTP assumes that BOOTP messages are never fragmented according RFC 951.
An issue with fragmenting DHCP message I can think of is that a DHCP relay agent or server may not be able to correctly reassemble fragmented messages when simultaneously received from multiple DHCP clients if the source address of those messages is unspecified (0.0.0.0). How does DHCP address this issue? Note: DHCPv6 does not have this issue because a specified address is always used. Yoshihiro Ohba On Wed, Oct 24, 2007 at 05:03:01PM -0400, Ralph Droms wrote: > Sorry, I made a goof. Relay agents can forward fragmented DHCP > messages. There is, if I recall correctly, a recommendation against > fragmentation (perhaps RFC 2131); however, the stack on the node > where the relay agent is instantiated will re-assemble the DHCP > message before delivering it to the relay agent, and then re-fragment > the new DHCP message resent by the relay agent. > > - Ralph > > On Oct 24, 2007, at Oct 24, 2007,4:54 PM, Ralph Droms wrote: > > >Section 6.3 of draft-pruss-dhcp-auth-dsl-01 addresses how to fit > >the EAP info into DHCP options, using RFC 3396. > > > >However, there is also a recommendation, when using EAP, that the > >server set the "Maximum DHCP Message Size" option to 1604. Sending > >a DHCP message of this size may require fragmentation, but DHCP > >relay agents cannot forward fragmented DHCP messages. > > > >- Ralph > > > >On Oct 24, 2007, at Oct 24, 2007,4:36 PM, Richard Pruss wrote: > > > >> > >> > >>Stig Venaas wrote, around 24/10/07 7:23 PM: > >>>It's not as simple as just putting credentials into option 82 > >>>though. > >>>For one thing there are strict limits on the size of DHCP > >>>messages that > >>>will limit what EAP or other mechanisms you can use. When the EAP > >>>MTU is too small for the EAP message, you need multiple requests and > >>>responses to transport the message. This is not possible without > >>>major DHCP changes. Hence you are not free to use what EAP > >>>mechanisms > >>>or credentials you like without major changes to DHCP. While with > >>>say > >>>PANA you could do that. > >>> > >>Stig section 6.3 of the currently posted -01 draft addresses the > >>size issue of EAP in some detail, it is not clear if you are > >>saying the proposed mechanism would not work. > >> > >>Regardless of the mechanism if one thinks of this from the > >>implementation it should be no big deal as for EAP and RADIUS one > >>has to chop EAP into small enough chunks to get through > >>limitations in RADIUS (<253 bytes). While DHCP has similar > >>problems (<255 bytes), and one could can expect that most > >>networking companies would have implemented the lower common > >>denominator of RADIUS here. > >> > >>Regards, > >>Ric > >> > >> > >> > >> > >>_______________________________________________ > >>Int-area mailing list > >>[email protected] > >>https://www1.ietf.org/mailman/listinfo/int-area > > > > > >_______________________________________________ > >Int-area mailing list > >[email protected] > >https://www1.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
