On 9/28/07 10:55 AM, "michael.dillon@bt.com" <michael.dillon@bt.com> wrote:
It is also becoming apparent that:
- the "core internet" (ie the web and any infrastructure server) will take a long time to move to v6 and/or dual stack.
- new v6-only edges will have to communicate with it. So we need v6->v4 translation in the core
Some companies have implemented MPLS in the core, therefore they can easily add IPv6 services by configuring 6PE on a couple of PE routers in each PoP. Beyond the PoP, in the customer's network, they can do pure IPv6 if that is what they want.
The issue is not the transport of v6 packet over the network(s) in the middle, but the servers and the applications at the other side who may remains IPv4. In other words, transition to IPv6 is not so much a L3 issue, but a L7 one.
- legacy v4 PCs (think win95 up to win XP) using RFC1918 addresses behind a home gateway will never be able to upgrade to an IPv6-only environment. So if we provision the home gateway with v6-only (because there will be a point where we do not have any global v4 addresses left for it) those legacy PCs are going to need a double translation, v4->v6 in the home gateway and then v6 back to v4 in the core.
Not if they use an application layer proxy in their gateway. It's not too late to specify this as a standard function for an IPv6 Internet gateway device. Also, the "v6 back to v4" conversion could be handled in an information provider's data center (Google, CNN) not in the core.
If you put a proxy on the home gateway that is provisioned with v6 only on the wan side, you will have to proxy to a v6 destination. If you go back to my previous point, the destination may be a v4 address.... Thus a home gateway only solution cannot work, it needs to translation back to v4 somewhere in the network. That said, I used the word "core" a bit generously, and I agree with you it could be done within a datacenter if you were willing to pay the cost of the extra round trip to that datacenter. - Alain.