Wes Beebee (wbeebee) wrote:
I've heard IPv6 described as a major forklift upgrade with a minor
engineering benefit over IPv4 (larger addresses).
IPv6 doesn't have to be a forklift.
That said, this thread is sufficiently off-topic from NAT66 that it
should be put to rest or taken elsewhere.
- Mark
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
