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:ned(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: Wed 11/26/2008 12:17 PM
To: Hallam-Baker, Phillip
Cc: Eric Klein; Fred Baker; behaveietforg WG; IAB; IETF Discussion;
alh-ietf(_at_)tndh(_dot_)net; 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf