[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BEHAVE] IPv6 Flow Label
On 6/05/08 11:16 PM, "Rémi Denis-Courmont" <email@example.com>
> Le Tuesday 06 May 2008 15:52:49 ext Hesham Soliman, vous avez écrit :
>> => I don't know why we're talking about NATs and IPv6. It sounds like a
>> flawed assumption from the beginning.
>> There are two situations I can think of that you might be referring to (I
>> haven't read TURN since 2004)
>> 1. Two connections, node - TURN relay and TURN relay - another node. I have
>> a feeling this is not the case you have in mind.
>> 2. Node - intermediate strange relay that overwrites headers - end node
>> There is no need for scenario 2 in IPv6.
>> If this is in effort to do something for Ipv6 NATs I think it's a waste of
>> time and adds confusion for the Internet as a whole.
> You are assuming that scenario 2 implies NAT.
> I believe SOCKS (RFC1928) supports IPv6-IPv6 gatewaying, pretty much the same
> as TURN would. One obvious reason is firewalls. Last time I checked the V6CPE
> discussion, it did not seem like IPv6 would deprecate firewalls.
=> Again, this implies having two different connections and there should not
be an issue with flow labels.
> One can nevertheless question the usefulness of IPv6-IPv6 gateways. Afterall
> SOCKS is quite old. And the main driver for TURN is NAT traversal, which is
> not an issue in IPv6-IPv6. Assuming that IPv6 firewalls are well BEHAVE'd,
> then TURN will never be needed in pure IPv6 cases. That seems like an
> optimistic assumption to me, but fine with me.
> Then TURN should only support, IPv4-IPv4, IPv6-IPv4 and IPv4-IPv6 cases. And
> then, the issue of flow infos preservation is moot, as flow infos don't exist
> in IPv4. Also then, we're back to my point on that TURN should provide an
> IPv4 mapped address to _IPv6_ TURN clients by default.
=> Right. I don't know about your point for mapped addresses, but I agree
with the rest.