Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 08 Jul 2013 15:32:35 +0200

On 20.06.2013 18:23, Tomek Mrugalski wrote:
> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
> feels it's ready for work group last call. Please review this draft and
> indicate whether or not you feel it is ready to be published.
> 
> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that
> control SOLICIT and INFORMATION-REQUEST message retransmissions and
> define a mechanism for server to override client's default values. There
> is a document in v6ops about basic requirements for IPv6 CE routers that
> depends on this work.
> 
> At the time of this writing, there is no IPR reported against this draft.
> 
> Bernie and I will evaluate consensus after 2013-07-04.
Very useful draft. I strongly support this work moving forward. I do
have some comments, though.

1. Clarifying question regarding text:

   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 3315

The (updated) section 17.1.2 says that SOLMAXRT is now 3600 (seconds).
Any value received in the option that is smaller than 3600 will mean
that the SOLICIT messages would be sent more frequently, thus must be
ignored. Does it mean that allowed range of values is 3600 - 2^32-2 ?

I'm somewhat ok with that, but I would prefer that there would be an
ability to revert to current behaviour, i.e. configure value of SOLMAXRT
option to 120, so old and new clients would behave the same way.

In any case, I think the allowed values should be explicitly specified
for both options. I would also consider the upper end of possible ranges
here. 2^32 seconds is around 136 years, so perhaps limiting the upper
value is a good idea as well? Speaking of big numbers, section 5.6 of
3315 says that 0xffffffff means infinity (I agree that it is somewhat
debatable if that applies to timers, but it's a matter of
interpretation). Is it allowed value here? That would mean that this
draft allows tweaking backoff mechanism to essentially have no upper
threshold. I prefer to not have a solution that can be told to count to
infinity.

2. Section 8 must be updated to cover also INF_MAX_RT value.

3. RFC3315 mentions client restarting configuration process in various
events (NotOnLink status received, received REPLY for INF-Request failed
validation, link change etc.) and there are operational events that also
trigger it: service restart, sleep/resume, device reboot etc. It is not
clear whether client should attempt to store the INF_MAX_RT and
SOL_MAX_RT values across those events? If not, at what situation should
it revert back to default (3600) values? I think it would be good to
clarify that.

4. It is not very well specified what should the client do if it
receives several ADVERTISEs, each with different SOLMAXRT (or INFMAXRT)?
I'm tempted to assume that according to the current text, it must
process them in the order in which they appear. That may not be the best
thing to do. Perhaps clarifying text about using exactly one value from
the received advertises could be helpful? I agree that having two
servers on the same link advertising different values is a bit uncommon
(configuration error or a rogue server), but clients should be able to
behave consistently in such case.

5. The text does not include Client and Server behaviour sections, as
recommended by option-guidelines-12, Section 21. I agree that this draft
is very simple, but it would be good to follow those recommendations if
possible.

6. Is RFC3633 reference really normative here? I think it should be
informative.

7. Ralph already mentioned his plan to have the name updated to reflect
the addition of INF_MAX_RT.

8. The discussion in Security considerations is not precise. According
to last paragraph of section 4 ("If a DHCPv6 client receives a message
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.").
Note that this sentence applies to all received messages, including
non-selected Advertises. So whether the value sent by legitimate or
rogue server will be used by the server, depends on the order of
received messages. Also see my comment #4.

Hope that helps,
Tomek

---

From: Ralph Droms <[email-masked]>
Date: Mon, 8 Jul 2013 15:25:06 -0400

> ignored. Does it mean that allowed range of values is 3600 - 2^32-2 ?

That paragraph isn't well written.  How about:

   If a DHCPv6 client receives a message 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.  This value of
   SOL_MAX_RT is then used by the retransmission mechanism defined in
   sections 17.1.2 and 14 of RFC 3315 [RFC3315].

...which would allow for values of SOL_MAX_RT smaller than the new default of 3600.

> option to 120, so old and new clients would behave the same way.

Does the new text address this issue by allowing a value of 120 in the SOL_MAX_RT option?
> threshold. I prefer to not have a solution that can be told to count to

In my opinion, the additional constraints aren't necessary and it would be better to minimize the changes relative to RFC 3315.

> 2. Section 8 must be updated to cover also INF_MAX_RT value.

e.g.:

8.  IANA Considerations

   IANA is requested to assign option codes from the "DHCP Option
   Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.

> behave consistently in such case.

Is this situation different from all the other options that might appear in messages from multiple servers?

There's a hidden point in your question: does this option apply when received in an Advertise message or just when received in a Reply message?

> is very simple, but it would be good to follow those recommendations if

Aw, I was trying to keep this draft as simple as possible.  I'll rewrite the draft if the consensus is that it should follow the guidelines but I'd prefer not to if possible.  Sorry to be lazy (and to resort to a bit of blackmail), but the reality is that rewriting for Client and Server behavior sections is likely to delay the document...
> 6. Is RFC3633 reference really normative here? I think it should be

Agreed.

> the addition of INF_MAX_RT.

"Modifications to Default Values of SOL_MAX_RT and INF_MAX_RT"
> received messages. Also see my comment #4.

Yeah, so perhaps "receives a message containing a SOL_MAX_RT option" should be constrained to just "receives a Reply message containing a SOL_MAX_RT option"?

> Tomek

Very helpful and thanks for your thorough and careful review.

- Ralph

> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 9 Jul 2013 00:18:21 +0000

See below.

John
-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Monday, July 8, 2013 3:25 PM
To: Tomasz Mrugalski <[email-masked]>
Cc: dhc WG <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01
-	respond by July 4

>Does the new text address this issue by allowing a value of 120 in the
[jjmb] the new text Ralph proposed seems to address Tomasz's comment well.

>In my opinion, the additional constraints aren't necessary and it would
>be better to minimize the changes relative to RFC 3315.
[jjmb] I would agree.
>There's a hidden point in your question: does this option apply when
>received in an Advertise message or just when received in a Reply message?
[jjmb] it seems the reply rules here like many other aspects of the DHCPv6
exchange.

>Aw, I was trying to keep this draft as simple as possible.  I'll rewrite
>the draft if the consensus is that it should follow the guidelines but
>I'd prefer not to if possible.  Sorry to be lazy (and to resort to a bit
>of blackmail), but the reality is that rewriting for Client and Server
>behavior sections is likely to delay the document...
[jjmb] I agree tre-writing should not be required here, I do not see the
need.

>Yeah, so perhaps "receives a message containing a SOL_MAX_RT option"
>should be constrained to just "receives a Reply message containing a
>SOL_MAX_RT option"?
[jjmb] as I stated above the reply is ultimately what should be used in
the exchange.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Jul 2013 14:00:37 +0200

On 13-07-08 21:25, Ralph Droms wrote:
>> 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
>> 3315
>> 
>> The (updated) section 17.1.2 says that SOLMAXRT is now 3600
>> (seconds). Any value received in the option that is smaller than
>> 3600 will mean that the SOLICIT messages would be sent more
>> frequently, thus must be ignored. Does it mean that allowed range
>> of values is 3600 - 2^32-2 ?
> 
> If a DHCPv6 client receives a message 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.  This value of SOL_MAX_RT is then
> used by the retransmission mechanism defined in sections 17.1.2 and
> 14 of RFC 3315 [RFC3315].
> 
That will work. But there's a potential danger of setting both timers to
too low value. Rogue server set in IPv4-only network could set both to 1
and then you'd have a nice packet storm in your network. On the other
hand I don't think it's a big deal as you can do the same now with T1=1
and very long lifetimes.

>> I'm somewhat ok with that, but I would prefer that there would be
>> an ability to revert to current behaviour, i.e. configure value of
>> SOLMAXRT option to 120, so old and new clients would behave the
>> same way.
> 
Yes, thank you.

>> In any case, I think the allowed values should be explicitly
>> specified for both options. I would also consider the upper end of
>> possible ranges here. 2^32 seconds is around 136 years, so perhaps
>> limiting the upper value is a good idea as well? Speaking of big
>> numbers, section 5.6 of 3315 says that 0xffffffff means infinity (I
>> agree that it is somewhat debatable if that applies to timers, but
>> it's a matter of interpretation). Is it allowed value here? That
>> would mean that this draft allows tweaking backoff mechanism to
>> essentially have no upper threshold. I prefer to not have a
>> solution that can be told to count to infinity.
> In my opinion, the additional constraints aren't necessary and it
> would be better to minimize the changes relative to RFC 3315.
Ok.

> 8.  IANA Considerations
> 
> IANA is requested to assign option codes from the "DHCP Option Codes"
> Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
That will work. Thanks.

>> 5. The text does not include Client and Server behaviour sections,
>> as recommended by option-guidelines-12, Section 21. I agree that
>> this draft is very simple, but it would be good to follow those
>> recommendations if possible.
> 
> Aw, I was trying to keep this draft as simple as possible.  I'll
> rewrite the draft if the consensus is that it should follow the
> guidelines but I'd prefer not to if possible.  Sorry to be lazy (and
> to resort to a bit of blackmail), but the reality is that rewriting
> for Client and Server behavior sections is likely to delay the
> document...
Nah, it won't delay anything. And I'm blackmail resistant. :) Please see
proposed XML attached with applied changes 1, 2, 5, 6, and 7. The only
outstanding issue is whether we want client to use SOL_MAX_RT and
INF_MAX_RT received in all messages or just REPLY. You may also look at
new nitpicks 9 and 10 below, if you think they are worth the effort.

