On 5 aug 2008, at 16:58, Magnus Westerlund wrote:
The passive side of the TCP connections can hardly be behind a NAT.
Isn't that the whole point of endpoint independent NATing?
To allow for it yes, but there is also the filtering behavior. NATs
doesn't allow traffic in unless you have sent to that address or
even address and port.
Right, because of the unfortunate notion that NAT provides security.
With NAT64 this isn't an issue because even if the NAT64 were to
filter, incoming sessions over IPv6 would still be possible so a
filtering by a NAT64 doesn't provide any security. So any filtering
would have to be done on the CPE and/or the hosts in question.
For a dual stack light type of solution this is slightly different,
but in this case I think it would also be more secure to have the
encapsulating CPE provide filtering rather than the ISP NAT, if
filtering is desired.
In the absense of filtering on the NAT incoming sessions the way I
described in my previous message should work, right?
Unfortunately I have to agree with Remi, for TCP and carrier NAT you
really like to have a whole punching protocol for listing sockets.
So which is it then?
If the endpoint independent behavior doesn't buy us incoming sessions,
what's the use and why would we impair the NAT box scalability for it?
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
