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

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Dec 2011 17:58:21 +0000

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!

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 10 Dec 2011 21:16:54 -0600

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Dec 2011 09:56:16 -0500

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 15 Dec 2011 21:25:32 -0600

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).

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.

---

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.

---

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].
                                                     ^^^

4.  Security Considerations

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

6.  Normative References

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

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?

---

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?

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).

- 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Dec 2011 05:53:21 +0000

On Dec 15, 2011, at 9:56 AM, Ralph Droms wrote:
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, are you arguing that we should pass this on sooner than the date I originally proposed?   Given that we've had some review and that we generally don't get late review, and that this particular review is informal, I'm not entirely opposed to that, but please let me know if that's what you intended.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 16 Dec 2011 11:59:41 -0500

> 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.
> about that these sections are impacted.

Yes.  Good catch.

> limited it to a week, that rate drops to 17 packets/second.

I'll leave this topic open for discussion.

>  mechanism defined in sections 17.1.2 and 14 of RFC 315 [RFC3315].

OK.

>   described in RFC 3315 [RFC3315].

OK.

> The references should include RFC 3633 as you now mention IA_PD (even

OK.

> Perhaps it was explicitly referenced in the -00 draft because of the M/O

Right.

> aggregated traffic at the DHCPv6 server). I think the "at the DHCPv6

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

> the current timing algorithm (other than to cap the timeout) if

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

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Dec 2011 20:52:37 +0000

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

I think that if the DHCP client is required not to cache the value of SOL_MAX_RT across restarts, that would address this concern.   You know the standard IT crowd question: did you turn it off and then on again?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 16 Dec 2011 14:56:04 -0600

There are really two issues:

1.       If the client always 'resets' and never uses the server
provided value, then the server provided value has no usefulness.

2.       We don't want the client to keep the server provided value in
'stable storage' between hard power cycles.

This is tricky to describe.

-          Bernie

From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, December 16, 2011 3:53 PM
To: Ralph Droms
Cc: Bernie Volz (volz); dhc WG
Subject: Re: [dhcwg] WGLC: draft-droms-dhc-dhcpv6-solmaxrt-update-00

		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 think that if the DHCP client is required not to cache the value of
SOL_MAX_RT across restarts, that would address this concern.   You know
the standard IT crowd question: did you turn it off and then on again?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 16 Dec 2011 15:57:44 -0500

Nope, no need to move faster.  Just wanted to remind the WG that it would be better to comment sooner rather than later...

- Ralph