Ned raises one firewall concern: they block applications that should work. I have another concern: many are completely insecure as configured. It is not completely unusual to find a $200,000 firewall configuration that could be replaced with an ethernet patch cable. I have seen it: some consultant was working on an installation at the customer site, the deployment didn't work, they shut off the firewall rules, it worked and he got paid. Nobody checked the firewall until we came in to take it under outsourced management. One of the key problems is that we have no facilities for network administration. The modus today is that we administer the hosts on the network, not the network as a whole. We have network monitoring, but not really administration. It should be possible to have a supplier drop ship equipment to the other side of the world, have them plug it into the local network and have all the configuration be pushed out securely from the administration control center in machinereadable form. Lets get rid of the need for SSH tweakage as well. I want to rack dumb hardware and then have the control system decide 'hey, I need more email server, box 42 is now an email server, here are your marching orders'. People should not talk to machines when machines can talk to machines. The machines can automatically configure, they can optimize, they can load balance. And we can save a lot of electricity this way as well. When a machine is no longer needed shut it down, or collapse its function with another under-utilized machine. In the near future we are going to be using a lot more renewables and that will mean that the spot price for energy may change pretty quickly. If the wind is blowing in Texas the price there will be cheaper than when it is not. Making use of that cheap energy is going to mean moving the computing effort to where the power is.
________________________________ From: Ned Freed [mailto:[EMAIL PROTECTED] Sent: Wed 11/26/2008 12:17 PM To: Hallam-Baker, Phillip Cc: Eric Klein; Fred Baker; behaveietforg WG; IAB; IETF Discussion; [EMAIL PROTECTED]; IESG IESG Subject: RE: [BEHAVE] Lack of need for 66nat : Long term impact toapplicationdevelopers > The problem here is that you assume that the IETF has decision power that can > magic away NAT66. Clearly it did not for NAT44 and will not for NAT66. I really hope you aren't correct about this, but I fear you are. > So the real question for App designers is: > 1) Should they design protocols that assume no NAT66 > 2) Should they regard the assumption that there is no NAT6 as a design > fault that may lead to lack of interoperability. > The only way that the effort being expended to kill NAT66 makes any sense is > if the idea is to allow this type of argument to be rulled out of scope as > similar arguments were ruled out of scope when they were brought up in > existing > protocols that simply do not work properly because the design was > intentionally > made to be unfriendly to NAT. Unfortunately, protocol-unfriendly middleboxes are a fact of life even for protocols that have no specific issues with NAT. In the case of email, for example, NAT rarely presents problems even though a significant fraction of message submission occurs from NATted systems. Firewalls are another matter. They cause all sorts of operational problems - so much so that malfunctioning and misconfigured firewalls create a noticeable fraction of our support calls. Frankly, I think it would be good if some of this anti-NAT fervor were to be generalized to other sorts of application-hostile midldeboxes. BUt I've been able to get essentially zero traction on that over the years in the IETF. > If we recognize that there is no consensus that applications that are not > NAT66-agile will work in future then we should agree that the reasonable > default requirement for an apps WG should be that it should build a protocol > that is NAT66 tolerant. But I suspect that there will be severe pushback > against that. I'm sure there will. That said, perhaps one alternative is to attempt to reduce the extent to which NAT66 will be needed by doing what Fred Baker suggests and looking clearly and carefully at the reasons for NAT use. But it is very hard to do this in the present climte of what amounts to religious hysteria on both sides. > Peter Dambier is right in this case, > I would NAT66 my network for the simple reason that very few endpoint devices > actually tollerate a change in the IP address without at a minimum a service > interruption. Since I cannot guarantee that my IPv6 address from my ISP will > never change I am going to NAT66 my internal network for the sake of having > static numbering inside the network. Bingo. That's exactly the reason long-term I'll probably do it too. And even this assumes that renumbering support of any kind manifests in a useful way. The absolutely dismal state of support for IPv6 in SOHO-grade routers is IMO one of the orimary current impediments for IPv6 deployment. And when IPv6 support does start to show up in these boxes, I really have to wonder if they'll get automatic renumbering right, assuming it's supported at all. > The more infrequent you posit the need for renumbering is, the greater my > reluctance to allowing it will become. If you have a network event that > happens > only once a year it is going to mean a very serious disruption when it > happens. > DHCP only solves some of the problems, I am still effectively forced to > perform > a reboot, I will lose connections and this will cost me real time and money to > fix. I went for something like 10 years without having to renumber, and as a result IP addresses got put in all sorts of nooks and crannies on my network. Then suddenly and without warning my ISP announced an emeergency numbering change due to an upstream provider switch. The announcement went out at 11:00PM Sunday night; the renumbering occurred the next morning. It is a bit of an understatement to say I was not a happy camper. And then it happened again a week or so later - easier because I had notes on all the stuff that needed changing plus I'd switched to DHCP as much as possible, but still no picnic. And then I had to renumber again when I switched ISPs ;-) But that should be the last time because I took the opportunity to switch to 1:1 NAT and private address space. In any case, I think getting renumbering right and getting it deployed is an essential step in minimizing the use of NAT66. Ned
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
