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.
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.
And, as a practical matter, I suspect all extant DHCP clients and
servers have a DHCP message MTU less than 1500 octets.
- 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
