Subject: [Capwap] Issue 227: Require proper DHCP client and server behavior

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 14 Oct 2008 15:35:22 -0700

All,

During the IESG review, there were some comments associated with whether
some 
of the text in the draft should be changed from a SHOULD to a MUST.
After 
review of the draft, the following comment was made:

>   All - I have a couple of concerns about simply changing the SHOULDs
to MUSTs 
>   in the paragraphs describing the DHCP (I'll use DHCP for DHCPv[46]
throughout) 
>   client and server behaviors.
>   
>   The first concern is about the timing of the DHCP client in the WTP
device, 
>   especially if the WTP function is instantiated in a device  
>   after the DHCP client has completed its initial message exchange.   
>   That is, the DHCP client may not know that the WTP will be
instantiated at 
>   some point, and may not know to ask for the CAPWAP AC option.
>   
>   It is possible for the WTP function, if it finds it does not have
access to 
>   the CAPWAP AC option info, to use a separate message (DHCPINFORM or 
>   Information-Request) to obtain the information.  I suggest the
following text 
>   for DHCPv4 and (with appropriate changes)
>   DHCPv6:
>   
>      A DHCPv4 client, acting on behalf of a CAPWAP WTP, MUST request
the CAPWAP 
>   AC DHCPv4 Option
>      in a Parameter Request List Option, as described in RFC 2131 and
RFC 2132.
>   
>   I think this text allows for the case when the DHCP client is
unaware of the 
>   WTP, and the WTP function invokes DHCPINFORM/Information- Request
later.
>   
>   The second concern is about the description of when the DHCP server
should 
>   respond with the CAPWAP AC option.  The current text doesn't allow
for DHCP 
>   server policy to control the inclusion of the option in the response
to the 
>   client.  This policy may work both ways - the server may have a
policy to 
>   return the option even if the client hasn't requested it, because
the server 
>   can determine that the device is a WTP and will need the option, or
the server 
>   may have a policy not to return the option to certain clients even
if the 
>   client lists the option in the PRL/ORO.  Text to allow for server
policy might 
>   be:
>   
>      A DHCPv4 server returns the CAPWAP AC Option to the client if the
server 
>   policy is configured
>      appropriately and the server is configured with a list of CAPWAP
AC 
>   addresses.

I have made the requested changes, and the resulting text looks like:

<modified text>
2.  CAPWAP AC DHCPv4 Option
[...]
   A DHCPv4 client, acting on behalf of a CAPWAP WTP, MUST request the
   CAPWAP AC DHCPv4 Option in a Parameter Request List Option, as
   described in [RFC2131] and [RFC2132].

   A DHCPv4 server returns the CAPWAP AC Option to the client if the
   server policy is configured appropriately and the server is
   configured with a list of CAPWAP AC addresses.

3.  CAPWAP AC DHCPv6 Option
[...]
   A DHCPv6 client, acting on behalf of a CAPWAP WTP, MUST request the
   CAPWAP AC DHCPv6 Option in a Parameter Request List Option, as
   described in [RFC3315].

   A DHCPv6 server returns the CAPWAP AC Option to the client if the
   server policy is configured appropriately and the server is
   configured with a list of CAPWAP AC addresses.
</modified text>

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap