IPv6-Only Preferred Option for DHCPv4
draft-ietf-dhc-v6only-08

[Ballot comment]
Hi,

Thank you for your work on this document, I found it easy to read.

I have a few minor comments/nits that may help improve this document:

Minor comments:

Would it be helpful for the the term dual-stack need to be defined (or the definition imported)?

    6.  Security Considerations

    ... could be considered a security feature.

Perhaps better for the security ADs to comment, but I wasn't sure whether this is so much a security feature, or instead just reducing the possible attack surface.

Nits:
"such approach" => "such an approach"
"IPv6-Only" => "IPv6-only"? (for consistency with other terms)
"operate in IPv6-only network" => "operate in an IPv6-only network"
"Strictly speaking IPv6-only ... " => "More precisely, IPv6-only ..."
" ... declaring a host or (strictly speaking, a host interface) IPv6-only capable ..." =>  "... declaring a host (technically, a host interface) as IPv6-only capable ..."
"Hypothetically it" => "Hypothetically, it"
"in IPv6-only environment" => "in an IPv6-only environment"
"via NAT64 service" => "via a NAT64 service"

[Ballot comment]
A few editorial nits:

-- Section 3.3.1.  Editorial. “w/o” --> “without”

-- Section 3.3.1.  Editorial.
OLD
Therefore the
  following update is proposed to Section 2.3 of [RFC2563]"
NEW
Therefore, the following update is made to Section 2.3 of [RFC2563].

-- Section 3.4  Please review the SECDIR review for revised text on V6ONLY_WAIT (and thank you Russ Housley for doing the review)

[Ballot comment]
In Sections 3.2 and 3.3, there are a lot of SHOULDs and a couple of SHOULD NOTs, but no guidance about what one might do instead of what they say, or when it might be appropriate to deviate from the SHOULD, or what the impact of doing so might be.  Since you're providing a choice, I suggest fully developing the choice.

And a few nits:

Abstract:

* "... supports an IPv6-only mode and willing to ..." -- s/willing/is willing/

Section 1.2:

* "This document currently implies that ..." -- Is this document going to imply something else later?

* "a deployment scenario when ..." -- s/when/where/

[Ballot comment]
Thank you for this document - it is well written and should help significantly with address exhaustion (and, potentially, knowing when we are done :-))

Also, thanks to Sheng for the OpsDir review.

[Ballot comment]
I have several comments that I believe are borderline DISCUSS-worthy because collectively they result in the specification not being clear.  However, I have decided to ballot No Objection because none of them individually raise to the same level.


(1) From the Introduction:

  If hosts were to delay requesting IPv4 until IPv6 reachability is
  confirmed, that would penalize IPv4-only and dual-stack networks, which
  does not seem practical.

The mechanism specified may delay the IPv4 process for at least MIN_V6ONLY_WAIT; 5 minutes is a very long time, and it seems longer than "until IPv6 reachability is confirmed".  I would like to see the document include operational considerations related to the practicality of implementing the new functionality.  Given that the operation (in §3.2) is only recommended ("SHOULD stop the DHCPv4 configuration process for at least V6ONLY_WAIT"), the considerations should include guidance on the tradeoffs, including initial setup.


(2) §3.2: What is a "network attachment event"?  Is that defined somewhere?  I looked at rfc2131 but didn't find the definition there.  A "network disconnection event" is mentioned later...same question.  Both sound like physical events to me (connect/disconnect).


(3) §3.2: What is the difference between these two actions: "the client...SHOULD stop the DHCPv4 configuration process or disable IPv4 stack completely"?  Are they defined anywhere?  I have an intuition of what the actions mean, but given that they are attached to normative language, it would be ideal if the operation was clear to everyone.


(4) [nit] s/MAY configure IPv4 link-local address/MAY configure an IPv4 link-local address


(5) [nit] s/specify V6ONLY_WAIT timer/specify the V6ONLY_WAIT timer


(6) §3.3: The first paragraph makes configuration recommended/optional ("SHOULD be able to configure...MAY have a configuration option"), but the second paragraph requires an action based on that configuration ("MUST NOT include...if the YIADDR...does not belong to a pool configured...").  First of all, I believe these a Normative conflict: if the configuration is recommended/optional, then a required action can't rely on it.

Also, if the pools can't be configured, then it seems that the IPv6-only Preferred option would never be included.  Is that the expected behavior?  It seems to me that even if individual pools can't be configured, the use of the option could still be useful for all pools.


(7) §3.3: "The server SHOULD NOT assign an address for the pool.  Instead it
SHOULD return 0.0.0.0 as the offered address.  Alternatively, the server MAY
include an available IPv4 address from the pool into the DHCPOFFER as per
recommendations in [RFC2131]."

What are the conditions under which the server would select to assign an address?  The initial two sentences recommend not doing it.


(8) §3.3: "...the server MAY include an available IPv4 address from the pool
into the DHCPOFFER as per recommendations in [RFC2131].  In this case, the
offered address MUST be a valid address that is not committed to any other
client.  Because the client is not expected ever to request this address, the
server SHOULD NOT reserve the address and SHOULD NOT verify its uniqueness."

rfc2131 already contains a similar recommendation as "the server SHOULD NOT reserve", but without using normative language ("Servers need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client."). It seems to me that the recommendations from rfc2131 already cover the reservation case and don't need to be repeated.

OTOH, "SHOULD NOT verify its uniqueness" seems to contradict what rfc2131 recommends: "When allocating a new address, servers SHOULD check that the offered network address is not already in use".  I'm assuming that being unique and "not already in use" are equivalent.


(9) §3.3.1: [nit] s/on IPv6-mostly network/on an IPv6-mostly network

[Ballot comment]
[[ suggestions ]]

[ section 5 ]

* Consider redoing the table to instead match the columns in the registry.

  Perhaps:

      Tag: TBD
      Name: IPv6-only Preferred option
      Data Length: 4
      Meaning: IPv6-only Preferred option
      Reference: [THIS-RFC]


[[ nits ]]

[ section 3.2 ]

* Perhaps s/per interface enabled basis/per enabled interface basis/

[ section 3.3 ]

* s/assign an address for the pool/assign an address from the pool/

[Ballot comment]
Thank you for addressing Martin's point already!

Abstract

  This document specifies a DHCPv4 option to indicate that a host
  supports an IPv6-only mode and willing to forgo obtaining an IPv4
  address if the network provides IPv6 connectivity.  It also updates

nit: "is willing"

  RFC2563 to specify the DHCPv4 server behavior when the server
  receives a DHCPDISCOVER not containing the Auto-Configure option.

I know Abstracts should be concise, but perhaps we should pay the few
extra words and note that this is limited to just the v6only case -- the
current text makes it sound like this is some completely orthogonal
thing.

Section 1.2

I worry a little bit about how we are sometimes assuming that
IPv6-only includes NAT64+DNS64, and sometimes not, but the current text
about "this document currently implies" is probably enough to clarify
things.

Section 2

Thank you for acknowledging the new DoS attack vector :)

  Being a client/server protocol, DHCPv4 allows IPv4 to be selectively
  disabled on a per-host basis on a given network segment.  Coexistence
  of IPv6-only, dual-stack and even IPv4-only hosts on the same LAN
  would not only allow network administrators to preserve scarce IPv4
  addresses but would also drastically simplify incremental deployment
  of IPv6-only networks, positively impacting IPv6 adoption.

It seems that the cost of achieving this benefit is that the v4 stack on
the network equipment needs to know about the v6 capabilities of the
network.  When the same hardware provides the v4 and v6 service (would
that ever not be the case?), this is presumably no great burden, but it
does perhaps present an abstraction barrier violation.

Section 3.1

Am I reading this wrong, or do we only specify the semantics of the
"Value" field for the server-to-client direction?  Should the client
just set it to all-zeros in messages it generates?

Section 3.2

Is the "for at least  seconds or until a network attachment event
happens" common enough in DHCP documents that the "whichever comes
sooner" is implicit?

  to that value.  Otherwise, the client SHOULD set the V6ONLY_WAIT
  timer to MIN_V6ONLY_WAIT.  The client SHOULD stop the DHCPv4
  configuration process for at least V6ONLY_WAIT seconds or until a
  network attachment event happens.  The host MAY disable the IPv4
  stack completely for V6ONLY_WAIT seconds or until the network
  disconnection event happens.

I'm not entirely sure if there are some subtle semantic differences
between "network attachment event" and "network disconnection event"
such that the former applies to the "stop the DHCPv4 configuration
process" cases but the latter applies to "disabled IPv5 stack
completely" cases.  (We only talk about "network disconnection event" in
the following paragraph, as applying to both pausing configuaration and
disabling the stack entirely.)

Section 3.3.1

  contain the Auto-Configure option, it is not answered."  Such
  behavior would be undesirable for clients supporting the IPv6-Only
  Preferred option w/o supporting the Auto-Configure option as they
  would not receive any response from the server and would keep asking,
  instead of disabling DHCPv4 for V6ONLY_WAIT seconds.  Therefore the

Should I infer that the "V6ONLY_WAIT seconds" is modified by "or until a
network attachment event occurs"?

Section 3.4

  V6ONLY_WAIT    The minimum time the client SHOULD stop the DHCPv4
                  configuration process for. The value MUST NOT be less
                  than MIN_V6ONLY_WAIT seconds. Default: 1800 seconds

