[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