Subject: RE: Question re. RECONFIG in DHCPv6

From: "Lin, Ping (Ping)" <[email-masked]>
Date: Fri, 8 May 2015 18:23:26 +0000

Hi Everyone,

I was wondering if you could help with a question about RECONFIG in DHCPv6:

RFC 3736 indicates that stateless DHCPv6 does not support the RECONFIGURE message.  If this is the case for stateless DHCPv6, how important is RECONFIGURE support for stateful DHCPv6 and how much is it used in practice?

Thanks very much,
Ping Lin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 10 May 2015 14:00:43 +0000

For stateless DHCPv6, the Information Refresh Time (see RFC 4242) is usually used to cause periodic client refreshes. Reconfigure requires authentication and so only applies to the cases that can use authentication - and use of authentication with Information-Request only is unclear from RFC 3315. The RFC 3315 bis work will remove much of the authentication support (except for Reconfigure Key Auth. Protocol (RKAP)) - this requires stateful.

The RFC 3736 document is really not something I would recommend following - see full RFC 3315 and implement those features you need (such as only Information-Request and Reply). 3736 was written to demonstrate that stateless dhcpv6 was rather simple to implement.

Technically if a client has done Solicit/... and then later the server's configuration has changed, a Reconfigure message specifying the client should send Information-Request is allowed (if only "other congifuration" options have changed).

I don't have any good data as to how important Reconfigure is and it is optional for client and server to implement/support - client specifies whether it can support it when RKAP is used. There are some uses where it is required, such as for CableLabs DOCSIS Cable Modems (see the CableLabs standards). But whether this is actually used in the field for DOCSIS (i.e. server providers make use of it) is unclear.

- Bernie (from iPad)

On May 9, 2015, at 9:12 AM, Lin, Ping (Ping) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Everyone,

Thanks very much,
Ping Lin

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 11 May 2015 12:20:39 +0000

It's required for pretty much every CE router that wants to connect to a "standard" ISP access network. Not just DOCSIS. It's required in BBF TR-124 and RFC 7084. But according to conversations I've had with various telco ISPs, it is about having the capability there just in case it's needed to forcibly renumber (IA_PD or IA_NA) the CE router. I'm also not aware of any cases where it's actually been used. But unless there is widespread unhappiness or very vocal singular unhappiness over a renumbering incident, I would never expect to hear of such cases.
Barbara

