> (2) NATs provide a huge advantage for customer support > organizations of ISPs supporting such lower-end (in terms of > financial returns, at least) connections. With a standardized > NAT setup, the setups of all of their customers are pretty much > the same, including the address ranges used by default. This > permits much easier (and cheaper) user support than trying to > debug LAN-specific routing tables, arrangements to support both > a LAN and the router providing the the interface between that > LAN and the WAN in a very small address range, and so on. In this discussion, the term "NAT" is being used as a catchall for various different things, even if we ignore the discussion about NAT-PT for v4-v6 interworking. The customer support advantage comes not from the network address translation on the box, but from the firewall side-effects of port address translation (PAT). Until we separate these three things in our speech, how can we ask anyone to implement an IPv6 firewall that does not do either address translation or address/port translation unless specifically configured? Also, I don't believe that the identical address range is that important, especially not in comparison to an IPv6 world in which every subscriber will have an identical prefix length (/48) in their Internet gateway. > I continue to believe that, until and unless we come up with > models that can satisfy the underlying problems that NATs > address in the above two cases and implementations of those > models in mass-market hardware, NATs are here to stay, even if > we manage to move to IPv6 for other reasons. And, conversely, > the perceived difficulties with NATs will be sufficiently > overcome by the above issues to prevent those difficulties from > being a major motivator for IPv6, at least for most of the > fraction of the ISP customer base who cannot qualify for PI > space. No real disagreement here but I do see a way forward. First, clarify the terminology. Second publish a pair of RFCs rather like 1009 entitled "Requirements for Consumer Internet Gateways" and "Requirements for Enterprise Internet Gateways". These documents would describe how an Internet gateway should function in its default configuration so as not to interfere with IPv6 applications but still maintain a certain level of security. It would also describe how the configuration will be changed and introduce clear terminology to describe differing levels of security (firewall-type intervention in the free flow of traffic). The goal of this section is to structure the management interface in such a way that non-technical consumers can understand what they are doing, why to change the settings and how to change the settings. The RFCs should specify the specifics of the user-interface paraphernalia. It might be implemented with buttons on the box, a GUI on an LCD on the box, a GUI app on a PC, a telnettable CLI, a webserver on the box, or an XML interface that can be controlled by an ISP service management system. The primary differences between the Consumer and Enterprise requirements will be that Consumer gateways are expected to be managed from the ISP side whereas Enterprise gateways are only managed from the customer side. Because of this, a consumer gateway will have additional features geared towards the needs of an ISP who must manage hundreds of thousands of such devices. What do the O&M area directors think of a working group with this goal? --Michael Dillon _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf