[arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition
Jason Schiller
schiller at uu.net
Tue Feb 8 16:11:32 EST 2011
Lee,
I am starting a new thread, as your existing thread got polluted with a
conversation about the need to protect consumer end-sites from in-bound
sessions, and if that can only or best be accomplished with NAT or
statefull firewall (with no DPI), or if DPI is required to explicitly
permit or block certain tyraffic.
If I understood your email you were asking a different question.
Can we transition from IPv4 to IPv6 without widespread dependence on NAT
as a translation technology?
A decade ago IETF suggested that all IPv4-only systems should dual-stack
prior to the depletion of IPv4 addresses, and the deployment of the first
IPv6-only network. In that case there is no transition problem.
At the moment a vast majority of the Internet facing content is IPv4-only.
This is a result of two things; 1. a chicken and egg problem, where the
end-sites don't feel a need to go dual-stack, as there is no IPv6-only
content, and the content provider don.t feel a need to go dual stack as
there are no IPv6 users. 2. There is real cost and risk involved in
deploying IPv6 with no new products, services, capabilities, or revenue.
As such it is in a company's best interest to defer the added cost of
deploying IPv6 until the last moment.
Now is the time to see if everyone planned accordingly, and started in
time. If there is a rapid wide spread IPv4 / IPv6 dual-stack deployment
(I mean end systems can use both protocols equally well regardless of the
technology leveraged) then this will drive content providers and
application developers to support IPv6 in a real way. If all of this can
happen in the time period between IANA depletion and when the first
organizations are forced to build green field IPv6-only networks, then
dependance on NAT can be mostly avoided as a protocol translation
mechanism.
Is likely that 100% of the content will be dual-stacked or even most of
the important content? That question misses the point. To the extent
that we are successful with getting content dual-stack prior to
organizations being forced to deploy IPv6-only networks, we *minimize* the
amount of dependence (and hence pain) of IPv4 / IPv6 NAT style
translation.
Is it likely we will all be forced to deploy some flavor of IPv4 / IPv6
NAT style translation? That question misses the point, see above, but
yes. To the extend that we don't want to turn away new customers that
refuse to upgrade their hw / sw to support IPv6, we will have to deploy
some flavor of translation. The important point here is the people that
feel the pain of the poorly operating translation services are the people
who refuse to upgrade. When the pain of poor performance outweighs the
pain of upgrading the problem will resolve itself.
__Jason
==========================================================================
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Public IP Global Network Engineering schiller at uu.net
UUNET / Verizon jason.schiller at verizonbusiness.com
The good news about having an email address that is twice as long is that
it increases traffic on the Internet.
On Sun, 6 Feb 2011, Lee Howard wrote:
|Date: Sun, 06 Feb 2011 08:36:02 -0800 (PST)
|From: Lee Howard <spiffnolee at yahoo.com>
|To: Benson Schliesser <bensons at queuefull.net>, Owen DeLong <owen at delong.com>,
| Ted Mittelstaedt <tedm at ipinc.net>
|Cc: arin-ppml at arin.net
|Subject: [arin-ppml] inevitability of NAT?
|
|
|
|> From: Benson Schliesser <bensons at queuefull.net>
|
|>
|> Sadly, because we've waited too long to grow IPv6 penetration to
|> the inflection point ("the moment that end users start accepting and
|> using IPv6"), people will still need to deploy IPv4. Vendors will
|> make money on NATs. And people will find ways to get addresses
|> - one way or another.
|
|This is often asserted and generally accepted. Is it true?
|
|Nobody wants NAT: ISPs, content providers, law enforcement,
|copyright holders, game console manufacturers, web advertisers,
|home gateway vendors, and end users all have an interest in
|avoiding NAT. Even NAT vendors are decorously sheepish in
|selling their products. If everyone wants to avoid it, why are we
|stuck with it?
|
|1. ISPs aren't ready for IPv6. This belief is rapidly being
|overtaken by events--most ISPs will have broad IPv6 this year.
|2. Content isn't ready for IPv6. This belief is rapidly being
|overtaken by events. World IPv6 Day is a test-drive of content,
|which should go a long way toward eliminating barriers.
|3. Home gateways aren't ready for IPv6. This belief is
|slowly being overtaken by events. All home gateway makers
|are developing IPv6, and industry is doing better as telling them
|what needs to be fixed. However, it may still be true that all
|home gateways sold before ARIN runout have to be replaced.
|4. Consumer electronics aren't ready for IPv6. This is widely
|true, although more embedded OSs are becoming IPv6-capable.
|Most web-capable devices will be capable of simple firmware
|or OS updates. Untraditional networked devices (like
|entertainment systems) are in trouble.
|
|How do we improve IPv6 uptake in these categories?
|
|If all of a household's devices speak IPv6, and the ISP provides
|IPv6, and all of the content the household accesses is available
|over IPv6 (including NAT64), that household no longer needs
|IPv4.
|
|What would it take for the number of households in that state
|to increase faster than new Internet activations? Think big--
|there are a lot of stakeholders whose interests align against
|NAT.
|
|Lee
|
|
|
|_______________________________________________
|PPML
|You are receiving this message because you are subscribed to
|the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
|Unsubscribe or manage your mailing list subscription at:
|http://lists.arin.net/mailman/listinfo/arin-ppml
|Please contact info at arin.net if you experience any issues.
|
More information about the ARIN-PPML
mailing list