[dhcwg] WG meeting follow-up - draft-ietf-dhc-rfc3315bis (1/3)

[dhcwg] WG meeting follow-up - draft-ietf-dhc-rfc3315bis (1/3) - Raise objections by 12/1/2017

"Bernie Volz (volz)" <volz@cisco.com> Wed, 23 November 2016 19:44 UTC

From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: WG meeting follow-up - draft-ietf-dhc-rfc3315bis (1/3) - Raise objections by 12/1/2017
Thread-Index: AdJFwM5vhF36djpVRHyUWmOuS8VEHw==
Date: Wed, 23 Nov 2016 19:44:30 +0000
Message-ID: <b059e3c62d9b42eeb8a74a1e004e607d@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_b059e3c62d9b42eeb8a74a1e004e607dXCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/IqN7HRO1jW9qyfnrEmr38acO2s0>
Subject: [dhcwg] WG meeting follow-up - draft-ietf-dhc-rfc3315bis (1/3) - Raise objections by 12/1/2017
Precedence: list

Hi:

At IETF-97 (Seoul) I presented several issues that had been raised by reviewers during the WGLC of draft-ietf-dhc-rfc3315bis-05.

The first was regarding RFC 7083 SOL_MAX_RT/INF_MAX_RT:

Here are the Etherpad notes taken by Tim Chown and others:

Proposal is to use "smallest" legal value across the received options
In principle, all servers should be configured the same.
Ted Lemon: good idea to take the smallest length that you hear, to avoid bad guy sending long values.
Suresh: idea was to allow changes to default, including reducing traffic from it. Perhaps use default in cases of conflict?
Bernie: Sounds plausible.
Bernie: Also, when do you ever set it back to the default? RFC 7083 doesn't talk about that. Should we address that?
Suresh: Do you keep track of which value comes from which server?
Tomek: Implementation-specific.
Tim Winters: We only see it in home gateways; most lose it when you reboot. A couple keep it forever - interesting! So might want to say something about this to avoid applying a value for ever.
Ted: I like Suresh's suggestion. Not likely to be a problem in typical use case; if cable modem sends a solicit, it's on the cable network, so unlikely to get a 3rd party attack is slim. So, good idea, but not a serious issue. I suggest you discard values on link state transition.
Bernie: Should these options be allowed in confirm/rebind case? Maybe doesn't matter.

Action: will confirm on list (inc. Suresh's suggestion?)

So, this email is to confirm that we use Suresh's suggested mechanism which is that when a Client is receiving responses for Solicits (or Information-Requests) it track the SOL_MAX_RT/INF_MAX_RT values that are received. If the values returned DIFFER between responses, the client should then use the default values.

Note: The assumption here is that only the values received while normally waiting to receive a response for a transmitted request are compared; values from previous attempts are ignored. If only one response is received, its value can be used.

We will assume that everyone supports this approach UNLESS someone raises an objection. You have until 12/1/2017 to raise an objection.

See slide #4 at https://www.ietf.org/proceedings/97/slides/slides-97-dhc-dhcpv6bis-open-issues-discussion-01.pdf.

- Bernie (for the bis team)

[dhcwg] WG meeting follow-up - draft-ietf-dhc-rfc… Bernie Volz (volz)