Re: [Int-area] DCHP-based authentication for DSL?

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
>>>> Int-area@lists.ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/int-area
>>>
>>>
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@lists.ietf.org
>>> https://www1.ietf.org/mailman/listinfo/int-area
>>
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/int-area
>>

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area