nit(?): is this really a "minimum" time?  The previous discussion
is inconsistent about using "at least V6ONLY_WAIT seconds" or just "for
V6ONLY_WAIT seconds", which might be worth tightening up.

Section 6

  An attacker might send a spoofed DHCPOFFER containing IPv6-only
  Preferred option with the value field set to 0xffffffff, disabling
  DHCPv4 on clients supporting the option.  If the network is IPv4-only

I don't remember us assigning special semantics to 0xffffffff, so maybe
we should just say "value field set to a large number, such as
0xffffffff, effectively disabling DHCPv4".

I guess this attack also only works if the client ends up picking that
offer (right?), so we might mention that the attacker needs to make the
rest of the offer look compelling enough for the client to pick it
anyway, even in the presence of other (legitimate) offers.

Section 8.1

We seem to only use RFC 4861 in the definition of RA, which itself seems
to be unused.

Section 8.2

It's a little surprising to see RFC 6146 listed as only an informational
reference, given how heavily we rely on/expect NAT64 to be available
alongside this mechanism.

[Ballot comment]
Thanks for addressing my DISCUSS on spoofed long timeouts in the github version.

Original comments, since addressed:

This seems like an important stepping stone to v6 adoption, so thanks.

Sec 3.1 In client-generated messages, what is in the "Value field"? I presume this is one of those "client MUST set to zero and server MUST ignore" cases?

Sec 3.3
"If the client then
  issues a DHCPREQUEST for the address, the server MUST process it per
  [RFC2131], including replying with a DHCPACK for the address if in
  the meantime it has not been committed to another client."

What if it HAS been committed to another client? What then?

[Ballot discuss]
Not so much an objection, but a question:

What would happen if, in response to a DHCPDISCOVER with the IPv6-only offer, an attacker spoofed a DHCPOFFER with this option and a V6ONLY_WAIT value of UINT32_MAX, when in fact there was no NAT64, or v6 capability, at all? Would the very long timeout amplify existing DoS attacks on DHCP?

[Ballot comment]
This seems like an important stepping stone to v6 adoption, so thanks.

Sec 3.1 In client-generated messages, what is in the "Value field"? I presume this is one of those "client MUST set to zero and server MUST ignore" cases?

Sec 3.3
"If the client then
  issues a DHCPREQUEST for the address, the server MUST process it per
  [RFC2131], including replying with a DHCPACK for the address if in
  the meantime it has not been committed to another client."

What if it HAS been committed to another client? What then?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dhc-v6only-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BOOTP Vendor Extensions and DHCP Options registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

a single, new registration is to be made as follows:

Tag: [ 108 Requested ]
Name: IPv6-only Preferred option
Data Length: 4
Meaning: IPv6-only Preferred option
Reference: [ RFC-to-be ]

IANA notes that a temporary registration for IPv6-only Preferred via the early allocation process has been made.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

The following Last Call announcement was sent out (ends 2020-07-02):

From: The IESG
To: IETF-Announce
CC: Bernie Volz , dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-v6only@ietf.org, dhcwg@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6-Only-Preferred Option for DHCPv4) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'IPv6-Only-Preferred Option for DHCPv4'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-07-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a DHCPv4 option to indicate that a host
  supports an IPv6-only mode and willing to forgo obtaining an IPv4
  address if the network provides IPv6 connectivity.  It also updates
  RFC2563 to specify the DHCPv4 server behavior when the server
  receives a DHCPDISCOVER not containing the Auto-Configure option.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard (i.e., on the standards track).

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies a new DHCPv4 option that a host can use to indicate to the
DHCPv4 server that it can operate in IPv6 only mode (via an appropriate transition
technology) and thus does not require an IPv4 address. The DHCPv4 server can
therefore bypass allocating an IPv4 address.

Working Group Summary:

While the document was a product of the DHC WG, v6ops, and 6man, were also
involved in the initial discussion and refinement of the work. The document progressed
relatively quickly, though there were several issues debated during its development.

Document Quality:

There was significant interest from both client and server software implementers.
While I am not aware of a prototype implementation, the result does closely follow
the behavior of many other DHCP actions.

Personnel:

Document Shepherd: Bernie Volz (DHC WG co-chair)
Responsible Area Director: Éric Vynck

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed every revision of the document and followed its development
to assure it addressed the issues and comments raised. I have reviewed the
final version of the document and feel it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. I think the document has had good review, both during its development as
during WGLC.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. As it is a product of the DHC WG, the option definition and DHCP
client and server behavior were reviewed by the WG and "DHCP experts".

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns or issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, each author has confirmed this via email to me.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Not to my or the IETF knowledge at the present time (6/1/2020).

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It presents strong consensus. The WG discussed and resolved the significant
areas of differences (mainly around whether the server MUST NOT, SHOULD NOT,
MAY NOT assign an address for the Offer) during the development of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There are no formal reviews (IANA will do a DHCP Expert review of the requested DHCP option,
but it follows the normal DHCP option guidelines).

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. All are RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, it makes a modification to RFC 2563 and is reflected in the header - "Updates: 2563" - and mentioned in Abstract and Introduction sections.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA section is correct and clear.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

There were none as none is appropriate.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

There is no YANG model.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard (i.e., on the standards track).

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies a new DHCPv4 option that a host can use to indicate to the
DHCPv4 server that it can operate in IPv6 only mode (via an appropriate transition
technology) and thus does not require an IPv4 address. The DHCPv4 server can
therefore bypass allocating an IPv4 address.

Working Group Summary:

While the document was a product of the DHC WG, v6ops, and 6man, were also
involved in the initial discussion and refinement of the work. The document progressed
relatively quickly, though there were several issues debated during its development.

Document Quality:

There was significant interest from both client and server software implementers.
While I am not aware of a prototype implementation, the result does closely follow
the behavior of many other DHCP actions.

Personnel:

Document Shepherd: Bernie Volz (DHC WG co-chair)
Responsible Area Director: Éric Vynck

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed every revision of the document and followed its development
to assure it addressed the issues and comments raised. I have reviewed the
final version of the document and feel it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. I think the document has had good review, both during its development as
during WGLC.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. As it is a product of the DHC WG, the option definition and DHCP
client and server behavior were reviewed by the WG and "DHCP experts".

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns or issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, each author has confirmed this via email to me.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Not to my or the IETF knowledge at the present time (6/1/2020).

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It presents strong consensus. The WG discussed and resolved the significant
areas of differences (mainly around whether the server MUST NOT, SHOULD NOT,
MAY NOT assign an address for the Offer) during the development of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There are no formal reviews (IANA will do a DHCP Expert review of the requested DHCP option,
but it follows the normal DHCP option guidelines).

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. All are RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, it makes a modification to RFC 2563 and is reflected in the header - "Updates: 2563" - and mentioned in Abstract and Introduction sections.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA section is correct and clear.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

There were none as none is appropriate.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

There is no YANG model.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard (i.e., on the standards track).

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies a new DHCPv4 option that a host can use to indicate to the
DHCPv4 server that it can operate in IPv6 only mode (via an appropriate transition
technology) and thus does not require an IPv4 address. The DHCPv4 server can
therefore bypass allocating an IPv4 address.

Working Group Summary:

While the document was a product of the DHC WG, the v6ops (and 6man) were also
involved in the initial discussion and refinement of the work. The document progressed
relatively quickly, though there were several issues debated in its development.

Document Quality:

There was significant interest from both client and server software implementers.
While I am not aware of a prototype implementation, the result does closely follow
the behavior of many other DHCP actions.

Personnel:

Document Shepherd: Bernie Volz (DHC WG co-chair)
Responsible Area Director: Éric Vynck

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed pretty much every revision of the document and followed its
development to assure it addressed the issues and comments raised. I have
reviewed the final version of the document and feel it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. I think the document has had good review, but during its development as
well as the WGLC revision.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. As it is a product of the DHC WG, the option definition and DHCP
client and server behavior were reviewed by the WG and "DHCP experts".

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns or issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

XXX - PENDING!

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Not at the present time.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It presents strong consensus. The WG discussed and resolved the significant
areas of differences (mainly around whether the server MUST NOT, SHOULD NOT,
MAY NOT assign an address for the Offer) during the development of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There are no formal reviews (IANA will do a DHCP Expert review of the requested DHCP option,
but it follows the normal DHCP option guidelines).

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. All are RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, it makes a modification to RFC 2563 and is reflected in the header - "Updates: 2563".

XXX - No mention of RFC 2563 in the Abstract and Introduction sections.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA section is correct and clear.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

There were none as none is appropriate.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

There is no YANG model.

Initiated WGLC on 5/11/2020:

Hello:

The authors have requested a WGLC for draft-ietf-dhc-v6only (IPv6-Only-Preferred Option for DHCP). This starts a 2 week WGLC for this document.

Please review this document and provide your comments and whether you support this document moving forward or not by May 25th, 2020 (23:59 UTC).

Please see https://tools.ietf.org/html/draft-ietf-dhc-v6only. This is a Standards Track document.

There are no IPR notices filed against this work (as of this writing).

Thank you!

- Tomek & Bernie