From: ipv6 [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, May 10, 2015 10:01 AM
To: Lin, Ping (Ping)
Cc: Mudric, Dusan (Dusan); [email-masked]
Subject: Re: Question re. RECONFIG in DHCPv6

- Bernie (from iPad)

Thanks very much,
Ping Lin

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 11 May 2015 12:30:38 +0000

As Bernie said, authentication is an issue with DHCPv6 Reconfigure.  Currently, how are folks testing Reconfigure and its authentication step?

Hemant

From: ipv6 [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Monday, May 11, 2015 8:21 AM
To: Bernie Volz (volz); Lin, Ping (Ping)
Cc: Mudric, Dusan (Dusan); [email-masked]
Subject: RE: Question re. RECONFIG in DHCPv6

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 11 May 2015 13:15:06 +0000 (UTC)

From: "STARK, BARBARA H" <[email-masked]>
 To: Bernie Volz (volz) <[email-masked]>; "Lin, Ping (Ping)" <[email-masked]> 
Cc: "Mudric, Dusan (Dusan)" <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Monday, 11 May 2015, 22:20
 Subject: RE: Question re. RECONFIG in DHCPv6
   
#yiv2206513416 #yiv2206513416 -- _filtered #yiv2206513416 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv2206513416 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv2206513416 #yiv2206513416 p.yiv2206513416MsoNormal, #yiv2206513416 li.yiv2206513416MsoNormal, #yiv2206513416 div.yiv2206513416MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv2206513416 a:link, #yiv2206513416 span.yiv2206513416MsoHyperlink {color:blue;text-decoration:underline;}#yiv2206513416 a:visited, #yiv2206513416 span.yiv2206513416MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv2206513416 p.yiv2206513416MsoListParagraph, #yiv2206513416 li.yiv2206513416MsoListParagraph, #yiv2206513416 div.yiv2206513416MsoListParagraph {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv2206513416 span.yiv2206513416EmailStyle18 {color:windowtext;}#yiv2206513416 span.yiv2206513416EmailStyle19 {color:#1F497D;}#yiv2206513416 span.yiv2206513416EmailStyle20 {color:#1F497D;}#yiv2206513416 span.yiv2206513416EmailStyle21 {color:windowtext;}#yiv2206513416 .yiv2206513416MsoChpDefault {font-size:10.0pt;} _filtered #yiv2206513416 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv2206513416 div.yiv2206513416WordSection1 {}#yiv2206513416 It’s required for pretty much every CE router that wants to connect to a “standard” ISP access network. Not just DOCSIS. It’s required in BBF TR-124 and RFC 7084. But according to conversations I’ve had with various telco ISPs, it is about having the capability there just in case it’s needed to forcibly renumber (IA_PD or IA_NA) the CE router. I’m also not aware of any cases where it’s actually been used. But unless there is widespread unhappiness or very vocal singular unhappiness over a renumbering incident, I would never expect to hear of such cases. Barbara

/ I think these conversations you've had with various ISPs show a lack of understanding of IPv6's mechanisms to support transitioning between one address space and another. I think the perceived need for "flash renumbering" disappears when you have the ability to start expressing addressing preferences via preferred and valid lifetimes and an understanding of IPv6's address src/dst address selection rules.
/ Regards,Mark.    

From: ipv6 [mailto:[email-masked]] On Behalf OfBernie Volz (volz)
Sent: Sunday, May 10, 2015 10:01 AM
To: Lin, Ping (Ping)
Cc: Mudric, Dusan (Dusan); [email-masked]
Subject: Re: Question re. RECONFIG in DHCPv6    For stateless DHCPv6, the Information Refresh Time (see RFC 4242) is usually used to cause periodic client refreshes. Reconfigure requires authentication and so only applies to the cases that can use authentication - and use of authentication with Information-Request only is unclear from RFC 3315. The RFC 3315 bis work will remove much of the authentication support (except for Reconfigure Key Auth. Protocol (RKAP)) - this requires stateful.    The RFC 3736 document is really not something I would recommend following - see full RFC 3315 and implement those features you need (such as only Information-Request and Reply). 3736 was written to demonstrate that stateless dhcpv6 was rather simple to implement.    Technically if a client has done Solicit/... and then later the server's configuration has changed, a Reconfigure message specifying the client should send Information-Request is allowed (if only "other congifuration" options have changed).    I don't have any good data as to how important Reconfigure is and it is optional for client and server to implement/support - client specifies whether it can support it when RKAP is used. There are some uses where it is required, such as for CableLabs DOCSIS Cable Modems (see the CableLabs standards). But whether this is actually used in the field for DOCSIS (i.e. server providers make use of it) is unclear.    - Bernie (from iPad) 
On May 9, 2015, at 9:12 AM, Lin, Ping (Ping) <[email-masked]> wrote: 
Hi Everyone,   I was wondering if you could help with a question about RECONFIG in DHCPv6:   RFC 3736 indicates that stateless DHCPv6 does not support the RECONFIGURE message.  If this is the case for stateless DHCPv6, how important is RECONFIGURE support for stateful DHCPv6 and how much is it used in practice?    Thanks very much, Ping Lin       

[email-masked]

[email-masked]

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 11 May 2015 13:57:17 +0000

UCR2013 states:

“IP6-000260 [Required: EI] [Conditional: NA/SS] [Alarm] If the product is a DHCPv6 client, then it shall log all reconfigure events. “
Based on your comments, RECONFIGURE is still not required in the industry and this requirement priority does not reflect the real need for RECONFIGURE. Without RECONFIGURE, the clients will be able to get the new configuration updates with some delay, after the address renewals.

If RFC4862 “Removed the text regarding the M and O flags”, does it mean the stateless DHCPv6, RFC 3736, and its management using M and O flags, are not required in industry either?

Regards,
Dusan.

From: Mark ZZZ Smith [mailto:[email-masked]]
Sent: Monday, May 11, 2015 9:15 AM
To: STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping)
Cc: Mudric, Dusan (Dusan); [email-masked]
Subject: Re: Question re. RECONFIG in DHCPv6

________________________________
From: "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; "Lin, Ping (Ping)" <[email-masked]<mailto:[email-masked]>>
Cc: "Mudric, Dusan (Dusan)" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, 11 May 2015, 22:20
Subject: RE: Question re. RECONFIG in DHCPv6

It’s required for pretty much every CE router that wants to connect to a “standard” ISP access network. Not just DOCSIS. It’s required in BBF TR-124 and RFC 7084. But according to conversations I’ve had with various telco ISPs, it is about having the capability there just in case it’s needed to forcibly renumber (IA_PD or IA_NA) the CE router. I’m also not aware of any cases where it’s actually been used. But unless there is widespread unhappiness or very vocal singular unhappiness over a renumbering incident, I would never expect to hear of such cases.
Barbara

/ Regards,
Mark.

From: ipv6 [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, May 10, 2015 10:01 AM
To: Lin, Ping (Ping)
Cc: Mudric, Dusan (Dusan); [email-masked]<mailto:[email-masked]>
Subject: Re: Question re. RECONFIG in DHCPv6

- Bernie (from iPad)

Thanks very much,
Ping Lin

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=AwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=D-C5TComNe7_-FWnWFHfT0lDkFnk_O9fJRUVSkS5ON4&s=hqyw0oLY_sjeimghuLsK21aW1tAiuykHUh5sjrurRv0&e=>
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=AwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=D-C5TComNe7_-FWnWFHfT0lDkFnk_O9fJRUVSkS5ON4&s=hqyw0oLY_sjeimghuLsK21aW1tAiuykHUh5sjrurRv0&e=>
--------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 11 May 2015 23:18:55 +0900

The best characterization of this situation I've heard is from Steven: CPE
routers "are supposed to must" implement reconfigure. :-)

I don't know that it would be wise for an operator to rely on reconfigure
support in CPEs unless they had stringent acceptance testing and certified
the CPEs themselves.

On Mon, May 11, 2015 at 9:20 PM, STARK, BARBARA H <[email-masked]> wrote:

>  It’s required for pretty much every CE router that wants to connect to a
> “standard” ISP access network. Not just DOCSIS. It’s required in BBF TR-124
> and RFC 7084. But according to conversations I’ve had with various telco
> ISPs, it is about having the capability there just in case it’s needed to
> forcibly renumber (IA_PD or IA_NA) the CE router. I’m also not aware of any
> cases where it’s actually been used. But unless there is widespread
> unhappiness or very vocal singular unhappiness over a renumbering incident,
> I would never expect to hear of such cases.
>
> Barbara
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Bernie Volz
> (volz)
> *Sent:* Sunday, May 10, 2015 10:01 AM
> *To:* Lin, Ping (Ping)
> *Cc:* Mudric, Dusan (Dusan); [email-masked]
> *Subject:* Re: Question re. RECONFIG in DHCPv6
>
>
>
> For stateless DHCPv6, the Information Refresh Time (see RFC 4242) is
> usually used to cause periodic client refreshes. Reconfigure requires
> authentication and so only applies to the cases that can use authentication
> - and use of authentication with Information-Request only is unclear from
> RFC 3315. The RFC 3315 bis work will remove much of the authentication
> support (except for Reconfigure Key Auth. Protocol (RKAP)) - this requires
> stateful.
>
>
>
> The RFC 3736 document is really not something I would recommend following
> - see full RFC 3315 and implement those features you need (such as only
> Information-Request and Reply). 3736 was written to demonstrate that
> stateless dhcpv6 was rather simple to implement.
>
>
>
> Technically if a client has done Solicit/... and then later the server's
> configuration has changed, a Reconfigure message specifying the client
> should send Information-Request is allowed (if only "other congifuration"
> options have changed).
>
>
>
> I don't have any good data as to how important Reconfigure is and it is
> optional for client and server to implement/support - client specifies
> whether it can support it when RKAP is used. There are some uses where it
> is required, such as for CableLabs DOCSIS Cable Modems (see the CableLabs
> standards). But whether this is actually used in the field for DOCSIS (i.e.
> server providers make use of it) is unclear.
>
>
>
> - Bernie (from iPad)
>
>
> RFC 3736 indicates that stateless DHCPv6 does not support the RECONFIGURE
> message.  If this is the case for stateless DHCPv6, how important is
> RECONFIGURE support for stateful DHCPv6 and how much is it used in
> practice?
>
>
>
> Thanks very much,
>
> Ping Lin
>
>
>
>
>
>
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 May 2015 08:46:24 -0700

At Mon, 11 May 2015 13:57:17 +0000,

> If RFC4862 “Removed the text regarding the M and O flags”, does it mean the stateless DHCPv6, RFC 3736, and its management using M and O flags, are not required in industry either?

The short answer is "the change in RFC4862 does NOT mean such things".

A bit longer answer would be:

- It's not clear what you mean by "not required in industry", but
  whatever an RFC states it's not uncommon that the "industry" ignores
  what's written in the RFC.  So the answer to a question like this
  would basically always be "No".
- Ignoring the "in industry" part, RFC4862 says nothing about whether
  to support stateless DHCPv6 or at which requirement level.
- Also ignoring the "in industry" part, RFC4862 does not deprecate the
  use of M or O flags by removing text about these flags.  See
  appendix C of the RFC.

--
JINMEI, Tatuya

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 11 May 2015 17:02:26 +0000

Why are the M & O flags not deprecated if RFC 2462 is obsolete? If RFC 4862 obsoletes RFC 2462, what is the value of supporting M and O flags? Why would new devices support an obsolete standard (i.e. 2462)? Backward compatibility?

Dusan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, May 11, 2015 11:46 AM
To: Mudric, Dusan (Dusan)
Cc: Mark ZZZ Smith; STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping); [email-masked]
Subject: Re: Question re. RECONFIG in DHCPv6

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 11 May 2015 17:27:33 +0000

