<meta charset="utf-8"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Hi, </span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div>>Why would be need negotiation if we will not have encryption?</span><br>I was thinking of a scenario with both nodes behind NATs. In this<div>
case is still possible to establish direct tunnels, but we need a ICE-like</div><div>procedure. In many cases we will just need to tell on wich </div><div>(IP addr, UDP port) pair we are expecting tunneled packets.</div><div>
<div><div><div><br></div><div>>So it is better to decide</div>>to which UDP destination(s) send each packet. And this is it?<div>Yes.</div><div><br></div><div>>But from planning perspective we should already plan IPv6.<br>
<div><div></div></div></div><div>OK. I totally agree.</div><div><br></div><div>Marco</div><div><br><div class="gmail_quote">On Thu, Apr 15, 2010 at 4:01 PM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi!<br>
<div class="im"><br>
> I agree, and in fact, the learning process update the forwarding table<br>
> automatically ( I guess I didn't specify that in the proposal :) ).<br>
> I think that there are scenarios in which you have the tunnel<br>
> established with a node, but you don't know the (inner - virtual) address<br>
> of the node that established the tunnel (it is a matter of the specific<br>
> signaling protocol used in the tunnel negotiation). In this case, you need<br>
> an explicit rule for the node initiating the flow, while the "responder" can<br>
> still automatically update the forwarding table.<br>
<br>
</div>Signaling protocol used in the tunnel negotiation? You would negotiate<br>
tunnel? I thought it would be much simpler to do it without<br>
negotiation. Whatever comes on the UDP port you push into kernel IP<br>
stack of virtual interface and this is it. You do not need even to<br>
check what it is. Just on the sender side you decide over which<br>
tunnel(s) (to which destination UDP ports) you send a packet. Why<br>
would be need negotiation if we will not have encryption?<br>
<br>
I think we could see this as a virtual switch, except that for cables<br>
you have UDP packets between UDP ports (and not hardware ports).<br>
<br>
Maybe easier would be to imagine if we would have virtual hub.<br>
Whatever would come to virtual interface would be send to all<br>
configured destinations encapsulated in UDP packets. On destination<br>
UDP would be simply stripped of and feed to virtual interface.<br>
<br>
The only problem with this is that a lot of packets would be sent just<br>
to be discarded by destination's IP stack. So it is better to decide<br>
to which UDP destination(s) send each packet. And this is it?<br>
<div class="im"><br>
> 1- (as for the inner packets) not all applications are supposed to have IPv6<br>
> support<br>
<br>
</div>But I think that IPv6-only meshes (internally) are something which<br>
will be probably used for those of us who do not have public IPv4<br>
addresses. (And we will then to some magic for clients so that they<br>
will be able to use IPv4.)<br>
<div class="im"><br>
> 2- (as for the tunnel header) few ISPs provide IPv6 connectivity.<br>
<br>
</div>Our main server, high speed Internet gateway, is IPv6 connected. And<br>
also some of our nodes (like at university) are also connected to IPv6<br>
network. Currently we use IPv4, but it would be at least interesting<br>
to play with IPv6. :-)<br>
<br>
But I completely agree. From coding perspective first do IPv4 version.<br>
But from planning perspective we should already plan IPv6.<br>
<div><div></div><div class="h5"><br>
<br>
Mitar<br>
_______________________________________________<br>
WLANware mailing list<br>
<a href="mailto:WLANware@freifunk.net">WLANware@freifunk.net</a><br>
Abonnement abbestellen? -> <a href="https://freifunk.net/mailman/listinfo/wlanware" target="_blank">https://freifunk.net/mailman/listinfo/wlanware</a><br>
<br>
Weitere Infos zu den <a href="http://freifunk.net" target="_blank">freifunk.net</a> Mailinglisten und zur An- und Abmeldung unter <a href="http://freifunk.net/mailinglisten" target="_blank">http://freifunk.net/mailinglisten</a></div>
</div></blockquote></div><br></div></div></div></div>