Opened 8 years ago

Last modified 5 years ago

#1188 open enhancement

Check for OBEP/IBGW transport compatibility

Reported by: zzz Owned by:
Priority: minor Milestone: eventually
Component: router/general Version: 0.9.10
Keywords: performance peer-selection Cc: orignal
Parent Tickets: Sensitive: no


<orignal@freenode> I notice one thing. When you pick you outbound tunnel and party's inbound tunnel do you check if endpoint and gateway are able to talk each other?
<zzz> no, we do not check for compatibility, that's a great idea, I will enter a trac ticket for that!

A compatibility check would look for common transports and common address types IPv4/v6.

In OCMOSJ. Also when storing our RI to ffs in StoreJob?. Anyplace else? Probably need a common compatibility-check class/method. But for the outbound direction, this isn't straightforward as we have two degrees of freedom, OBEP and IBGW.

Note that lack of advertisement of an address does not necessarily mean lack of support for outbound, but we can't make assumptions (e.g. i2pcpp and i2pd).

Not so easy.


Change History (4)

comment:1 Changed 8 years ago by zzz

Cc: orignal added

RouterAddresses? (RA) in RouterInfos? (RI) are defined as advertised inbound addresses. We have no defined way to advertise outbound capabilities. Inbound implies outbound, but there is nothing for outbound only.

An RA without host/port is almost sufficient. That's what introducers is, sortof (although it lists host/port anyway, that may need to be changed, right now we look for ihost0).

What an RA without a host/port does not do is specify IPv6 compatibility. That's where an NTCP6 RA style would have been helpful.

Perhaps an RA with "caps=46" and without host/port for IPv4 and IPv6?

Pluggable transports and a new version of NTCP will maybe make this more urgent.

comment:2 Changed 7 years ago by str4d

Keywords: performance peer-selection added
Milestone: 0.9.14

comment:3 Changed 6 years ago by str4d

Status: newopen

comment:4 Changed 5 years ago by zzz

Milestone: eventually
Type: defectenhancement

ditto for peer selection for tunnels.
<zzz> do we even want to do it though? If we do, run a few v6-only routers and you'd deanon everybody
<zzz> it could e.g. be a RI cap, or an empty RA with nothing but a cap
<zzz> right now we have two transports and we expect everybody to implement both. A year or two from now, say we have 6 or 8 transports, and 6 different router impls, it gets harder
<zzz> but there's also v6-to-v4 compatibility addresses and various ISP hackery… some of that just magically works. Others we may block as illegal addresses

Note: See TracTickets for help on using tickets.