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

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.

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.

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

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

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?

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?

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

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