If we go with REPLY only, we can remove almost all section 6, except
last NEW paragraph, so the draft becomes even simpler and changes to
3315 become smaller.

>> 7. Ralph already mentioned his plan to have the name updated to
>> reflect the addition of INF_MAX_RT.
> 
Sounds fine.

>> 8. The discussion in Security considerations is not precise.
>> According to last paragraph of section 4 ("If a DHCPv6 client
>> receives a message 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."). Note that this sentence applies to all
>> received messages, including non-selected Advertises. So whether
>> the value sent by legitimate or rogue server will be used by the
>> server, depends on the order of received messages. Also see my
>> comment #4.
That would work fine. One (minor) disadvantage is that with the current
text you can set up a dummy server that will send out NoAddsAvail and
longish SOL_MAX_RT/INF_MAX_RT if you don't want to be bothered with
DHCPv6 in your network and you want to limit the traffic. As I said
that's really minor disadvantage as the updated clients will go for 1
packet per hour and the old clients won't use SOL_MAX_RT anyway.

I have 2 other minor change proposals:

9. One other thing that occurred to me is possible addition of the
following text:

    Client also MAY include option SOL_MAX_RT in its SOLICIT,
    REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a
    hint for the server regarding preferred option values.

I always liked the idea that DHCP allows negotiations between client and
server. Sadly, most implementations don't take advantage of such
capability. But if you don't like this concept, I'm ok with not adding it.

10. You mention in 2 places that the options must be sent as top-level
options, not sub-options. We had a discussion with Ted and Bernie
regarding vocabulary. Ted prefers sub-options to be used for options
that use private number spaces (like sub-options in DHCPv4) and use
"nested" or "encapsulated" for DHCPv6. "Encapsulated" is used in
RFC3315, but I think it's not a good name as it has overloaded meaning
(the other is what relays do with client messages). If it was up to me
to decide, I would go with "nested", but I'm ok with whatever WG decides
to use. This terminology is discussed in section 9 of option-guidelines.
I'll be more than happy to update it if needed.

Thanks for doing this work.
Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Jul 2013 14:11:46 +0200

On 13-06-20 18:23, Tomek Mrugalski wrote:
> ...
Thank you to all of those that responded with support for moving this
document forward and thank you to Ralph for doing this useful work.

In my and Bernie's opinion this document has consensus to move forward.
There were couple minor issues discussed during WGLC and they will be
resolved in the next revision. As they are sufficiently small, no extra
WGLC is required. We will proceed with shepherding work as soon as
updated version becomes available.

As Bernie and Ralph both work for Cisco, Tomek will be the doc shepherd
for this draft.

Bernie & Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Jul 2013 16:13:57 +0000

>> should be constrained to just "receives a Reply message containing a

Don't we need clients to pick up the values in Advertises as a client that only receives NoAddrsAvail (which is usually not followed by Request/Reply) would never pick up the change. And if it gets to Reply stage, it likely doesn't need a new SolMax as it would likely have a lease and stop Soliciting.

Perhaps I am confused as to issue, but I think it has to do with which Advertise to chose when they are NoAddrsAvail cases. Shouldn't client only use SolMax from best (highest pref) Advertise (same as it would have used if it was not a NoAddrsAvail status)? 

- Bernie (from iPad)

On Jul 9, 2013, at 8:00 AM, "Tomek Mrugalski" <[email-masked]> wrote:

> <draft-ietf-dhc-dhcpv6-solmaxrt-update.xml>

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Jul 2013 18:56:55 +0200

On 09.07.2013 18:13, Bernie Volz (volz) wrote:
> Regarding:
> 
>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT
>>> option" should be constrained to just "receives a Reply message
>>> containing a SOL_MAX_RT option"?
> 
> Don't we need clients to pick up the values in Advertises as a client
> that only receives NoAddrsAvail (which is usually not followed by
> Request/Reply) would never pick up the change. And if it gets to
> Reply stage, it likely doesn't need a new SolMax as it would likely
> have a lease and stop Soliciting.
I thought about this a bit and I actually prefer Ralph's proposal to use
only REPLY messages. Here's why:
- if you have legacy clients (original 3315), they won't request
SOLMAXRT anyway. You can't do anything about them
- if you have clients that implement solmaxrt, they already start with
3600 value, so the original problem is mostly solved. They will use only
option that is delivered in the sole REPLY (as they do with every other
option).
- You don't have race conditions between advertises from different
servers sending different values in advertise.
- Implementation of the ADVERTISE with NoAddrsAvail would be tricky. The
text would have to say something like "client picks the value from that
ADVERTISE that it would have picked if the ADVERTISE had addresses".

> Perhaps I am confused as to issue, but I think it has to do with
> which Advertise to chose when they are NoAddrsAvail cases. Shouldn't
> client only use SolMax from best (highest pref) Advertise (same as it
> would have used if it was not a NoAddrsAvail status)?
It's more complicated than that. Highest preference is not the only
indicator. See 17.1.3 of RFC3315 ("The client MAY choose a
less-preferred server if that server has a better set of advertised
parameters, such as the available addresses advertised in IAs.").

I'm definitely with Ralph here - it is much cleaner to stick to REPLY
only. Speaking with my chair hat off and my implementor hat on: The
easiest to implement is this: the option will be requested in SOLICIT
and REQUEST, but only the value from REPLY will actually be consumed.
(that how every other option is used anyway).

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Jul 2013 17:08:42 +0000

I'm OK with that as I buy your analysis. And it would be tricky otherwise.

What about Information-Request and Reply to that? Can those include
SOLMAX? (Or just the Info Max).

   A DHCPv6 client MUST include the SOL_MAX_RT option code in an Option
   Request option [RFC3315] in any message it sends.

   The DHCPv6 server MAY include the SOL_MAX_RT option in any response
   it sends to a client that has included the SOL_MAX_RT option code in
   an Option Request option.

BTW: Perhaps already a known issue, but isn't the text in Section 5 wrong:

   5. INF_MAX_RT option

   A DHCPv6 server sends the INF_MAX_RT option to a client to override
   the default value of INF_MAX_RT.  The value of INF_MAX_RT in the
   option replaces the default value defined in Section 3.  One use for
   the INF_MAX_RT option is to set a longer value for INF_MAX_RT, which
   reduces the Solicit traffic from a client that has not received a
               ^^^^^^^ Information-Request
   response to its Solicit messages.

                   ^^^^^^^ Information-Request

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2013 18:42:05 +0000

> servers sending different values in advertise.

If there are multiple servers sending different values, it seems likely that something is broken.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Jul 2013 23:25:13 +0200

> If there are multiple servers sending different values, it seems likely that something is broken.
Yes, I stated that in previous mail. That is either a configuration
error or a rogue server. Nevertheless it would be good if client could
handle such situation gently. Ralph's proposal to use only options from
REPLY does that.

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 9 Jul 2013 22:48:46 +0000

Bernie I think you are correct as this is one the original scenarios that
resulted in this draft.  Thanks for catching this.

John
-----Original Message-----
From: Bernie Volz <[email-masked]>
Date: Tuesday, July 9, 2013 12:13 PM
To: Tomasz Mrugalski <[email-masked]>
Cc: dhc WG <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
respond by July 4

>Request/Reply) would never pick up the change. And if it gets to Reply
>stage, it likely doesn't need a new SolMax as it would likely have a
>lease and stop Soliciting.
>
>Perhaps I am confused as to issue, but I think it has to do with which
>Advertise to chose when they are NoAddrsAvail cases. Shouldn't client
>only use SolMax from best (highest pref) Advertise (same as it would have
>used if it was not a NoAddrsAvail status)?
>
>- Bernie (from iPad)
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 9 Jul 2013 23:34:28 +0000

See below.

-----Original Message-----
From: Tomasz Mrugalski <[email-masked]>
Date: Tuesday, July 9, 2013 12:56 PM
To: Bernie Volz <[email-masked]>
Cc: dhc WG <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
respond by July 4

>ADVERTISE that it would have picked if the ADVERTISE had addresses".
[jjmb] these are good points and I do not mean to seem like I am bouncing
back and forth.  I suppose what Tomasz is suggesting would be a reasonable
compromise.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Jul 2013 11:46:46 -0400

Please review -02 (thanks, Tomek!) and post any comments; "looks OK" is a fine comment.  If the chairs will determine consensus, I'll publish rev -02 tomorrow (Friday) as the final candidate for submission to the IESG.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Jul 2013 11:52:06 -0400

BTW, rev -02 specifies that the client uses SOL_MAX_RT and INF_MAX_RT in any message, not just a Reply message.  My sense is that WG consensus is leaning toward restricting those options to Reply messages.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Jul 2013 12:10:51 -0400

Tomek posted XML for -02 here: http://www.ietf.org/mail-archive/web/dhcwg/current/msg14454.html

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Jul 2013 12:37:10 -0400

.txt attached by request.

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 11 Jul 2013 17:58:59 +0000

A few nits:

5.  INF_MAX_RT option

** This impacts Information-Request, not Solicit messages. The text needs to be fixed.

8.  DHCPv6 Server Behavior
...
   body of the message to client, not as a sub-option in, e.g., an
   IA_NA, IA_TA [RFC3315] or IA_PD [RFC3633] option.

   The DHCPv6 server MAY include the INF_MAX_RT option in any response
   it sends to a client that has included the INF_MAX_RT option code in
   an Option Request option.  The INF_MAX_RT option is sent in the main
   body of the message to client, not as a sub-option in, e.g., an
   IA_NA, IA_TA [RFC3315] or IA_PD [RFC3633] option.

** Can we replace 'sub-option' with encapsulated? RFC 3315 uses 'sub-option' in only one place.

11.  IANA Considerations

   IANA is requested to assign an option code from the "DHCP Option
   Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.

** Shouldn't this say "DHCPv6 Option Codes" registry just to be clear or "from the DHCP Option Codes table of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) parameters registry maintained in http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml"?

Otherwise, I think this draft is now hopefully ready to go to the IESG (well, the AD first).

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Thursday, July 11, 2013 12:37 PM
To: [email-masked] WG
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 12 Jul 2013 13:02:29 +0200

On 11.07.2013 19:58, Bernie Volz (volz) wrote:
> ** Shouldn’t this say "DHCPv6 Option Codes" registry just to be clear or
> “from the DHCP Option Codes table of the Dynamic Host Configuration
> Protocol for IPv6 (DHCPv6) parameters registry maintained in
> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml”?
I was surprised with this one, but "DHCP Option Code" is the correct
name for DHCPv6 options registry. DHCPv4 options are listed in "BOOTP
Vendor Extensions and DHCP Options" registry. I would have named those
registries differently, but I suppose there's no procedure (or a real
need) to rename them. I think the text in IANA considerations is a bit
minimalistic, but correct.