Read RFC 4862:

   o  Removed the text regarding the M and O flags, considering the
      maturity of implementations and operational experiences.
      ManagedFlag and OtherConfigFlag were removed accordingly.  (Note
      that this change does not mean the use of these flags is
      deprecated.)

-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:[email-masked]] 
Sent: Monday, May 11, 2015 1:02 PM
To: 神明達哉
Cc: Mark ZZZ Smith; STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping); [email-masked]
Subject: RE: Question re. RECONFIG in DHCPv6

Dusan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, May 11, 2015 11:46 AM
To: Mudric, Dusan (Dusan)
Cc: Mark ZZZ Smith; STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping); [email-masked]
Subject: Re: Question re. RECONFIG in DHCPv6

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 11 May 2015 18:46:52 +0000

I didn't write that text in RFC 4862, so you would have to ask the RFC 4862 authors.

Personally, I want to say that I do not want to comment further on this M/O bits topic. It has been hacked to death many times in the past and you should revisit those discussions (I do NOT want to start another round of debates related to these two bits). Also, this has little to do with the subject of this email which is related to DHCPv6 Reconfigure and not the M/O bits.

- Bernie

-----Original Message-----
From: Lin, Ping (Ping) [mailto:[email-masked]] 
Sent: Monday, May 11, 2015 2:33 PM
To: Bernie Volz (volz); Mudric, Dusan (Dusan); 神明達哉
Cc: Mark ZZZ Smith; STARK, BARBARA H; [email-masked]
Subject: RE: Question re. RECONFIG in DHCPv6

