On Tue, Apr 20, 2010 at 1:36 PM, Edward Ned Harvey <lop...@nedharvey.com>wrote:
> I think this probably wraps things up: > Hmm. You really should mark most of this as "opinion" rather than "fact", though. You've presented this as a dispassionate review; however I see much to disagree with below. When you boil it all down, the one thing that is likely to add any value > people care about is the > ability to establish p2p connections, which necessitates no NAT (or at > least, no many-to-one NAT) and necessitates eliminating the "block all > unknown inbound traffic" rule which has become standard on perimeter > firewalls. > It doesn't necessitate any such thing; most organisations will probably continue to block all unknown inbound traffic, and rightly so. There's nothing about P2P applications which requires an open firewall; what's being gained is the ability to have consistent source and destination headers along the whole route, without requiring routers or firewalls to keep track of all connections for NAT purposes. Regardless of people's opinions at IETF or anywhere else, if you want to use > NAT, they will never be able to stop you. If you build the perimeter > firewall/router, and if you happen to implement IPv6 NAT on it, there is no > technique to detect or prevent that. It's not even possible to develop a > technique except inside the actual endpoint client application, which seems > unlikely to care. The only way you might be prevented from using NAT in > IPv6 if you want it: is if there's insufficient consumer demand and hence > insufficient product availability. > You still haven't presented any reason why NAT would be required or even desirable. Why implement something which is useless? > Yes, NAT could be useful to mask your internal > network topology from the wild world web. But there's a much better way to do that - RFC3041 privacy addresses. > If you do implement NAT to mask > your internal network topology, you can use an external IP for every > internal IP, and therefore p2p will not be broken in IPv6 NAT, as it is in > IPv4 NAT. > This makes no sense whatsoever. If you do a 1:1 mapping of internal to external addresses, what are you gaining? > As for security, exposing all devices directly to the Internet: There are > many possible outcomes. Fundamentally, the only security that IPv4 NAT > provides is to automatically block inbound unknown traffic (not established > or related to an outbound connection.) > ... which can be achieved by a regular firewall rule, IPv4 or IPv6. This is pretty well-understood network administration. (1) It's possible that some firewalls might have a similar firewall rule > created for IPv6 by default, and you have to disable it if you want unknown > traffic to reach your endpoint. > (2) It's possible the firewalls might ship without that rule by default, > and > increase the reliance on your endpoint software firewall. (Somebody should > tell Apple to create a firewall that works on OSX.) ;-) heheh > ipfw works perfectly on OS X; it's been included with every version that I know of and works identically to ipfw on any other BSD system. There are numerous tools out there to help configure it and load default rules automatically (I like WaterRoof). > (3) It's possible that devices such as your laser-printer-toaster or > automated beer brewing system might just enable a simple checkbox or switch > of some kind, so by default they don't take a world routable IP address, > and > by default they're only accessible using the link-local address, on the > local LAN. > It's possible. In general, though, I think that this sort of decision should be handled at the RA level; it's perfectly straightforward to configure any of the standard tools to offer addresses or not depending on the requestor. > (4) There's no reason IPv4 needs to die. In all likelihood, devices which > have no benefit from worldwide accessibility will simply use IPv4 for > outbound connections. They may implement IPv6, but hopefully then, they're > secured by one of the above methods. > We're still short of IPv4 address space. Colm -- Colm Buckley / c...@tuatha.org / +353 87 2469146
_______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
