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

Re: Follow-up work on NAT-PT

Brian, perhaps we need to better understand the reasoning behind the request and what "real estate" mean?
I'd like to think there is a day that IPv4 can be retired from a service provider's network. It is not necessarily the dual-stack nature of the access network that will increase the cost, but the amount of NAPT that may need to occur within the service provider to continue v4 ops in a address-depleted environment. During transition period there will be dual-stack and eventually v4-NAPT (for at least some customers). 

My view is that:
- During transition dual stack should be what every new device supports (ie, IPv6-only stacks is a bad idea during the transition period) 
- During transition we will see a move from IPv4 towards IPv6
- We should support connectivity for legacy clients as best we can until transition is complete
So, the last point is most interesting - support the legacy customer base. These are the customers who have not got devices that are dual- stack or who are accessing services/servers that are not yet IPv6- enabled. With 79% of the market running Windows XP (Net Applications Oct 2007) we need to consider how to transition the bulk of our customers to IPv6. The methods are (in order of preference from the Service Provider's perspective): 
- Enable IPv6 in their existing OS
- Upgrade to a new OS
- Translation (along the lines of NAT-PT or the NAT46 component of draft-durand-ngtrans-nat64-nat46)
Translation of any kind should be last resort, but this is where I'm interested to get thoughts on NAT-PT revival for an IPv4-only host OS contacting an IPv6 server (with the same limitation as today's IPv4 NA(P)T. I'm assuming that one day IPv4 resources will be too impractical (cost) to obtain so some business may be faced with IPv6- only connectivity for _servers_. Does anyone else think there may be a day when IPv4-only clients may exist (through provider NAPT) and because of v4 address shortages running a server on a well known port (http) may be restricted to IPv6 - to me this is a case for NAT46/NAT- PT - but its anyone's guess whether this day will come. 

-d


On 11/11/2007, at 3:12 AM, Christian Huitema wrote:
I don't think that we need to optimize for IPv6 only hosts. In practice, we can expect that IPv6 capable hosts will either be dual stack. Device designers will want to accommodate situations where their device connects to either an IPv6 network, or an IPv4 network. Implementing "dual stack" is not much harder than implementing "IPv6 only", so this is pretty much a no-brainer.
We need to optimize for reliability and operation support. There, we have to reconcile the tension between two goals: networks are simpler and easier to operate if they support one protocol instead of two; and, networks are simpler if they do not rely on complex and error prone gateways.
Is it really more efficient for an ISP to operate an IPv6 only network? If it is, then IPv4 services will have to be provided through some kind of overlay. On the provider side, the overlay will have connect to some IPv4 "gateways" that give access to the global IPv4 service. On the client side, the overlay will extend either all the way to the client itself, or terminate at the "access router".
If we just want to reuse old technology, the overlay can be built with simple tunnels. Access routers routinely support protocols like PPPoA or PPPoE. PPP over IPv6 (PPPo6?) would not be much of a stretch. It would also not look to strange on the ISP side, since after all ISP are quite used to support PPP servers.
If we don't like the hub and spoke nature of PPP, we can of course be creative and build the overlay with some form of automatic tunneling. But I am not sure that the automatic tunneling will actually reduce operation costs, or increase reliability. 

-- Christian Huitema