james woodyatt wrote:
On 20 Jun 2007, at 15:10, Mark Smith wrote:
On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt <[EMAIL PROTECTED]> wrote:
I'd be more sympathetic to arguments like this if we RFC 4864 didn't
insist on recommending the deployment of stateful packet filters in
IPv6 that break most of the things NAT breaks in IPv4.
How does a stateful firewall, present on the end-node itself, cause
these problems?
We see this all the time today with stateful packet filters in IPv4
nodes at global unicast addresses. Application binds to a socket for
accepting connections, but that isn't enough for accepting incoming
connections. Application need to obtain authorization to request the
firewall to allow incoming connections. That involves asking a user for
a password. Bletch.
And then there is no real standard for asking for that authorization in
the first place. A lot of applications embed UPnP, which I guess is as
close to a standard for being able to request a listening port as we
have. Many protocols have ways of testing to see if a listening port
really is listening, since there is no real local feedback from
firewalls that your listening port is being filtered or NAT'd or had any
number of other things done to it.
And then we get software developers abusing what is really a bug in
stateful boxes in the name of "nat transversal". Operators and end
users regularly say "Your new application should support nat
transversal" rather than fixing the underlying problems.
Moreover, firewall knows how to track state for TCP and UDP, because
that's all the transports the IP stack knows about. It would be
reasonable to port implementations of SCTP and DCCP to live there as
well, but nobody bothers because the firewall doesn't know about those
transports and needs to be taught about them from scratch.
Consequently, applications that should use DCCP or SCTP, use TCP or UDP
instead, so they can work with the firewall interface they have.
Firewalls don't get upgraded to support SCTP and DCCP because
applications are all limping along with TCP and UDP. Egg: meet chicken.
And these boxes don't support this "new fangled" IPv6 thing either.
Operators claim theres no point in pushing IPv6 out to customers coz
their CPE's don't support it.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------