With the current advent of sudden rise of MD5'd BGP requests due to something not be undisclosed apparently I was looking at what routers support this for IPv6 and apparently at least both Cisco and Juniper can do this.
But what draft/rfc/doc/... are they using?
RFC2385. But you already knew that... The RFC doesn't mention IPv6, but nothing is specific to IPv4 so there shouldn't be any issues implementing it for IPv6. (Also note that there is nothing stopping anyone from exchanging IPv6 routing information over IPv4 transport.)
In IPv6 we have this nice thing called extension headers. If the RFC2385 scheme would be implemented on IPv6 I would expect it to be a Destination Option.
RFC2385 specifies a TCP option. I don't think it makes much sense to define a new option, as RFC2385 is already implemented and if something better is desired, why not simply use IPsec?
In IPv4 it looks like:
no-md5: [ipv4 + tcp + data] md5'ed: [ipv4 + tcp + md5hash + data]
Thus the 16 byte hash is stuck in the data part. If a unsuspecting host gets this packet it expects data in the portion where the hash now is in place.
First of all, the hash is in the TCP header (I think you're confused by the description of the hash calculation), and second this mechanism must always be manually configured between two hosts so the "unsuspection host" scenario doesn't apply.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