Or perhaps not. One minor correction: "an option code" => "option codes".

> Otherwise, I think this draft is now hopefully ready to go to the IESG
Bernie, what's your opinion: should those options be consumed by client
from Advertise and Reply messages or from Reply only?

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 12 Jul 2013 12:14:54 +0000

The main reason for this was to handle situation where server didn't give addresses to client - thus just a Solicit/Advertise cycle (client has nothing to Request, so no Reply).

But because default has changed (120 -> 3600), it will reduce rate of Solicits. Might have been nice if server (via Advertise) could increase value further (1 day...).

If you thus just do this on the Reply, the utility of SOLMAX option is really lost.

- Bernie (from iPad)

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Jul 2013 08:54:32 -0400

> The main reason for this was to handle situation where server didn't give addresses to client - thus just a Solicit/Advertise cycle (client has nothing to Request, so no Reply).

Ah, right, of course.

Agreed.

But I'm concerned that we're letting the perfect be the enemy of the good in what should be a really simple use case.

Perhaps we can just drop the idea of the options altogether.  They will only be of value in devices that also use default SOLMAXRT == 3600.  Is changing the default enough to skate us past this transition case?

If so, I apologize for introducing the extra complexity w/o considering the consequences.  Lesson learned...

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 12 Jul 2013 13:23:18 +0000