Hi Jinmei, Bernie,

Could I ask for another clarification?  Would you have some information about how much the M and O flags are used currently by end user devices (vs. routers)?  When Appendix C was written, it seems from the text quoted here that implementations of M and O flags were not quite mature as mentioned -- has this changed since that time?

Regards,
Ping Lin
Avaya
________________________________________
From: Bernie Volz (volz) [[email-masked]]
Sent: Monday, May 11, 2015 1:27 PM
To: Mudric, Dusan (Dusan); 神明達哉
Cc: Mark ZZZ Smith; STARK, BARBARA H; Lin, Ping (Ping); [email-masked]
Subject: RE: Question re. RECONFIG in DHCPv6

Read RFC 4862:

-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:[email-masked]]
Sent: Monday, May 11, 2015 1:02 PM
To: 神明達哉
Cc: Mark ZZZ Smith; STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping); [email-masked]
Subject: RE: Question re. RECONFIG in DHCPv6

Dusan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, May 11, 2015 11:46 AM
To: Mudric, Dusan (Dusan)
Cc: Mark ZZZ Smith; STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping); [email-masked]
Subject: Re: Question re. RECONFIG in DHCPv6

--
JINMEI, Tatuya

---

From: "Lin, Ping (Ping)" <[email-masked]>
Date: Mon, 11 May 2015 18:32:58 +0000

Hi Jinmei, Bernie,

Regards,
Ping Lin
Avaya

Read RFC 4862:

-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:[email-masked]]
Sent: Monday, May 11, 2015 1:02 PM
To: 神明達哉
Cc: Mark ZZZ Smith; STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping); [email-masked]
Subject: RE: Question re. RECONFIG in DHCPv6

Dusan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, May 11, 2015 11:46 AM
To: Mudric, Dusan (Dusan)
Cc: Mark ZZZ Smith; STARK, BARBARA H; Bernie Volz (volz); Lin, Ping (Ping); [email-masked]
Subject: Re: Question re. RECONFIG in DHCPv6

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 May 2015 15:29:02 -0700

At Mon, 11 May 2015 18:32:58 +0000,
"Lin, Ping (Ping)" <[email-masked]> wrote:

> Could I ask for another clarification?  Would you have some information about how much the M and O flags are used currently by end user devices (vs. routers)?

I don't, although I suspect it's not used very widely as different
implementations still handle these flags differently.  In any case, as
Bernie pointed out, these seem to be irrelevant to the use of
RECONFIGURE message of DHCPv6.  If you really need a conclusive answer
about the deployment maturity of M/O (if it exists...), it would be
better to flame the question in a separate thread.

--
JINMEI, Tatuya

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 12 May 2015 18:13:50 +0000

Changing configuration attributes on DHCPv6 server and pushing to clients using RECONFIGURE

Based on RFC 3315, there are three reasons to support RECONFIGURE:

-          The need for the immediate configuration updates

-          Server might respond only to the clients willing to accept RECONFIGURE message

-          Server can require that the client supports RECONFIGURE

A detailed analysis is below.

Based on these criteria, does it mean it is mandatory to support dynamic updates of stateful configuration attributes using RECONFIGRE and, consequently, DHCPv6 authentication?

RFC 3315 – RECONFIGURE

====================

When the configuration is changed on DHCPv6 server, the server initiates the update, rfc3315#section-19 "DHCP Server-Initiated Configuration Exchange"<http://tools.ietf.org/html/rfc3315#section-19>:

   A server sends a Reconfigure message to cause a client to initiate

   immediately a Renew/Reply or Information-request/Reply message

   exchange with the server.

Pushing new configurations from DHCPv6 server using RECONFIGURE is important. Without RECONFGIURE the client can get the configuration only after T1 timeout, when it sends SOLICIT.

In addition, RFC3315 allows servers to reject SOLICIT msgs if the clients don’t support RECONFIGURE:

rfc3315#section-17.2.1 "Receipt of Solicit Messages"<http://tools.ietf.org/html/rfc3315#section-17.2.1>

   The server determines the information about the client and its

   location as described in section 11<http://tools.ietf.org/html/rfc3315#section-11> and checks its administrative

   policy about responding to the client.  If the server is not

   permitted to respond to the client, the server discards the Solicit

   message.  For example, if the administrative policy for the server is

   that it may only respond to a client that is willing to accept a

   Reconfigure message, if the client indicates with a Reconfigure

   Accept option in the Solicit message that it will not accept a

   Reconfigure message, the servers discard the Solicit message.

