<div>Hi,</div><div><br></div>>But I think this learning of which tunnel to choose should be also<br>>done automatically. Like switches are doing it. You do not need to<br>>preconfigure which port switch will use to send a packet.<div>
<div>I agree, and in fact, the learning process update the forwarding table</div><div>automatically ( I guess I didn't specify that in the proposal :) ).</div><div>I think that there are scenarios in which you have the tunnel </div>
<div>established with a node, but you don't know the (inner - virtual) address</div><div>of the node that established the tunnel (it is a matter of the specific</div><div>signaling protocol used in the tunnel negotiation). In this case, you need </div>
<div>an explicit rule for the node initiating the flow, while the "responder" can</div><div>still automatically update the forwarding table.</div><div><div><br></div></div><div>>We should also not forget about broadcast (at least).<br>
</div><div>Yes. I think there will be no problem.</div><div><br></div><div>>When we are talking about IPinUDP we are talking about both IPv4 and</div><div>>IPv6? And also UDP will be both over IPv4 and IPv6?</div><div>
I was thinking of starting considering only IPv4. Anyway, this is a good point, and I don't</div><div>see big problems in extending the module to support IPv6 (for both encapsulation </div><div>headers and inner packets).</div>
<div>Anyway, in my defense, I think it is reasonable to start supporting only v4 because: </div><div><br></div><div>1- (as for the inner packets) not all applications are supposed to have IPv6 support</div><div>2- (as for the tunnel header) few ISPs provide IPv6 connectivity.</div>
<div><br></div><div><br></div><div>Marco</div><div><br></div><div><br></div><div><div class="gmail_quote">On Thu, Apr 15, 2010 at 2:27 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>
On Thu, Apr 15, 2010 at 1:56 PM, marco bonola <<a href="mailto:marco.bonola@gmail.com">marco.bonola@gmail.com</a>> wrote:<br>
> Now, I'm doing this because I considered a more complex scenario.<br>
<br>
</div>I agree. It is necessary to consider also complex scenarios. It is<br>
always then possible not to use it. But it is harder to add it later.<br>
I think it is good that it is possible to fix which tunnel to use for<br>
a given inner packet specification.<br>
<br>
But I think this learning of which tunnel to choose should be also<br>
done automatically. Like switches are doing it. You do not need to<br>
preconfigure which port switch will use to send a packet. It learns by<br>
itself. And something like this should be also possible here. (Next to<br>
the possibility of manually specifying the port/tunnel.)<br>
<br>
We should also not forget about broadcast (at least).<br>
<br>
When we are talking about IPinUDP we are talking about both IPv4 and<br>
IPv6? And also UDP will be both over IPv4 and 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><br>

</div></div></blockquote></div><br></div></div>