While the text around which advertise's SOLMAX to take isn't very clear, it was I believe Tomek that had the main concerns. In thinking this through, in practice I don't see that this makes that much difference as "good" servers should all have the same values. And "bad" servers are hard to weed out anyway and can always craft packets that would be "preferred" over others - and I would think they'd prefer to give the client "their" service rather than telling the client to try less often - with the retransmission algorithm it still gives the real server plenty of opportunity to get a packet to the client (it isn't as if receiving SOLMAX means to set the next retransmission interval to that value and real offers of service will still be accepted). So a DoS attack using this isn't likely to be that effective unless the real servers' traffic can also be blocked.

- Bernie (from iPad)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 12 Jul 2013 13:24:10 +0000

> Perhaps we can just drop the idea of the options altogether.  They will only
> be of value in devices that also use default SOLMAXRT == 3600.  Is changing
> the default enough to skate us past this transition case?

I don't see the options as necessary to the problem we're trying to solve and would not object to dropping them.
Barbara

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Jul 2013 09:27:12 -0400

> I don't see the options as necessary to the problem we're trying to solve and would not object to dropping them.

Thanks, Barbara.

Might be good to hear from other operators (customers!) as well.  OK, so predicting the future is hard, but I'll ask anyway - do we anticipate another use case for this option beyond the immediate use case of an IPv6 deployment where some, but not all, devices will be granted IPv6 service via DHCPv6?

- Ralph

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 12 Jul 2013 15:43:09 +0200

On 12.07.2013 14:54, Ralph Droms wrote:
>> The main reason for this was to handle situation where server
>> didn't give addresses to client - thus just a Solicit/Advertise
>> cycle (client has nothing to Request, so no Reply).
That wouldn't be enough. If you want to limit DHCPv6 traffic in your
network, you'll also need to handle INF-REQUEST.

> Ah, right, of course.
> 
>> 
>> But because default has changed (120 -> 3600), it will reduce rate
>> of Solicits. Might have been nice if server (via Advertise) could
>> increase value further (1 day...).
>> 
> But I'm concerned that we're letting the perfect be the enemy of the
> good in what should be a really simple use case.
> 
> Perhaps we can just drop the idea of the options altogether.  They
> will only be of value in devices that also use default SOLMAXRT ==
> 3600.  Is changing the default enough to skate us past this
> transition case?
But the 3600 value was a judgement call. Some people may argue that 120
is a better value while other prefer 86400.

I think the approach with changing the value to 3600 and having those
options is a good one. It alleviates the problem and provide means to
fine tune if the default solution is not sufficient.

Here's my attempt to summarize all 3 possible solutions:

1. Change timer values only, no options
+ very short draft, easy to implement
- 3600 was an arbitrary chosen value. Some time in the future people may
  argue that it is too high/too low and may try to update it again, so
  it doesn't solve the the problem definitely.
- lack the flexibility for sysadmins to fine tune to their specific
  needs. (You want super fast recovery after server failure? set it to
  10. You plan to deploy IPv6 sometime in late 2020s? Set it to 86400
  or larger)

2. Allow options in Advertise and Reply:
+ you know which clients are updated and which are legacy (SOLMAXRT
  present in ORO or not)
+ flexibility to fine tune to specific networks
+ ability to deploy dummy server to send back NoAddrsAvail + SOLMAXRT
  to Solicits and Reply with INFMAXRT to inf-requests.
- you change how clients process options in advertise. Up to now, no
  option from advertise is ever consumed by the client, it is merely
  used to pick the most suitable server. Updating clients code for
  using that one specific option also in advertise will be difficult in
  some cases
- you get a solution that is less resistant to configuration errors or
  rogue servers. In both cases you may get different SOLMAXRT values in
  different Advertises. What's worse, the clients behavior will be
  dependent on the order in which Advertises were received. It also may
  vary between clients.
- if you allow Advertise, a bad guy can deploy rogue DHCPv6 server in
  IPv4-only networks (lots of them are still around), set SOLMAXRT to 1
  and enjoy his easy to pull off DDOS. What's worse, his rogue server
  could then disappear, but the DDOS would continue. (In a typical case
  a rogue DHCPv6 server in IPv4-only network can mess things up in many
  different ways, I admit. However, there are solutions that allow
  trust relationship between clients and a server.)
- the language in the text and the code implementing it would be tricky.
  It would have to say something like "client picks the value from that
  ADVERTISE that it would have picked if the ADVERTISE had addresses".
- lack of accountability. Clients won't really know who told them to
  use very low SOLMAXRT as the text says that every SOLMAXRT from every
  Advertise must be used. Implementors will likely not log the servers
  DUID, IP or MAC address.

3. Allow options in Reply only:
+ you know which clients are updated and which are legacy (SOLMAXRT
  present in ORO or not)
- dummy server would be less functional (it would handle inf-requests
  ok, but not Solicits that are more popular)
+ the confidence that you use data from a server you chose.
+ consistency between clients (each will have SOLMAXRT and INFMAXRT set
  to the same value in case of configuration issues or rogue servers)
+ flexibility to fine tune to specific networks
+ very easy to implement
+ simpler draft text than in #2
- more complex draft text than in #1

I really think that allowing SOLMAXRT and INFMAXRT options in Reply only
is the best way forward. It loses a bit on deploying dummy server, but I
think it is not that relevant. Clients that are able to handle SOLMAXRT
option are already using 3600 timer. Otherwise it has all benefits. My
preference is #3. If that is not acceptable, #1 would the next best
choice for me. I don't like #2, because it opens up too many abuse
options and is too tricky to implement.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 12 Jul 2013 13:43:21 +0000

Ralph ... I think the options should not be removed so hastily. For a network where service is expected, sending the 120 second value to override the 3600 is really important (and this could be in the Reply).

If a server provider has a maintenance window where service isn't available for a period, clients may then not retry but once every hour and thus may not have internet service or voice service for a long time. Yes, this won't help those clients that didn't previously communicate with the server (since the last boot) to get the shorter time. And cases where it would apply might be minimal with long lease times, but think of failover and MCLT restrictions - clients getting a "new" lease before the window would have had shorter MCLT lease times and could easily have returned to sending Solicits.

I think it could be a mistake to remove the options - not for the case to slow down retransmissions as the shift from changing the default from 120 to 3600 will improve that situtation, but in the cases where you want clients to use the original 120 (or shorter?) value to address the situation above.

I think this maintenance window issue may also be something that SPs haven't given careful consideration to as extending the window by an hour for some clients may have to be factored in.

- Bernie (from iPad)

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Jul 2013 09:52:06 -0400

Tomek - how does #3 handle the case in which no Reply is sent, such as the original use case in which no IPv6 addresses will be assigned (or prefixes delegated)?

I can imagine a bit of hackery in which the server returns an Advertise with addresses, but then returns a Reply with NoAddrsAvail.

Otherwise, the option won't be useful in the original use case.  It might be useful in other use cases.

- Ralph

---

From: "Weil, Jason" <[email-masked]>
Date: Fri, 12 Jul 2013 10:35:01 -0400

I'm leaning towards Barbara on this one. The options do give more
flexibility for those admins who find benefit, but they don't feel
critical to the original problem statement. We could always split this
work into two drafts and use this draft to make the necessary default
timer changes. If the options are deemed beneficial to members of the WG a
separate draft would allow more time for testing and analysis on their
impact.

Jason

>and would not object to dropping them.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 12 Jul 2013 17:00:55 +0200

On 12.07.2013 15:52, Ralph Droms wrote:
> Tomek - how does #3 handle the case in which no Reply is sent, such
> as the original use case in which no IPv6 addresses will be assigned
> (or prefixes delegated)?
It doesn't for stateful clients. If the client is modified, it will
stick to 3600, so the original problem is alleviated, we just lose the
ability to tweak it. If the client is legacy, it won't request SOLMAXRT
in the first place. For stateless clients it would work ok (reply sent
in response to inf-request). I admit that majority of clients are
stateful, though.

> I can imagine a bit of hackery in which the server returns an
> Advertise with addresses, but then returns a Reply with
> NoAddrsAvail.
That's certainly possible. But I think that the original use case
(setting up a dummy server to tell clients that dhcpv6 is not there, so
they should try less often) is not that important. Modified clients will
send 1 packet every hour anyway and legacy clients once every 2 minutes.
More important case is what Bernie metioned: you have functional
network, but need to bring down your DHCPv6 infrastructure for
maintenance and want to prepare them for it. In that case the reply only
(#3) would work.

> might be useful in other use cases.

If we leaning toward #2 (advertise and reply), I insist on limiting the
range of allowed values (both min and max) to prevent or at least limit
abuses.

Tomek

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Jul 2013 11:23:42 -0400

> in response to inf-request). I admit that majority of clients are

And we've gotten feedback from a couple of customers that just setting *_MAX_RT to 3600 should be sufficient.

> they should try less often) is not that important.

Ok.  But we don't have any other requested use case beyond the original one, in which a server is configured to Advertise addresses to some clients but not others.

In my opinion, any other use case, in which all clients are denied DHCPv6 address assignment, can be more conveniently managed by turning off the DHCPv6 relay, dropping the DHCPv6 messages in the relaying router, etc.  The only problematic case is when some, but not all, clients are granted DHCPv6 addresses.

> Modified clients will

Or just turn off the relay.  My understanding is the problem arises when millions of Solicits are aggregated at a DHCPv6 server, not when thousands are received by a relay.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Jul 2013 11:26:01 -0400

Just to be clear, in my opinion we could write a spec for the options that might provide some additional capabilities.  Do those additional capabilities address a useful problem and are we sure the design doesn't add implementation and operational risks?

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 12 Jul 2013 15:48:46 +0000

I think if there was text to limit the SOLMAX (and INF) option value to be 120 seconds to 1 day (24 hours), we could leave the options in place (and let the client use the values from Advertise messages). That would avoid really bad values and still give the possibility to set the value back to 120 for those cases where valid service is expected.

I'm not sure removing the options is the best avenue - as it provides no way to 'correct' any problems that might occur if the 3600 seconds turns out to have negative operational consequences.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Friday, July 12, 2013 11:26 AM
To: Tomek Mrugalski; Bernie Volz (volz)
Cc: [email-masked] WG
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