The client only accepts options it asked for in ORO of SOLICIT msg. The server can send Reconfigure Accept option in ADVERTISE to request the reconfigure support:  rfc3315#section-17.2.2 "Creation and Transmission of Advertise Messages"<http://tools.ietf.org/html/rfc3315#section-17.2.2>

   The server includes a Reconfigure Accept option if the server wants

   to require that the client accept Reconfigure messages.

It is not clear in the RFC what the behavior is in this case . Shall the client ignore Reconfigure Accept option sent by DHCPv6 server or it shall support RECONFIGURE message?

Dusan

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, May 11, 2015 10:19 AM
To: STARK, BARBARA H
Cc: Bernie Volz (volz); Lin, Ping (Ping); Mudric, Dusan (Dusan); [email-masked]; Steven B.
Subject: Re: Question re. RECONFIG in DHCPv6

The best characterization of this situation I've heard is from Steven: CPE routers "are supposed to must" implement reconfigure. :-)

I don't know that it would be wise for an operator to rely on reconfigure support in CPEs unless they had stringent acceptance testing and certified the CPEs themselves.

On Mon, May 11, 2015 at 9:20 PM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
It’s required for pretty much every CE router that wants to connect to a “standard” ISP access network. Not just DOCSIS. It’s required in BBF TR-124 and RFC 7084. But according to conversations I’ve had with various telco ISPs, it is about having the capability there just in case it’s needed to forcibly renumber (IA_PD or IA_NA) the CE router. I’m also not aware of any cases where it’s actually been used. But unless there is widespread unhappiness or very vocal singular unhappiness over a renumbering incident, I would never expect to hear of such cases.
Barbara

From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernie Volz (volz)
Sent: Sunday, May 10, 2015 10:01 AM
To: Lin, Ping (Ping)
Cc: Mudric, Dusan (Dusan); [email-masked]<mailto:[email-masked]>
Subject: Re: Question re. RECONFIG in DHCPv6

- Bernie (from iPad)

Thanks very much,
Ping Lin

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=AwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=0jkgXednN3zUusa8-1yTKZFy-6qXZOHJ1TnZUT-wFPw&s=XTrk-0GVD_CkBXNzT78u3iNvRaVFq2vESYf_OGQR4hc&e=>
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=AwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=0jkgXednN3zUusa8-1yTKZFy-6qXZOHJ1TnZUT-wFPw&s=XTrk-0GVD_CkBXNzT78u3iNvRaVFq2vESYf_OGQR4hc&e=>
--------------------------------------------------------------------

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 12 May 2015 22:29:21 +0000

I am not sure why you are sending these kinds of questions and to ipv6 (6man) wg when RFC 3315 is a product of the dhc wg.

There is no hard requirement in RFC 3315 to implement Reconfigure from a client or server perspective.

Sure, there could be networks where a server may enforce the requirement that Reconfigure is supported by a client (i.e., Reconfigure Accept option must be sent by client) and a client that does not support it would thus not be serviced (since the server’s policy says to ignore such clients). But such a restriction, except for specific environments where it may be mandated, would not likely be wise since it may prevent many clients from obtaining an address.

As I already mentioned in another threads, the DHC WG is working on a RFC 3315bis document and we are discussing removing much related to Authentication; though the Reconfigure Key Authentication Protocol would remain. And devices that want to support Reconfigure should use that form of authentication. See Section 21.5 of RFC 3315.

-          Bernie

From: Mudric, Dusan (Dusan) [mailto:[email-masked]]
Sent: Tuesday, May 12, 2015 2:14 PM
To: Lorenzo Colitti; STARK, BARBARA H
Cc: Bernie Volz (volz); Lin, Ping (Ping); [email-masked]; Steven B.
Subject: RE: Question re. RECONFIG in DHCPv6

RFC 3315 – RECONFIGURE

====================

Dusan

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, May 11, 2015 10:19 AM
To: STARK, BARBARA H
Cc: Bernie Volz (volz); Lin, Ping (Ping); Mudric, Dusan (Dusan); [email-masked]<mailto:[email-masked]>; Steven B.
Subject: Re: Question re. RECONFIG in DHCPv6

- Bernie (from iPad)

Thanks very much,
Ping Lin