Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-13

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.