[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.