- Ralph

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 12 Jul 2013 18:34:18 +0200

On 12.07.2013 17:48, Bernie Volz (volz) wrote:
> I think if there was text to limit the SOLMAX (and INF) option value
> to be 120 seconds to 1 day (24 hours), we could leave the options in
> place (and let the client use the values from Advertise messages).
> That would avoid really bad values and still give the possibility to
> set the value back to 120 for those cases where valid service is
> expected.
I like this. With those lower and upper bounds, the solution #2 (have it
in advertise as the text specifies now) would be ok.

> I'm not sure removing the options is the best avenue - as it provides
> no way to 'correct' any problems that might occur if the 3600 seconds
> turns out to have negative operational consequences.
Good point.

Tomek

---

From: Ralph Droms <[email-masked]>
Date: Sat, 13 Jul 2013 16:57:34 -0400

>> turns out to have negative operational consequences.

Unless I hear otherwise, I'll modify the solmaxrt draft to:

1) allow the SOL_MAX_RT option to appear in any message
2) limit the valid range of values to 120 seconds to 1 day

and publish a new rev before the deadline Monday.

- Ralph

---

From: Tomek Mrugalski <[email-masked]>
Date: Sat, 13 Jul 2013 23:16:34 +0200

> 2) limit the valid range of values to 120 seconds to 1 day
That's a good way forward. It addresses all my concerns. Thank you.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 13 Jul 2013 23:56:58 +0000

