Re: [dhcwg] draft-pruss-dhcp-auth-dsl-03

["Templin, Fred L" <[e-mail]>]

I haven't touched 'draft-templin-dhcpmtu' since the
last time this subject came up, but AFAICT it will
still work fine even if relay agent information
options are inserted.

Per RFC3046:

   "A DHCP relay agent adding a Relay Agent Information field SHALL add
   it as the last option (but before 'End Option' 255, if present) in
   the DHCP options field of any recognized BOOTP or DHCP packet
   forwarded from a client to a server."

So, as long as 'draft-templin-dhcpmtu' is updated to
say that the reassembly process ignores any relay agent
information options the DHCP fragmentation/reassembly
will still work fine. 

Ric is right that the normal-case link MTU is 1500 bytes,
but there is a remote possibility of smaller link MTUs
and/or larger DHCP messages; draft-templin-dhcpmtu'
addresses both possibilities. The approach would be
for the DHCP AUTH client to try w/o fragmentation first,
then try again using fragmentation if the unfragmented
attempt fails.

Fred
[e-mail] 
 

>-----Original Message-----
>From: Richard Pruss [mailto:[e-mail]] 
>Sent: Sunday, July 27, 2008 4:47 AM
>To: Yoshihiro Ohba
>Cc: [e-mail]
>Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-03
>
>Thanks for your comments,
>
>On 27/07/2008, at 10:19 AM, Yoshihiro Ohba wrote:
>
>> I have a couple of comments on new dhcp-auth I-D.
>>
>> - It still does not seem to address the issue of the difference in
>> retransmission directions.  Especially I am not sure how dhcp-auth
>> works when EAP-Success/Failure gets lost.
>>
>> - Comment on fragmentation.  The current draft says that 
>there is over
>> 200-octet space available more than the EAP MTU of 1020 octets.
>> However, I am not sure that if over 200-octet space is really
>> sufficient for 1500-octet MTU considering that DHCP relay agent
>> information option can be inserted by DHCP relay agent as well as
>> there can be 'shim' layers below IP.
>
>Relay's typically add only port information so I think we can 
>be quiet  
>safe with our 200 bytes
>also considering the real world EAP packet sizes.
>
>- Ric
>
>
>>
>>
>> - DHCP EAP request response message can be more confusing, 
>considering
>> the new extension to EAP such as ERX (draft-ietf-hokey-erx) where two
>> new messages are defined that are neither request nor response.
>> Considering ERX, I would strongly discourage combining DHCP and EAP
>> because ERX can make integration of DHCP and EAP even more difficult.
>> It is best if we separate IP address configuration from 
>network access
>> authentication.
>>
>> Regards,
>> Yoshihiro Ohba
>>
>> On Fri, Jul 25, 2008 at 08:41:44AM +1000, Richard Pruss wrote:
>>> Hi,
>>>
>>> To help the discussion next week I was prompted to put out a  
>>> summary of
>>> changes.
>>> http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-03
>>>
>>> We have tried in this version to address concerns raised in IETF 70.
>>> Jari and Ralph's preso may remind you of those:
>>> http://www.ietf.org/proceedings/07dec/slides/intarea-2/sld1.htm
>>>
>>> We have added a first draft proposal for DHCPv6 messages for a  
>>> limited
>>> set of IPv6 deployments.
>>> http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-03#section-5.2
>>>
>>> We now have added a DHCP relay model to the DHCP 
>proxy/server model  
>>> that
>>> was the document model.
>>> (DHCP proxy is a term used in the DSL architectures, where 
>the BRAS  
>>> acts
>>> as a server to the client.)
>>>
>>> We have added a section on fragmentation.
>>> http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-03#section-8
>>>
>>> The DHCP EAP request response messages are now separate messages to
>>> possibly make the flow clearer
>>> and hopefully make the discussion around DHCP vs EAP retransmission
>>> responsibility easier for people to understand.
>>>
>>> There is a section on backwards compatibility and a number of cases
>>> considered, no updates to that but it addresses one of the 
>bullets on
>>> the slides in IETF-70.
>>>
>>> - Ric
>>>
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg