19 Nov
2013
19 Nov
'13
11:22 a.m.
On 10/24/2013 02:24 PM, Axel Neumann wrote:
the question here would be: which src-address to use for that first packet?
if you use the primary address of the originating node, then AFAIU the
kernel will drop it, unless there's a point-to-point interface with that
specific address as "peer"
so my idea was to use your current "hacky" scheme of addresses (src-addr
is fake but predictable, based on dst-addr) to deliver the first packet
("I want a reverse tunnel")
but maybe it's not needed and i'm not seeing the big picture :)
something i would love to hear!
Hi Gui!
3) A gets the
ACK and creates the tunnel with "peer 2001:db8::D"
*** now both ends have a symmetric tunnel between them, with real src
and dest address ***
4) A finally sends the real payload through the symmetric tunnel, this
payload (may be bigger than 1280, say... 1450) will be encapsulated
with the real src-addr of A, so if any node in the path needs to send
back a Packet-too-big, will be able to, and PMTUD will happen correctly.
(at the cost of a full RTT latency before the first payload packet,
but with a reasonable tunnel expire time as it has currently, that
shouldn't be terrible)
back in April, i remember we discussed the idea of symmetric tunnels,
and you brought up this "control connection" idea which i'm simply
redescribing here.
But that discussion was in another context, more like a 'feature', and
finally didn't really solve the idea we had originally,
yet, this PMTUD issue was not taken into account AFAIR, so the
"symmetric tunnel" idea now becomes more like a bugfix (i.e. don't
create PMTUD blackholes)
what do you think?
I think the reception of an ip6-encapsulated packet destinated to the
primary address of the node could be used as an implicit request to
setup the reverse tunnel (from the gw to the node). So the additional
setup delay (of one RTT) could be avoided but at the cost of not knowing
if the gateway accepted or will ever accept the implicit tunnel request.
I'll try to speed up the dev of symmetric tunnels.
sounds great! in the meantime we're getting away with the mtu=1350, but
last week i bumped into some (suspected) mtu issues again, maybe because
it was a tunnel over a DSL line (thus adding 8bytes overhead), so anyway
a proper solution will be a great improvement overall, whenever it's
ready :D
cheers!
gui
/axel
Cheers!!
gui
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev