IPv6 Node Requirements
draft-ietf-6man-rfc6434-bis-09

[Ballot comment]
Thanks for the easy DISCUSS resolution :)
Original ballot comment preserved below.

Thanks for doing this work; it's quite helpful to have all this information assembled in one place!

I have a few comments, broken out by section.

Section 1

]draft-thomson-postel-was-wrong and some discussion I've seen surrounding it has made me
wonder whether we are best served by continuing to "blindly cite" Postel's Principle.  The principles
it espouses do remain true in some aspects, but there seems to be a tradeoff against other concerns
as well.

Section 5.3

  A host MAY impose a limit on the maximum number of non-padding
  options allowed in a destination options and hop-by-hop extension
  headers. [...]

nit: is there a singular/plural mismatch here?

Section 13

Why is the phrase "SSL VPN" preferable to the phrase "TLS VPN"?
SSL is deprecated; the IETF protocol is TLS.

Section 15

  If an IPv6 node is concerned about the impact of IPv6 message power
  consumption, it SHOULD want to implement the recommendations in
  [RFC7772].

Do we really need to assign motive to IPv6 nodes?

[Ballot discuss]
This is a pretty minor point and should be easy to resolve, but there seems to be an internal inconsistency
that is introduced with the new section on Constrained Devices.  In particular, Section 1.1 has a short
note:

  This document assumes that all IPv6 nodes meet the minimum
  requirements specified here.

but Section 15 says something a bit different:

  [...] While the requirements of this
  document are RECOMMENDED for all nodes, including constrained nodes,
  compromises may need to be made in certain cases.

[Ballot comment]
Thanks for doing this work; it's quite helpful to have all this information assembled in one place!

I have a few comments, broken out by section.

Section 1

]draft-thomson-postel-was-wrong and some discussion I've seen surrounding it has made me
wonder whether we are best served by continuing to "blindly cite" Postel's Principle.  The principles
it espouses do remain true in some aspects, but there seems to be a tradeoff against other concerns
as well.

Section 5.3

  A host MAY impose a limit on the maximum number of non-padding
  options allowed in a destination options and hop-by-hop extension
  headers. [...]

nit: is there a singular/plural mismatch here?

Section 13

Why is the phrase "SSL VPN" preferable to the phrase "TLS VPN"?
SSL is deprecated; the IETF protocol is TLS.

Section 15

  If an IPv6 node is concerned about the impact of IPv6 message power
  consumption, it SHOULD want to implement the recommendations in
  [RFC7772].

Do we really need to assign motive to IPv6 nodes?

[Ballot comment]
Thank you for this - it is a large amount of work!

I had a question, and a few nits.

Question:
"In core networks dominated by routers, Redirects are typically disabled.  The sending of Redirects SHOULD be disabled by default on backbone routers.  They MAY be enabled by default on routers intended to support hosts on edge networks."
The SHOULD here concerns me, but only because a "backbone router" isn't really defined. I know one when I see one, but if I'm an implementer I don't really know if the box is a backbone router or not (todays backbone gear becomes tomorrow's edge gear, and next week's boat anchor). I have no suggestions for how to address this (and feel free to ignore it!)

Nits (I'm sure the RFC Ed would have caught them, but doesn't hurt to make their lives easier)
Section 5.3.  Protecting a node from excessive EH options
"If a packet is received and the number of destination or hop-by-hop optines exceeds the limit, then the packet should be silently discarded."
options

Section  5.4.  Neighbor Discovery for IPv6 - RFC 4861
"  [RFC7559] discusses packet loss resliency for Router Solicitations,"
resiliency

Section 5.7.1.  Path MTU Discovery - RFC 8201
" For example, this will result in connections that
  complete the TCP three- way handshake"
three-way.

[Ballot comment]
Two comments that I would really like to see addressed before publication, however, I don't think they would warrant a discuss:

1) I agree with Adam comments but I would like to say that I am even more concerned about the use of normative language. Especially, sections 5.2 and 5.3 (maybe others; did check further) seems to be word-by-word copies of the text in RFC8200, including use of normative language. This doesn't seem to be appropriate as it would mean that if you would ever want to update RFC8200, you also have to update this RFC. Please consider re-wording these section appropriately to make sure that only RFC8200 is defining the IPv6 protocol normatively and this document only points at the right positions in RFC8200 and provide additional discussion/background where needed.