Yes, I agree.

- Bernie (from iPad)

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Jul 2013 15:51:03 +0000

On Jul 12, 2013, at 7:02 AM, Tomek Mrugalski <[email-masked]> wrote:
> I would have named those

If there is strong desire in the working group to change the name, we can do that.   It would require a draft that updates all the specs that use that name, including the BOOTP specs.   It might be worth doing; if you think it is, feel free to make it happen.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 15 Jul 2013 09:13:56 +0100

I've submitted -02.  It includes the following changes:

1. range limits on "value" in the options: 60 <= "value" <= 86400 (1 day)
2. options can be included in any server message
3. restructured for options guidelines draft (thanks, Tomek!)
4. expanded security considerations (thanks, Tomek!)
5. in section 5, s/Solicit/Information-request/
6. in IANA considerations, s/an option code/option codes/
7. s/sub-option/encapsulated option/

There's one additional change.  I vaguely recall recent e-mail, perhaps from Ted, pointing out that text like this:

      A DHCPv6 client MUST include the INF_MAX_RT option code in an
      <xref target='RFC3315'>Option Request option</xref> in any
      message it sends.

is redundant w.r.t. RFC 3315 and should be omitted.  Makes sense to me, so I omitted it from -02.

- Ralph

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 15 Jul 2013 12:24:15 +0000

I for one do not feel strongly that that renaming is required.

=========================================
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
o) 609-377-6594
w) www.comcast6.net
e) [email-masked]
=========================================

-----Original Message-----
From: Ted Lemon <[email-masked]>
Date: Sunday, July 14, 2013 11:51 AM
To: Tomasz Mrugalski <[email-masked]>
Cc: dhc WG <[email-masked]>, Bernie Volz <[email-masked]>, Ralph Droms
<[email-masked]>

>If there is strong desire in the working group to change the name, we can
>do that.   It would require a draft that updates all the specs that use
>that name, including the BOOTP specs.   It might be worth doing; if you
>think it is, feel free to make it happen.
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 15 Jul 2013 14:44:28 +0200

On 14.07.2013 17:51, Ted Lemon wrote:
> If there is strong desire in the working group to change the name, we
> can do that.   It would require a draft that updates all the specs
> that use that name, including the BOOTP specs.   It might be worth
> doing; if you think it is, feel free to make it happen.
I doubt there's a strong need to do that. It's just an aesthetic detail.

I suppose that's another thing to do as part of the 3315bis work.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Jul 2013 14:36:38 +0000

> is redundant w.r.t. RFC 3315 and should be omitted.  Makes sense to me, so I omitted it from -02.

Thanks.   Personally, I think we should delete that text from 3315 as well.   I don't know of any server that implements this behavior, and I don't understand why it would be useful.   If the client already knows what to do, why ask the server at all?