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

Re: Enhanced SIIT

Nathan,

Nathan Ward wrote:
The approach of using some kind of proxy was proposed, and that's my preferred solution at this stage if some kind of IPv6 host to IPv4 host scheme is deemed needed - the drawback is that it doesn't allow IPv4 hosts to establish new connections to IPv6 hosts, only IPv6 -> IPv4. While it's my preferred solution, I'm still on the fence as to whether it's worth doing. As an aside, this might be easier if TCP and UDP ports for most applications didn't have default values..
My solution to one day not having IPv4 addresses to assign to end users (home broadband/dial users) right now, is to run dual-stack, where the v4 part of the stack is NAPTed. It's not ideal, as users are going to be double NAPTed if they have their own unit doing it at home, but it won't prevent them from getting to regular content providers which is the the first requirement from my POV.
At least one carrier that I am aware of is currently looking closely at an approach similar to yours.
Essentially, they are looking at dual-stacking the broadband access platforms to support IPv4 and IPv6 to the CPE[1]; then enabling their data centers and infrastructure for IPv6 support for their networks (eg. AAAA responses only to their customers). At the same time, an infrastructure deployment plan and architecture is developed for service-provider wide IPv4 NAPT.
At 'd-day' for IPv4 exhaustion, the infrastructure is in place to support service provider wide IPv4 NAPT which allows the SP to continue supporting single and dual stack customers. There are the obvious problems with dual/multi NAT layers[2]. The customers can access IPv6 enabled content locally if they are dual stack to their desktop; as well as native IPv6 content on the wider Internet. The SP also sees the opportunity to perhaps recover v4 addresses from legacy plant (dialup or whatever), and use these to provide an up-sell to a 'static IPv4 /32' if you want a real address. The product evolution here is likely to be that you pay a premium for a real v4 address where the SP can allocate it, and a reduced amount for NAPT v4 address.
The CPE[1] must support 4-to-6 NAT-PT of some kind. There is no planned facility for 6-to-4 NAT-PT as any host which is IPv6 enabled should also be IPv4 enabled and can get access to exclusive v4 resource through the SP-NAPT in place. Allowing for all the legacy IPv4 only hosts that customers may run to access IPv6 resource through the CPE seems to be a suitable approach.
This seems to be a reasonably pragmatic approach to the problem, but of course it requires the "big SP-NAPT" box and the development of a NAT-PT standard. 

aj.
[1] For this case, the Service Provider dictates the CPE use and manages it. Using 240/4 for this "private IPv4 infrastructure" could well work as all devices are modern and SP controlled. [2] There is the possibility for NAT evolution here to support the concept of uPNP across network boundaries. This is somewhat dependent on being able to trust the CPE, but given [1] this is less of a problem.