backwards compatibility with ddm protocol version 1 #156
Conversation
rcgoodfellow
force-pushed
the
protocol-unwrap-fix
branch
from
c4fe202 to
8de8595
Compare
rcgoodfellow
changed the title
| @@ -128,15 +134,15 @@ pub struct DiscoveryPacket { | |||
| impl DiscoveryPacket { | |||
| pub fn new_solicitation(hostname: String, kind: RouterKind) -> Self { | |||
| Self { | |||
| version: VERSION_1, | |||
| version: Version::V2 as u8, | |||
There was a problem hiding this comment.
Apologies as I've not spent much time in this, but how does hardcoding version 2 for the different discovery packets actually fit in terms of backwards compatibility? If someone only understood version 1, they'd presumably ignore the solicitation or advertisement, no?
There was a problem hiding this comment.
Version 1 does not do anything with the version value in the discovery header, except for fill it in with the value 1 and send it out. The backwards compatibility part comes in with how the routers behave when they get to the exchange phase, which comes after discovery. If a version 2 router detects a version 1 peer through discovery, it will speak the version 1 protocol for exchange.
There was a problem hiding this comment.
I've added a comment on this in 1f95198
There was a problem hiding this comment.
Follow in issue in
Co-authored-by: Robert Mustacchi <[email protected]>
This PR now covers backward compatibility with version one of the ddm exchange protocol.
Ddm has two protocols, a router discovery protocol and a prefix exchange protocol. The tunnel routing updates did not change the discovery protocol - and that protocol carries an 8-bit version in it. I updated the exchange client/server code to speak either v1 or v2 of the protocol based on what the peer advertised in the discovery phase. I also added backward compatibility tests to CI.