(do not taunt Happy Fun Ball) james woodyatt wrote: > On Mar 30, 2009, at 00:17, Mark Townsley wrote: >> Certainly, if /48 service (along with a "compatible with IETF NAT66" >> bullet-point in the SLA) comes at a premium in terms of monthly >> service fees vs., say, a /56 or otherwise, then you've given an >> incentive to small router vendors to build something that allows one >> to get all the advantages of /48-type service with a /56 service >> contract. Voila, the vendor gets to reap the difference between the >> service fees for /48 vs. /56... Much like they did for a /32 vs. /30 >> (or "multiple IP" service) in IPv4.... see where I'm going with this? > > This is the argument I attempted to make in the 6AI session in San > Francisco last week when I ranted about how we're hand-waving away > address amplification as a perceived benefit of NAT deployment for > IPv6. I had hoped that hearing it come from a member in the engineering > team for a line of small router products made by one of the major > vendors in the market might help clarify the issue for some.
Actually I suspect the set of SOHO router customers who couldn't make do with a /56 (or really, even a /64) *without* NATting is relatively small. A more relevant concern might be the use of NAT as part of autoconfiguration. The typical v4 NAT just gets one address via PPP or DHCP and from there it serves a great many hosts. But you can plug another NAT into the back side of the first NAT and it will do the same thing. In this way, NATs implement a form of the "catenet" model and they do it without any explicit configuration. Sure it sucks in lots of different ways, but overall it's a very nice feature for casual users. (Seems like once upon a time I read about some IPv6 DHCP options or some other ways for a downstream router to grab some allocation from an upstream router -- but I didn't keep up with it, so I don't know whether it ever survived its journey through the swamp. But I think it's fair to say that if IPv6 SOHO routers aren't given a better way to do autoconf even in the presence of nested routers, they'll use NAT.) > I also pointed out that this feature would be deployed by small router > vendors to permit networks to obtain something like Internet > connectivity from providers who restrict service only to hosts, i.e. > those that do not delegate any prefix at all. In general, when there's a tussle between the ISPs and their customers, it's hard to expect the router vendors to not try to help the customers pull from their end of things. Though this might not be much of an issue as long as there is competition between ISPs. > Anyone who thinks that captive network service providers (like, say, > those serving hotel guests) won't eventually recognize there's a huge > incentive for them to charge per host instead of per network demarcation > point is willfully ignoring more than a century of telecommunications > industry economic history. True, but I'm not sure what that has to do with NAT. The hotels (and airports, etc.) can and will charge per MAC address, just like they do with IPv4. Customers can drag IPv6 NATs along with them if they want (or use "Internet sharing" software in their PCs). (And if the hotels network providers work hard enough, they can detect the use of NAT and pessimimize the connection quality.) In general, it seems like the thing for IETF to do is not try to completely forbid IPv6 NAT, but instead write specifications in such a way that IPv6 NAT is seen as the last resort... and try to solve the problems in other ways so that NAT is a corner case rather than the general case. That eases the burden on software developers - they can deal with NAT if they want to, but hopefully most of the market won't have NAT so most applications won't have to deal with it - thus making most things less complex and more reliable. > If one can't find any providers currently thinking that's how they'll > sell IPv6 service, then it only means one > hasn't asked the ones with mono- or oligopolistic market power. Well, those same providers would very much like to do differential charging for traffic (based on destination port or destination address), but for the most part they haven't done so yet, and there's pressure from governments and public interest groups to not do the latter. So it is at least possible that they'll hold off on "per host" billing for awhile. > It would be very good if we could stop pretending that address > amplification isn't among the reasons users could have for wanting to > deploy NAT for IPv6. Of course it is a reason. But I can't tell how big a reason it is. And a lot of that depends on just what ISP IPv6 service offerings look like a year or three from now. I don't see how to evaluate that at this point. But the point is clear - the ISPs can kill e2e v6 if they want to. And what's more, the impending exhaustion of v4 address space may give them sufficient ammunition to do so. Soon IPv4 may suck badly enough that IPv6 only has to work marginally better to get customers to switch to it. e.g. A single v6 /64 with no port restriction and a NAT-PT for legacy v4 access, might well look more attractive to a customer than a NATted, shared v4 address with port restrictions. > Yet, as we have already decided that "NAT66 Is Evil" is an unwelcome > view in this BOF, it seems there is little hope for any productive work > to come out of this effort until that changes. Of course NAT66 is evil. We should all acknowledge that at the start so that we don't have to debate it. The question is whether we can make it less evil, and/or promote even lesser evils as alternatives to NAT66. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
