I've heard IPv6 described as a major forklift upgrade with a minor engineering benefit over IPv4 (larger addresses). At first, I started arguing with them about the advancements that IPv6 has made. What I didn't realize until recently is that that wasn't a complaint, but a *goal* by some Service Providers with a lot invested in the current IPv4 infrastructure and an aversion to change.
- Wes -----Original Message----- From: Fred Baker (fred) Sent: Wednesday, April 01, 2009 11:49 AM To: Wes Beebee (wbeebee) Cc: Keith Moore; Mark Townsley (townsley); Margaret Wasserman; [email protected]; [email protected] Subject: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48 And they would have no customers, and they would complain that IPv6 didn't buy them anything. Yes, there are idiots in the world. On Mar 30, 2009, at 7:04 AM, Wes Beebee (wbeebee) wrote: > ... 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 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
