IPv6 Support Required for All IP-Capable Nodes
RFC 6540

Note: This ballot was opened for revision 02 and is now closed.

(Jari Arkko) Yes

(Ralph Droms) Yes

(Wesley Eddy) Yes

Comment (2011-09-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 2 says "IP is redefined to mean IPv4 + IPv6", but I think to be consistent with the rest of the document it should say "IP is redefined to mean IPv6 or IPv4+IPv6"?

(David Harrington) (was Discuss) Yes

Comment (2011-09-08)
No email
send info
My real concern is that publishing this document a Proposed Standard  RFC might actually be damaging. 

IPv4 is being exhausted, and will no longer be suitable as *the* IP protocol underlying the Internet. The IETF mission is to make the Internet run better. We have in some ways been amiss in adding on lots of hacks to IPv4, such as NATs, and we are in the process of adding more. 

I believe that we have now reached a point where we are applying life-sustaining efforts to IPv4 that have exceeded the benefits/cost tradeoff threshold. Many of these hacks make the Internet run worse, not better. I think it may be time to declare IPv4 Historic, and stop trying to save it by piling on more detrimental hacks. 

We should **rewrite** documents like RFC1122 to reflect IPv6-only or dual stack options, to make it clear that an implementation that only supports IPv4 does not make the Internet run better; By supporting IPv4-only and the needed hacks, these implementations make the Internet run worse.

This document is a just a band-aid that might make the authors feel good, like an opinion piece does, but it gives the impression that it might actually accomplish something. I fear the only thing it will accomplish is to delay the work of actually rewriting RFC1122 and other documents to recognize that IPv4-only is no longer adequate for use in the Internet.

(Sean Turner) Yes

(Ron Bonica) (was Discuss) No Objection

(Stewart Bryant) No Objection

Comment (2011-09-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the document and it's intent, but would ask the authors to think about the following:

These two statements seem contradictory:

     IPv6 support MUST be equivalent or better in quality and
      functionality when compared to IPv4 support in an IP
      implementation.

      It is expected that many existing devices and implementations will
      not be able to support IPv6 for one or more valid technical
      reasons, but for maximum flexibility and compatibility, a best
      effort SHOULD be made to update existing hardware and software to
      enable IPv6 support.

Do the authors mean in the first para : IPv6 support in NEW equipment and software .......

Also is there any danger that the demand for immediate equivalence 
will introduce unintended delays in the deployment of more IPv6?

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

Comment (2011-09-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think I am missing the point of this document. It is not that I
disagree with it, but I don't see what it hopes to achieve. Is it the
intention that any node that claims to be "IP-capable" must support
IPv6? Will this document achieve that?

The statement that a user wants an "Internet caable" device and will 
not select specifically for IPv6 is fair. But redefining a term that
is current usage will not fix this. 

---

There is a slight contradiction between the language in the abstract
where "IP-capable" is redefined to make IPv6 mandatory, and that in
Section 2 where you have "SHOULD not support IPv4 only".

---

Section 2

      It is expected that many existing devices and implementations will
      not be able to support IPv6 for one or more valid technical
      reasons, but for maximum flexibility and compatibility, a best
      effort SHOULD be made to update existing hardware and software to
      enable IPv6 support.

I think "will not be able to" might better read "cannot be updated to"
because "will not" conveys a confusing future tense regarding existing
implementations.

Does the update intend to be made in the field, or for future shipments?
Is there a statement here about not continuing to ship existing products?

(Stephen Farrell) No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2011-09-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I see nothing harmful about this document, but I also don't see that it will have any real-world impact.

(Dan Romascanu) No Objection

Comment (2011-09-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
1. I support Ron's DISCUSS. 

2. I do not understand why this document aims to be a Proposed Standard. There are no testable requirements to allow this document to progress on the standards track. 

3. Jouni Korhonen made the following comment in the OPS-DIR review: 

The I-D is standards track and updates 1812, 1122 & 4084.
However, the I-D states:

  "...Therefore, the above-listed
   standards are not being updated to include the complete technical
   details of IPv6, but to identify that a distinction must be made
   between IPv4 and IPv6 in some places where IP is used generically."

I am pointing at this because the current I-D text regarding updates to these specifications is not detailed enough. Just giving few "for example"s is not enough. What I think is needed is a clear (bullet) list of affected sections for each document separately also detailing what is the exact text that gets affected/updated and how. Now too much is left for the reader..

I suggest that this comment is addressed before the document is published. 

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection