Ballot for draft-ietf-6man-rfc2460bis
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
I think it is valuable and accurate to express the maturity of IPv6 by making it an Internet Standard as the transition to IPv6 accelerates.
I support Ekr's DISCUSS (and most of his comments should be DISCUSSes) and Alvaro's DISCUSS.
Please have a look at the changes suggested in Peter's Gen-ART review: https://datatracker.ietf.org/doc/review-ietf-6man-rfc2460bis-08-genart-lc-yee-2017-02-28/
Thanks for addressing the points in my DISCUSS.
I support Ekr's DISCUSS. Otherwise, thank you for structuring this bis draft in a way where the diff tools are actually helpful.
Support Alvaro's Discuss.
I get that this document is from a period before the style became as uniformly to upper-casify RFC2119 keywords, but but it seems like it might be a good idea to do that here. It's a little hard to determine what is normative here, but S 4. says A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options Routing Authentication Encapsulating Security Payload Given that 6434-bis seems to have backed away from IPsec, this document needs to as well. S 4.4. Assuming I am reading this document correctly (and I've never implemented v6 so I could be crazy), in order to implement the routing header you need to decrement Segments Left, but the document does not seem to say that. S 4.5. As I read this document the order of headers is only strongly recommended, but the rules about fragmentation seem to absolutely require a specific order: The Per-Fragment Headers consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. Is there a reason why the rules are not MUST? S 4.5. The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. If fragments follow different paths (not crazy) then the hop limit will be different, right? So perhaps "not expected" is a bit strong. S 8.4. Response packets that carry Routing headers that were derived by reversing the Routing header of the received packet IF AND ONLY IF the integrity and authenticity of the Source Address and Routing header from the received packet have been verified by the responder. It's not clear to me how this works. If, as I suggest above, the routing header gets changed in transit, how do you measure the integrity and authenticity? Even if that is not the case, and you use something like IPsec to provide integrity, why do you trust whatever claims the sender makes about routing.
Thanks for updating the Security Considerations section, I was glad to see the references added to the fragmentation work that had already been done. If the TLS and SSH reference remain in the document, references would be good - RFC7525 and RFC4250-4254, but my preference would be to delete the sentence as this document is about IPv6 and developers and implementers of this standard wouldn't need those references, IPsec is enough.
Thanks for addressing my discuss. Please put a reference to RFC6465 in there to make sure that these RFCs do run out of sync.