> From: Melinda Shore [mailto:mshore@xxxxxxxxx] > On 7/2/07 11:14 AM, "Hallam-Baker, Phillip" > <pbaker@xxxxxxxxxxxx> wrote: > > There is no other device that can provide me with a lightweight > > firewall for $50. > > Of course there is - the same device that's providing the NAT. The $50 includes the cost of administration. I get the NAT effect for free when I plug the box in. Turning it off on the other hand requires rather a lot of thinking for the average user. > NAT by itself is intrinsically policy-free, although it > implements policy as a side-effect. I'm unclear on why you > think that a default-deny policy is better implemented on a > NAT than on a firewall. That is not what I am tying to say here. My point on NAT is that the objections being made against NAT are actually considered to be benefits in the wider Internet world. Turing off functionality you don't need is actually a good thing. We need a way to turn off unneeded functionality that is more effective than NAT. NAT is crude and turns off slightly more functionality that we would want. So we have Skype and others doing aggressive peer-peer end runs around NAT to make VOIP work. And I still can't find anyone with a set of comprehensible instructions on how I make video-conferencing work with my home network. But I would much rather forego videoconferencing and the ability to run multiple VOIP boxes than spend $10 per computer per month for every machine in the network to have its own separate IP address. That's a saving of over $1,000 a year for me. The IPv4 address space is scarce. NAT allows us to conserve what we have. Like they tell people in the disabled community: don't hate the wheelchair, its your friend, not your enemy. I use one IPv4 address instead of nine. The idea behind Domain Centric administration is we put in place a set of administrative support tools that make the NAT debate moot. This weekend I filled up the van with super instead of regular gas. If I put the wrong gas in the MGB it would send the engine seriously out of tune as the carbs are tuned for super. On a modern car the engine management unit detects and adjusts automatically. We need the same sort of approach to network administration. The devices on the network should not care whether they are on IPv4 or IPv6, they should detect and adjust automatically without the need for network administrator intervention. I have spent some time looking into the incentives for upgrading to IPv6 and they are not at all promising for us in the IETF. We seen the importance of making the change because we recognize the value to the community. Clearly joining the Internet will have great value to potential user number 4 billion plus 1. The problem for designing deployment incentives is that the cost of deployment falls on the first four billion users and the value to them of user 4 billion plus one joining is a rounding error using Real32. If we are going to deploy IPv6 we have to design deployment incentives that work for the parties that have to make the investment, not continue to hope that they see the light. If we go the way we are going at present there will be no IPv6 transition. There will be occasional IPv6 deployments but most end users will simply sit behind honking great big hyperNATs. In addition to losing the NAT argument we will end up losing the network neutrality argument (regardless of which position you take in that debate we will end up at a position that is not Pareto optimal). Deployment of IPv6 must be hooked into the solution to problems that are already recognized as pain points. Security is one widely recognized pain point, the cost of network administration is another. What I am saying is, please don't try to sell IPv6 as a replacement for NAT. The NAT boxes are not causing a pain point as far as proponents are concerned. Having spent over a decade trying to get people to consider security to be a pain point before they were prepared to accept that it was I would really urge you not to waste time trying to convince people that NAT is a pain point. Domain Centric allows us to avoid the whole debate altogether. Address the recognized pain points, finesse the transition to IPv6. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf