... And ISP's could just say "we're only handing out one /128" because we're expecting you to deploy NAPT66 - and there are plenty of vendors willing to sell NAPT66 boxes...
- Wes -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Keith Moore Sent: Monday, March 30, 2009 3:43 AM To: Mark Townsley (townsley) Cc: Margaret Wasserman; [email protected]; [email protected] Subject: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48 Mark Townsley wrote: > This is all really just crystal-ball gazing, but if one of the reasons > we are going to build NAT66 openly in the IETF is to avoid vendors > building it themselves, I find it hard to believe that targeting /48 > only will suffice. 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? It seems like one of the consequences of IETF defining NAT66 might then be that it pushes us further down the "slippery slope" toward widespread NAT in IPv6. It's one thing if it turns out being used by medium sized enterprises, quite another if it turns out appearing in every consumer IPv6 router. I'm actually much less concerned about the consequences of NAT66 in medium enterprises (who can presumably make a technical evaluation of the pros and cons of NAT for their particular business needs and then choose whether to solve their say multihoming problem with NAT or by some other means) than for home users (who are forced to use NAT in IPv4 in part because a single address is all most can afford). What I'd really hate would be for the existence of NAT in IPv6 and in home routers to be used by ISPs as an excuse to dole out only /64s or longer prefixes. > Point is, once the genie is out of the bottle, I don't think it is > realistic to think that we can keep it backed into a /48 corner. > Special-casing /48 may be worthwhile, but we need to somehow address > the rest. Going "halfway" here could well be a classic worst of both > worlds situation (i.e, we should either define NAT66 in full, or not at all). I really think it depends on what problems NAT66 is expected to solve. There's a bit of the "Maslow's hammer" mentality about NAT these days - NAT is such a familiar tool that people tend to see lots of different problems as address translation problems rather than say, tunneling problems. As I tried to say in SF, we really need to decide which use cases of NAT66 are justified (from an engineering perspective) and make sure that the solution we develop in IETF actually addresses those cases. Unless we do that, we run a real risk of (a) developing a solution to one or more non-problems, while (b) failing to develop solutions to bona fide problems, with (c) the unintended consequence of promoting wider use of NAT in IPv6 than is needed. For instance, I'm pretty much convinced that the value from the degree of topology hiding that can be accomplished by NAT66 is so small that it's not worth the cost to deploy it. There might be people who think otherwise, but that doesn't compel IETF to spend its resources solving their non-problem - especially when doing so legitimizes the idea of IPv6 NAT in the public mindset. (as certain members of the trade press would love to crow about...) If we were to determine (for example) that the only valid use case we could find for NAT was for address independence, we could develop a solution for just that case. And we could call it something besides NAT. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
