On Sun, Oct 28, 2007 at 04:22:27PM -0400, Ralph Droms wrote: > The only reference to fragmentation in RFC 951 is: > > 3. Packet Format > > [...] For > simplicity it is assumed that the BOOTP packet is never fragmented. > > There are no references to fragmentation in RFC 213[12] or RFC 3315. > > In my opinion, this reference is to simplicity in the IP layer, not > in the BOOTP layer. The IP layer handles any fragmentation and the > BOOTP/DHCP layers are unaware of that fragmentation. Therefore, any > addresses included in the DHCP messages are irrelevant to BOOTP/DHCP > message reassembly.
I don't think IP layer can correctly reassemble IP datagrams with the unspecified source address (0.0.0.0) which breaks uniqueness of fragments among multiple *different* source nodes. > > On the other hand, as I wrote in a previous message, all bets are off > regarding L2 (or other) devices that snoop the DHCP messages without > performing IP reassembly. Sure, this is another issue. > > And, as a practical matter, I suspect all extant DHCP clients and > servers have a DHCP message MTU less than 1500 octets. For the above reasons, DHCP message should not be IP-fragmented. However, DHCP message MTU being not more than link-layer MTU can be a non-workable requirement when carrying EAP, considering the fact that EAP can consume up to 1020 octets and additionally other options need to be carried in a DHCP message. Yoshihiro Ohba > > - Ralph > > > On Oct 25, 2007, at Oct 25, 2007,8:28 PM, Yoshihiro Ohba wrote: > > >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
