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.
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.
It seems to me that you're making the assumption that the only
scenario IPv6 will be deployed in is one where end-nodes always
have an upstream stateful firewalling device.
This is likely to be *more* common in the future than it already is
today. Residential IPv6 gateway devices are shipping now in consumer-
grade Wi-Fi AP/router products, and they include these packet filters
turned on by default. More are forthcoming. Their owners are rarely
even made aware of these packet filters. Most won't discover them
until they try to do something silly and stupid, like receive
incoming VoIP calls over IPv6, fail utterly, and then *maybe* track
down the source of the ICMP "administratively prohibited" errors to
their own router.
Architecture is hard, folks. Despite our best laid architectural
planz, we are certain to be plagued with middleboxes at every level
of the Internet. They're going to interfere with everything.
Basically, if it's known to work today over IPv4/NAT, then there's a
pretty good chance it will still work tomorrow over IPv6. That's
about the best we can hope for at this point.
If NAT between PA and ULA-C unicast addresses solves a problem for
somebody, without breaking anything important that isn't already
broken by something else we've already done, then why shouldn't we be
pragmatic and define a mostly sensible way for them to do it?
p.s. Readers are encouraged to consider whether this message is a
devil's advocacy.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
