Re: [dhcwg] WGLC: draft-droms-dhc-dhcpv6-solmaxrt-update-00

[Ralph Droms <[e-mail]>]

On Dec 15, 2011, at 10:25 PM 12/15/11, Bernie Volz (volz) wrote:

> Ralph:
> 
> The following text in section 3:
> 
>   If a DHCPv6 client receives an IA_NA or IA_TA option containing a
>   SOL_MAX_RT option, the client MUST set its internal SOL_MAX_RT
>   parameter to the value contained in the SOL_MAX_RT option.  As a
>   result of receiving this option, the DHCPv6 client MUST NOT send any
>   Solicit messages more frequently than allowed by the retransmission
>   mechanism defined in sections 17.1.2 and 14 of RFC 315 [RFC3315].
> 
> Fails to mention IA_PD (you probably forgot to update that sentence).

Oops.  Actually, I meant to edit out all references to IA_NA or IA_PD.  The goal is to simply change the default SOL_MAX_RT as that parameter is defined in RFC 3315, leaving aside any considerations of extended mechanisms for dealing with unsatisfied IA_* requests.
> 
> And, I thought we were also considering using this when a client is not
> given any addresses AND/OR delegated any prefixes? But, perhaps you
> don't think that is necessary? If it is necessary (do read further down
> to the end as there are some other potential issues to consider with
> that), this draft would need to update several sections of RFC 3315? In
> particular:
> 
> 17.1.3. Receipt of Advertise Messages
> 
>   The client MUST ignore any Advertise message that includes a Status
>   Code option containing the value NoAddrsAvail, with the exception
>   that the client MAY display the associated status message to the
>   user.
> 
> ...
> 
> 17.2.2. Creation and Transmission of Advertise Messages
> 
> ...
> 
>   If the server will not assign any addresses to any IAs in a
>   subsequent Request from the client, the server MUST send an Advertise
>   message to the client that includes only a Status Code option with
>   code NoAddrsAvail and a status message for the user, a Server
>   Identifier option with the server's DUID, and a Client Identifier
>   option with the client's DUID.
> 
> 
> 17.1.3 has a MUST ignore. If the client included the SOL_MAX_RT option
> in the ORO, then it should not ignore but check for that option?
> 
> 17.2.2 says MUST include only ... again, if client requested SOL_MAX_RT
> option in the ORO, server SHOULD include it.
> 
> So, your section 2. "Update to RFC 3315" would need to say something
> about that these sections are impacted.

Yes.  Good catch.

> ---
> 
> I also wonder whether to reduce the impact of the Security
> Considerations section we should impose some limit to the SOL_MAX_RT
> value that can be communicated by a Server. I was thinking that
> something like a day (86,400 seconds) would be a reasonable limit. But,
> not sure it really helps that much as that is rather long to be without
> [IPv6] service. And, if you had 10 Million devices on a network (and
> assuming they all were at that SOL_MAX_RT value), that results in 116
> Solicits/second which is probably still a fairly high rate. If you
> limited it to a week, that rate drops to 17 packets/second.

I'll leave this topic open for discussion.

> ---
> 
> Some nits the RFC editor would likely catch ....
> 
> 3.  SOL_MAX_RT option
> ...
> 
>  mechanism defined in sections 17.1.2 and 14 of RFC 315 [RFC3315].
>                                                     ^^^

OK.

> 4.  Security Considerations
> 
>   This document introduces one security considerations beyond those
>                                                      ^?
>   described in RFC 3315 [RFC3315].

OK.

> 6.  Normative References
> 
> The references should include RFC 3633 as you now mention IA_PD (even
> before my issue above).

OK.

> Why do you include the following as it is never referenced?
> 
>   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
>              Discovery for IP Version 6 (IPv6)", RFC 2461,
>              December 1998.
> 
> Perhaps it was explicitly referenced in the -00 draft because of the M/O
> bits?

Right.

> 
> ---
> 
> A few other nits:
> 
> In section 1, it says "high volume of aggregated traffic at a DHCPv6
> server" ... would also cause high volumes of traffic if there is no
> DHCPv6 server. Might also revise section 2 (significantly reducing the
> aggregated traffic at the DHCPv6 server). I think the "at the DHCPv6
> server" can be dropped?

Maybe, except if there is no DHCPv6 server, the traffic issue can be mitigated by turning off the relay agents.

> Especially if we change the draft to allow the SOL_MAX_RT option to be
> communicated when no addresses (and/or prefixes) are provided, it would
> be worth (in section 3) to indicate that a client should use the server
> provided SOL_MAX_RT value until some 'hard' reboot (not just a soft
> reset) -- some devices may soft reset every so often when waiting to
> come online which would defeat the utility of the server provided
> SOL_MAX_RT. Also, that an updated SOL_MAX_RT value should not cause the
> client to in any way reset its Solicit timer (we don't want it to reset
> the current timing algorithm (other than to cap the timeout) if
> retrying).

Hm.  I'm not sure how to specify "hard reboot" versus "soft reset"...

- Ralph

> 
> - Bernie
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Ralph Droms
> Sent: Thursday, December 15, 2011 9:56 AM
> To: dhc WG
> Subject: Re: [dhcwg] WGLC: draft-droms-dhc-dhcpv6-solmaxrt-update-00
> 
> I've published rev -01 taking into account comments from Bernie and
> others.
> 
> The changes:
> 
> * simplifies the discussion of "why is this option is needed"
> * applies the new SOL_MAX_RT value to any Solicits (leaving aside the
> question of how a client will deal with an Advertise that satisfies,
> e.g., an IA_NA request but not an IA_PD request)
> * requires client to request the option in an ORO
> * clarifies that the server returns the option in the main body of a
> response
> 
> I think this option can be moved forward without tying it to the
> resolution of partial IA_* assignments.  This option simplify modifies
> the default value of SOL_MAX_RT.  Any future modifications to the
> definition and use of SOL_MAX_RT would be independent of this option -
> i.e., would be specified in terms of SOL_MAX_RT or some new MAX_RT
> defaults - so this new option would apply (or not) regardless.
> 
> Pragmatically, there is interest in the SP and vendor community to move
> this option forward so the soon-to-be deployed IPv6-capable CE routers
> can mitigate issues with certain deployment scenarios.
> 
> - Ralph
> 
> On Dec 10, 2011, at 10:16 PM 12/10/11, Bernie Volz (volz) wrote:
> 
>> I think this draft needs to be updated a bit. It never mentions
> ANYTHING
>> about IA_PD.
>> 
>> I think whenever a server returns NoAddrsAvail or NoPrefixAvail
> status,
>> it should be able to provide this option in the response to indicate
> to
>> the client a new SOL_MAX_RT value for the IA type(s) requested by the
>> client.
>> 
>> The draft fails to solve the situation where a CPE routers that
> request
>> both an IA_NA and IA_PD (whether in one or two requests) does so
>> frequently. The current draft handles the case where addresses are not
>> being provided, but fails to handle the case where IA_PDs are also not
>> being provided.
>> 
>> - Bernie
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Ted Lemon
>> Sent: Friday, December 09, 2011 12:58 PM
>> To: [e-mail] WG
>> Subject: [dhcwg] WGLC: draft-droms-dhc-dhcpv6-solmaxrt-update-00
>> 
>> Ralph's put in an individual submission draft with Jari as the
>> sponsoring AD.   The draft attempts to solve a problem ISPs are having
>> where in a massive IPv6 network that isn't entirely deployed, devices
>> are requesting configuration too often.
>> 
>> Ralph's draft proposes a new option whereby a DHCP server can indicate
>> in response to a solicit that the client should use a larger value for
>> SOL_MAX_RT.   This means that clients will continue their exponential
>> backoff to whatever limit is stated in the offer, and reduces the
>> overall traffic on the DHCP servers at the core of the network.
>> 
>> The draft is an individual submission, so it doesn't technically have
> to
>> pass dhcwg last call-just IETF last call.   However, since the dhcwg
> is
>> where DHCP protocol extensions are done, I'm doing a last call here to
>> encourage people to review it-it would really help if some wg
>> participants would review it and think about the implications.
>> 
>> If we don't hear anything by December 23, Jari will continue the
> process
>> of advancing the draft.   If you do read the draft, please comment
> here
>> as to whether you support it, and please offer any suggestions you may
>> have.
>> 
>> Thanks!
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg