On 7 jan 2008, at 19:54, james woodyatt wrote:
2. Or should the opening up of incoming ports go through the OS, rather than be signalled directly from applications to the CPE?
I don't understand the question. The OS will always be sitting between the application and the CPE in any case, by virtue of providing the socket API,the network stacks and drivers, and possibly the local firewall.
This is already happening in the OS for IPv4/NAT. That's where the NAT-PMP and UPnP IGD support is coded. Application developers aren't rolling their own implementations of those protocols. They're relying on the OS to provide them with APIs.
I'm not sure if this is universally true. For instance, I believe that Azureus (popular BitTorrent client) has its own uPnP/NAT-PMP code.
I see no reason to burden application developers with new requirements just to use IPv6 instead of IPv4/NAT.
It would be good if the OS could determine the needs of applications and act on those without explicit signalling from the app, yes.
3. Should a host have the option of signalling to a CPE that it doesn't require any filtering?
It would probably be useful in some scenarios.
No. No, no, no. Firewalls don't care what nodes think are their filtering requirements. Policy is decided by the firewall administrator and enforced in the network middlebox.
See Christian's comment.
They'd better do it, because there are deployed IPv6 networks without reverseDNS. Especially if the host uses privacy addresses.
We're going to need privacy addresses once IPv6 worm authors start harvesting target addresses from server logs and honeypots.
Hm, how disposable can we make addresses before the baby goes out with the bath water?
But more importantly for this discussion: do we assume that these temporary addresses don't get DNS names? I know some people want DHCP servers to handle setting up DNS entries. It's not completely impossible to do this: you can have a host ask for a specific address with an IA option and then the DHCPv6 server still gets to see the address even though the host generated it. But there are other ways to do it, too. I like the dynamic DNS approach, although this needs to be handled carefully because Windows' DDNS implementation is pretty much a DDoS attack against the root servers. The forward DNS isn't a big problem, although this may need some setting up if the ISP doesn't handle it. Reverse should be easy: just let address X change the DNS entry for address X. But as an ISP, I would prefer to simply delegate the reverse DNS to the user's server for reduced headaches.