IPv6 content experiment
rdenis at simphalempin.com
Tue Apr 10 13:55:19 CEST 2007
Le mardi 10 avril 2007 14:06, Colm MacCarthaigh a écrit :
> > Which break as the first thing most people do is put a firewall
> > in place. Why do people carry on insisting open end to end
> > connectivity is the holy grail and designing protocols that don't
> > tolerate firewalls. Why would they not have a firewall for v6 too?
> No reason at all.
Sure, they will put firewalls (see
http://docs.info.apple.com/article.html?artnum=305366 for a recent
example). We can argue whether they'll be useful or not, but I'm pretty
sure they'll be there anyway.
> But you'll find that the majority of firewalls do not blanket filter
> inbound connections by default, and there's no good reason for them to
> either. In fact most end user firewalling products these days detect
> listen()'s and ask the user if they would like to allow or disallow
> inbound connectivity to that application.
Yes... But, this only works for host-firewalls. NATs are not found on
hosts, and it's likely that IPv6-enabled SOHO CPE (if they ever hit the
market) will ship with stateful IPv6 firewalls that will block incoming
connections. And even if they wanted to, they would not be able to
catch listen() system calls :(
> The point is that that flexibility becomes optional again, rather
> than restricted mandatorily.
It might be optional. "Hopefully" these would-be IPv6 CPEs will have a
big "firewalled on/off" button that will break so many cool apps that
people will always set the firewall to off... maybe. Afterall, my cable
modem has a "Internet data security" button (but it stops EVERYTHING
when pressed - that's extremely secure indeed).
> Personally I don't think it is the job of protocol designers to
> tolerate firewalls, that just gets us a billion protocols which all
> tunnel over HTTP.
I disagree. There has to be a tradeoff between everything on top of
HTTP, and "no security".
For UDP, we have discovered hole punching which works nicely around most
stateful firewalls. And in fact, any protocol should do some kind of
hole punching, not only to pass through firewalls, but also to make
sure one end is not sending piles of packets toward an unwilling other
Unfortunately, I am yet to see any widespread/agreed way of doing this
for TCP (whether TCP/IPv4 or TCP/IPv6). Big bonus if it works for "any"
layer-4 protocol so we don't doom any new transport to failure on IPv6
as NAT did on IPv4 (think DCCP, SCTP, UDP-Lite...).
> Internet security is better served by discrete protocols which are
> possible to filter and allow on a more granular basis.
Yes. Though apps vendor will continue to ship stuff that uses (or can
fallback through) HTTP, if only because there is demand for bypassing
firewalls, whether legitimately or not. Many people have no control
over the firewall(s) on their Internet access (e.g. in corporate
> > Most end users have an OS that really shouldn't be left open to
> > access by all,
> NAT is not a firewall, and does not meaningfully protect these users.
I completely agree. However I have seen many people call NAT what is
really a NAT plus a stateful firewall (since both functions are more
often than not in the same box). However, a stateful firewall does
protect some kind of protection. And it is also used to prevent
unsolicited traffic from filling up limited last mile bandwidth - a
problem end-to-end principle cannot address. Which is why I'm asking
for a layer-4 independant hole punching mechanism (end-to-end really
starts at layer-4).
> It's not like we don't already see millions of those bozes
> participating in botnets already. Nor does the removal of NAT leave
> them open to access by all.
I agree. If it can be caught by a worm through open TCP ports, it can
likely be caught by something running on email, IM or HTTP also.
> > add v6 to a major site (I've looked at this for BBC sites for years
> > and it's never been worth the risk) without black holing users
> > we'll be a big step towards general use.
> Why not just have www.ipv6.bbc.co.uk ? Does that really represent
> much risk? Seems like a better idea to iron out those problems before
No offense intented, but I think this *.ipv6.example.com thing is very
useless. Nobody uses it, so nobody finds the problem, so it does not
make anybody a service. The only way to diagnose IPv6 problems is to
put it to the normal hostname, and provide *.ipv4.example.com as a
work-around for people with blackhole IPv6 connections. It is more
painful and it makes IPv6 a very bad publicity to the affected users
(see the Ubuntu discussion a few days ago), but at least, it sort of
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070410/d45e9264/attachment.bin
More information about the ipv6-ops