[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem statement, was: Re: Follow-up work on NAT-PT



On Nov 12, 2007, at 11:31, Gert Doering wrote:
So what's your approach to handling the "there won't be any new  
IPv4 addresses to distribute to customers after a not-so-far- 
distant point in the future"?
Reduce, reuse, recycle.

I'm fairly serious about this - we *will* run into this, and so far, IPv6 seems to be the only solution. No matter how many rough edges it has today.
I'm deadly derious about this too.  If customers demand to use IPv4  
when addresses are in short supply, then I'm sure markets (or  
alternative mechanisms) will find prices for exchanging used  
addresses at which transactions will clear.
If network operators continue not deploying IPv6 services, then  
customer demand for IPv6 service will be met increasingly by tunnels  
over the existing IPv4 infrastructure between endpoint nodes.  This  
is happening today with dual-stack nodes.  The problem before us is  
how to make it happen with IPv6-only nodes.
Some organizations are likely to deploy IPv6-only networks in the  
coming years for reasons mainly unrelated to IPv4 address shortages.   
They will almost certainly end up using some combination of SIIT and  
whatever follows from the work on NAT-PT as their gateway to the  
legacy IPv4 public internet.  The less the IPv4/NAT-based ISP  
community knows about that, the *better*, if you ask me.  If all that  
traffic looks to them exactly like the IPv4/NAT traffic they know and  
love today, all the better.  It keeps them from mucking with things  
that don't belong to them.
Administrators of those gateways between legacy IPv4 and local IPv6- 
only networks will probably need to care about how such gateways  
work, so I think V6OPS is a good place for discussions to that end.    
That said, I disagree with Mr. van Beijnum: it is not an  
*operational* problem that ISP's are not deploying IPv6 service.  It  
is, one could argue, a crude solution to an otherwise thorny problem,  
i.e. how to make the operator community feel warm and comfortable in  
the face of the IPv6 autoconfiguration architecture being difficult  
for them to understand and control.

--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering