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

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Jan 2012 06:23:19 -0500

I've posted a revised version of draft-droms-dhc-dhcpv6-solmaxrt-update that addresses most of Bernie's discussion points.  Left unaddressed are:

* putting an upper limit on the value of SOL_MAX_RT that a client will accept

* details about retaining SOL_MAX_RT across soft reboots and not resetting
 the Solicit retry timer when a SOL_MAX_RT option is received

Discussion encouraged...

- Ralph

On Dec 16, 2011, at 11:59 AM 12/16/11, Ralph Droms wrote:

> 
> 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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Ted Lemon
>>> Sent: Friday, December 09, 2011 12:58 PM
>>> To: [email-masked] 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 30 Jan 2012 23:19:03 +0100

On 12-01-17 12:23, Ralph Droms wrote:
> I've posted a revised version of
> draft-droms-dhc-dhcpv6-solmaxrt-update that addresses most of
> Bernie's discussion points.  Left unaddressed are:
> 
You may also want to put lower limit as well. See below.

> * details about retaining SOL_MAX_RT across soft reboots and not
> resetting the Solicit retry timer when a SOL_MAX_RT option is
> received
> 
> Discussion encouraged...
I read -02 version and support this draft.

Couple of comments:

1. Header should explicitely metion that RFC3315 will be updated:
updates: 3315 (if approved).

2. I would put paragraphs from section 3 into separate "Client behavior"
and "Server behavior" sections. It's easier for implementors. On the
other hand, the whole combined text is less than a page, so it is not
that important.

3. What happens if server provides very low value, like SOLMAXRT = 1?
The only defense against that is currently "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 3315" at the end of
Section 3. Is that enough? Perhaps this could be mentioned in the
security considerations section? Maybe it would be useful to add a
statement that values below 120 seconds (old default value) MUST be
ignored by clients? If that is not desired for some reason, then at
least value of 0 should be forbidden.

5. What happens when client gets 2 advertises (one with solmaxrt and one
without) and chooses the one without solmaxrt (e.g. because it contains
addresses or have higher preference value). Clients usually discard the
second advertise completely. Is this the intended behavior here? There
is a valid case that could potentially lead to problems. When 2 servers
are running and only one provides solmaxrt option, its value	 may be
ignored.

6. What happens when there are 2 advertise responses with NoAddrsAvail,
e.g. first with maxsolrt=10000 and second maxsolrt=20000. Should client
use the just one of them? Pick the latest? Pick random? This should be
clarified. I agree that providing different values is mostly a
configuration error.

7. Can solmaxrt option appear in reconfigure message?

Tomek