Hi, 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? 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. 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. For BGP this is not much of a problem, but it isn't very applicable to other protocols. In IPv6 we have the Destination Option where we could stick the md5hash: no-md5: [ipv6 + tcp + data] md5'ed: [ipv6 + dstop-md5hash + tcp + data] This would even allow one to configure a host to do: - when there has never been a md5hash, don't use it - if we've once seen a md5hash use it. Allowing BGP sessions to be reconfigured on the fly even out of sync of eachother as long as they use the same passwords of course. Is such a scheme documented somewhere, is this in use or should we just play dirty and stick the md5hash in front of the data section and let the host fight it out. Greets, Jeroen
signature.asc
Description: This is a digitally signed message part