2) sec 5.12:
"Nodes that may be deployed in environments where they would benefit
  from such early congestion notification SHOULD implement [RFC3168].
  In such cases, the updates presented in [RFC8311] may also be
  relevant."
Thanks for pointer to ECN, however, this advise seems quite misleading.  First I guess the more useful reference here would be RFC8087. But more important, ECN can/should only be used if there is a feedback mechanism in the transport layer, therefore using ECN is a transport layer decision and the only thing the IP layer at the end host can do is to make sure that there is an interface for the upper layer to set the bits. I didn't make this point a discussion because the sentence is not entirely wrong (just not very helpful either). But I really think this sentence needs clarification! (Also thanks to Magnus who pointed at this sentences already in his TSV-ART review!)

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4050


I see you are using a mix of lower case and capital normative
language. Do you want to converge that?


COMMENTS
S 1.2.
>      we have the following definitions:
> 
>      IPv6 node  - a device that implements IPv6.
>      IPv6 router - a node that forwards IPv6 packets not explicitly
>                    addressed to itself.
>      IPv6 host  - any node that is not a router.

Nit: any IPv6 node.


S 5.1.
>      field as defined in the IPv6 Flow Label specification [RFC6437].
>      Forwarding nodes such as routers and load distributors MUST NOT
>      depend only on Flow Label values being uniformly distributed.  It is
>      RECOMMENDED that source hosts support the flow label by setting the
>      Flow Label field for all packets of a given flow to the same value
>      chosen from an approximation to a discrete uniform distribution.

Is there a reason you are using "approximation" here?


S 5.2.
>      to the action to be taken when a Next Header value in the current
>      header is not recognized by a node, that action applies whether the
>      value is an unrecognized Extension Header or an unrecognized upper
>      layer protocol (ULP).
> 
>      An IPv6 node MUST be able to process these headers.  An exception is

"these headers" == "extension headers"? I guess it's clear in context
from the title...


S 5.3.
>      A host MAY impose a limit on the maximum length of destination
>      options or hop-by-hop options extension header.  This value should be
>      configurable and the default is to accept options of any length.  If
>      a packet is received and the length of destination or hop-by-hop
>      options extension header exceeds the length limit, then the packet
>      should be silently discarded.

This is a WG decision, but experience with other protocols suggests
that language like this has the implicit effect of banning anything
outside these limtis.


S 5.7.2.
> 
>  5.7.2.  Minimum MTU considerations
> 
>      While an IPv6 link MTU can be set to 1280 bytes, it is recommended
>      that for IPv6 UDP in particular, which includes DNS operation, the
>      sender use a large MTU if they can, in order to avoid gratuitous

Can you be clearer about "large"?


S 5.12.
>      receiver of the packet echoes the congestion indication to the
>      sender, which can then reduce its transmission rate as if it detected
>      a dropped packet.
> 
>      Nodes that may be deployed in environments where they would benefit
>      from such early congestion notification SHOULD implement [RFC3168].

How would I know if I have such a node?


S 13.
>      key management approach of IKE.  This document updates that
>      recommendation by making support of the IPsec Architecture [RFC4301]
>      a SHOULD for all IPv6 nodes.  Note that the IPsec Architecture
>      requires (e.g., Section 4.5 of RFC 4301) the implementation of both
>      manual and automatic key management.  Currently, the default
>      automated key management protocol to implement is IKEv2 [RFC7296].

What does "default" mean in this case?

[Ballot comment]
I support Adam's comments concerning the use of normative keywords. In particular this sentence in 6.3 is in need of a normative "RECOMMENDED" I think:

"It is
  recommended, as described in [RFC8064], that unless there is a
  specific requirement for MAC addresses to be embedded in an IID,
  nodes follow the procedure in [RFC7217] to generate SLAAC-based
  addresses, rather than using [RFC4862]."

In Section 9, this sentence seems unlikely to remain up-to-date for the life of this document: "The IETF dnssd WG is defining solutions for DNS-based service
  discovery in multi-link networks."

[Ballot comment]
(I mostly reviewed the diff from RFC 6434)

- I echo Adam's comments.

- There's a normative downref to RFC 7739, which was not mentioned in the LC announcement nor is it in the downref registry.

§5.3: Do the "MAY limit" statements added in this section imply corresponding "MUST/SHOULD not exceed" requirements for the sender? Otherwise, it seems like a potential interop issue.

[Ballot comment]
Thanks for the work everyone put into updating this document. I have a couple of
minor comments.

---------------------------------------------------------------------------

§2:
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please update this to the boilerplate in RFC 8174.

The document's use of capitalized versus non-capitalized versions of these terms
appears to be inconsistent. In many cases, lowercase forms appear to be used
when reiterating behavior that has been normatively specified in other
documents, which seems correct. In other places, the selection of uppercase
keywords appears to be fairly arbitrary (e.g., §5.3 uses a mix of "MAY" and
"should"). Consider doing a pass to ensure that the use of normative language is
consistent.

---------------------------------------------------------------------------

With the removal of its final paragraph, §8.4 appears to only describe general
principles, and doesn't seem to contain any actionable requirements anymore. As
an implementor, I don't know what I would do to conform with its contents.
Consider adding concrete implementor guidance, or removing the section.

[Ballot comment]
Thanks for doing this update. I have some comments, but the only one that's more than editorial is on RFC 8311.

Do the right thing, of course.

I'm not understanding

  A host MAY limit the number of consecutive PAD1 options in
  destination options or hop-by-hop options to seven.  In this case, if
  the more than seven consecutive PAD1 options are present the packet
  should be silently discarded.  The rationale is that if padding of
  eight or more bytes is required than the PADN option should be used.

Isn't this saying that a path might work, or might fail silently, or might work even if the packet should have been discarded (I note the lower-case "should", without a reference to RFC 8174, which doesn't help)? It seems like "MAY limit" is significantly more permissive than "should be silently discarded", turning Jon Postel's Robustness Principle on its head. I'd either expect "SHOULD limit" or "may/MAY be silently discarded", for starters.

I'm sure that's for a good reason, but perhaps it's worth explaining it in the text. And I have the same confusion about

  A host MAY disallow unknown options in destination options or hop-by-
  hop options.  This should be configurable where the default is to
  accept unknown options and process them per [RFC8200].  If a packet
  with unknown options is received and the host is configured to
  disallow them, then the packet should be silently discarded.

A nit: "optines" for "options".

A nit: "resliency" for "resiliency".

I'm not sure that RFC 4821 would qualify as an extension to RFC 8201 in this text - the functionality is similar, but the mechanism is different by design.

  An extension to Path MTU Discovery defined in RFC 8201 can be found
  in [RFC4821], which defines a method for Packetization Layer Path MTU
  Discovery (PLPMTUD) designed for use over paths where delivery of
  ICMPv6 messages to a host is not assured.

Perhaps "An alternative to Path MTU Discovery defined in RFC 8201 can be found
  in [RFC4821] ... "?

Thanks for including the reference to RFC 8311 in this text.

  Nodes that may be deployed in environments where they would benefit
  from such early congestion notification SHOULD implement [RFC3168].
  In such cases, the updates presented in [RFC8311] may also be
  relevant.

It may not be possible to do anything about this, but "may also be relevant" seems weaker than I would have hoped. We were able to reclaim ECT(1) for experimentation because we couldn't find more than a trace of evidence that anyone on the Internet was using it, and this text doesn't quite discourage someone from starting to use it now, which would prevent us from doing ECN experiments. But do the right thing, of course.

This text

  Thus it is possible for 3rd
  party devices such nodes communicate with to track the activities of
  the node as it moves around the network.

wasn't easy for me to parse. Perhaps something like

  Thus it is possible for 3rd
  party devices to track the activities of a node they
  communicate with, as that node moves around the network.

would be clearer?

"Recently" may have been overtaken by events in this text.

  Recently, additional work has been done to support mobility in mixed-
  mode IPv4 and IPv6 networks [RFC5555].

I think

  If an IPv6 node is concerned about the impact of IPv6 message power
  consumption, it SHOULD want to implement the recommendations in
  [RFC7772].

might be clearer as

  If IPv6 implementers are concerned about the impact of IPv6 message power
  consumption in an IPv6 node, they SHOULD implement the recommendations in
  [RFC7772].

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

The IANA Functions Operator has reviewed draft-ietf-6man-rfc6434-bis-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-06-25):

From: The IESG
To: IETF-Announce
CC: ipv6@ietf.org, bob.hinden@gmail.com, Robert Hinden , draft-ietf-6man-rfc6434-bis@ietf.org, suresh@kaloom.com, 6man-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv6 Node Requirements) to Best Current Practice


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'IPv6 Node Requirements'
  as Best Current Practice

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
ietf@ietf.org mailing lists by 2018-06-25. 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 defines requirements for IPv6 nodes.  It is expected
  that IPv6 will be deployed in a wide range of devices and situations.
  Specifying the requirements for IPv6 nodes allows IPv6 to function
  well and interoperate in a large number of situations and
  deployments.

  This document obsoletes RFC 6434, and in turn RFC 4294.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6106: IPv6 Router Advertisement Options for DNS Configuration (Proposed Standard - IETF stream)
    rfc6775: Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (Proposed Standard - IETF stream)
    rfc7112: Implications of Oversized IPv6 Header Chains (Proposed Standard - IETF stream)
    rfc4301: Security Architecture for the Internet Protocol (Proposed Standard - IETF stream)
    rfc7048: Neighbor Unreachability Detection Is Too Impatient (Proposed Standard - IETF stream)
    rfc4303: IP Encapsulating Security Payload (ESP) (Proposed Standard - IETF stream)
    rfc7045: Transmission and Processing of IPv6 Extension Headers (Proposed Standard - IETF stream)
    rfc3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 (Proposed Standard - IETF stream)
    rfc6762: Multicast DNS (Proposed Standard - IETF stream)
    rfc5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (Proposed Standard - IETF stream)
    rfc8221: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) (Proposed Standard - IETF stream)
    rfc6564: A Uniform Format for IPv6 Extension Headers (Proposed Standard - IETF stream)
    rfc8106: IPv6 Router Advertisement Options for DNS Configuration (Proposed Standard - IETF stream)
    rfc8028: First-Hop Router Selection by Hosts in a Multi-Prefix Network (Proposed Standard - IETF stream)
    rfc5790: Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols (Proposed Standard - IETF stream)
    rfc8021: Generation of IPv6 Atomic Fragments Considered Harmful (Informational - IETF stream)
    rfc5095: Deprecation of Type 0 Routing Headers in IPv6 (Proposed Standard - IETF stream)
    rfc6241: Network Configuration Protocol (NETCONF) (Proposed Standard - IETF stream)
    rfc4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Draft Standard - IETF stream)
    rfc4861: Neighbor Discovery for IP version 6 (IPv6) (Draft Standard - IETF stream)
    rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - IETF stream)
    rfc4213: Basic Transition Mechanisms for IPv6 Hosts and Routers (Proposed Standard - IETF stream)
    rfc8247: Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) (Proposed Standard - IETF stream)
    rfc4607: Source-Specific Multicast for IP (Proposed Standard - IETF stream)
    rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP (Proposed Standard - IETF stream)
    rfc5175: IPv6 Router Advertisement Flags Option (Proposed Standard - IETF stream)
    rfc6946: Processing of IPv6 "Atomic" Fragments (Proposed Standard - IETF stream)
    rfc6437: IPv6 Flow Label Specification (Proposed Standard - IETF stream)
    rfc6434: IPv6 Node Requirements (Informational - IETF stream)
    rfc8311: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation (Proposed Standard - IETF stream)
    rfc7559: Packet-Loss Resiliency for Router Solicitations (Proposed Standard - IETF stream)
    rfc4293: Management Information Base for the Internet Protocol (IP) (Proposed Standard - IETF stream)
    rfc4294: IPv6 Node Requirements (Informational - IETF stream)
    rfc5722: Handling of Overlapping IPv6 Fragments (Proposed Standard - IETF stream)
    rfc4292: IP Forwarding Table MIB (Proposed Standard - IETF stream)
    rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream)
    rfc6724: Default Address Selection for Internet Protocol Version 6 (IPv6) (Proposed Standard - IETF stream)
    rfc8343: A YANG Data Model for Interface Management (Proposed Standard - IETF stream)
    rfc8064: Recommendation on Stable IPv6 Interface Identifiers (Proposed Standard - IETF stream)
    rfc7527: Enhanced Duplicate Address Detection (Proposed Standard - IETF stream)
    rfc5453: Reserved IPv6 Interface Identifiers (Proposed Standard - IETF stream)
    rfc2675: IPv6 Jumbograms (Proposed Standard - IETF stream)
    rfc4033: DNS Security Introduction and Requirements (Proposed Standard - IETF stream)
    rfc7739: Security Implications of Predictable Fragment Identification Values (Informational - IETF stream)
    rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - IETF stream)
    rfc3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - IETF stream)
    rfc6763: DNS-Based Service Discovery (Proposed Standard - IETF stream)
    rfc3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Proposed Standard - IETF stream)
    rfc7217: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (Proposed Standard - IETF stream)
    rfc4311: IPv6 Host-to-Router Load Sharing (Proposed Standard - IETF stream)
    rfc8344: A YANG Data Model for IP Management (Proposed Standard - IETF stream)
    rfc8040: RESTCONF Protocol (Proposed Standard - IETF stream)
    rfc2863: The Interfaces Group MIB (Draft Standard - IETF stream)
    rfc2711: IPv6 Router Alert Option (Proposed Standard - IETF stream)
    rfc2710: Multicast Listener Discovery (MLD) for IPv6 (Proposed Standard - IETF stream)

Title          : IPv6 Node Requirements
Authors        : Tim Chown
                  John Loughney
                  Timothy Winters
Filename        : draft-ietf-6man-rfc6434-bis-08.txt
Pages          : 40
Date            : 2018-03-20


(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?

  Best Current Practice (BCP)

  This is appropriate as this document is describing the requirements
  for all IPv6 nodes.  It obsoletes the previous version of this
  document RFC6434.
 

(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 defines requirements for IPv6 nodes.  It is expected
  that IPv6 will be deployed in a wide range of devices and situations.
  Specifying the requirements for IPv6 nodes allows IPv6 to function
  well and interoperate in a large number of situations and
  deployments.


Working Group Summary:

  There is support for this document in the 6MAN working group.  There
  is a consensus to advance this document.

Document Quality:

  The quality of the document is very good, it has received adequate
  review in the working group on the mailing list and at a series of
  6man sessions at IETF meetings.  The changes from the previous
  versions have been described on the mailing list and at the 6man
  sessions.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd:  Bob Hinden
  Responsible AD: Suresh Krishnan


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

  The document Shepard has reviewed and commented on this draft, and
  followed the process in the working group, and thinks that the issues
  raised have been resolved in the current draft.


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

  No concerns.


(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, N/A


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

  No concerns.


(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, the authors have each confirmed that there is no IPR and full
  conformance with BCP78 and BCP79.


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

  No IPR disclosures have been filed.


(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?

  There is a solid consensus around this document.  No one is opposed to
  it's publication.


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

  No appeals have been threatened, nor is there any extreme discontent.


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

  No serious nits found.  There are two references to drafts that are now
  RFCs, and two down references.  The references to IDs are:

    [I-D.ietf-netmod-rfc7223bis]
    [I-D.ietf-netmod-rfc7277bis]

  They were published as RFC 8343 and RFC 8344.  These will be fixed
  in the next version, and the down references are appropriate.


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

  N/A

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

  The document has a separate Normative and Information reference
  section.  References are characterized correctly.


(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 references are to RFC or IDs that are now RFCs (see (11) ).


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

  There are normative references to RFC 7739 and RFC 8021.  Both are
  Informational.


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

  This document obsoletes RFC6434 that is the earlier version of IPv6
  Node Requirements.  This is listed in the title page header and
  abstract.  It does not include this in the Introduction.  This can be
  fixed later.


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

  This document does not require any IANA actions.


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

  N/A


(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, etc.

  N/A