[arin-ppml] 464: was (Re: IPv6 adoption, map-encap for IPv4?)

[John Paul Morrison]

Wow - I recall speculating that broadband providers would eventually 
move to NAT IPv4, but I didn't think they were already doing it (or that 
it was imminent).

I saw that as a negative - that the providers would recoup routable IPv4 
space and charge a premium for it as IPv4 becomes more scarce. And I 
suppose there's nothing stopping that.
I was also more pessimistic in assuming they would simply put up carrier 
grade NATs to extend IPv4 address resources, without  really providing a 
path for IPv6. Probably nothing stopping other providers from doing that 
either, if they're betting IPv6 deployment isn't worth the effort.

Does Comcast provides native, routable IPv6 addresses to those who want 
them? If so, that would seem to provide some incentive to take advantage 
of IPv6 as it becomes more widespread.
I wasn't clued into this when Paul talked about the gamers and 
peer-to-peerers getting better performance out of IPv6.

This strategy does seem to be the most plausible I've yet seen for IPv6 
rollout.  It would seem that if IPv4 addresses become valuable in the 
IPv4 end-game, Comcast wins or at least breaks even by freeing up and 
redeploying IPv4 addresses. If IPv6 wins out, Comcast is obviously in a 
good position. A broadband carrier who bets against IPv6 could win if 
IPv4 addresses go up in value and IPv6 doesn't take off; but they face 
the looming risk that if it does, they'll be at a disadvantage.


On 6/13/2008 9:30 AM, Alain Durand wrote:
> The idea is that the home gateway will be provisioned on the WAN with only
> IPv6 and will run DHCPv4 with 192.168.0.0 on the LAN side.
> Now, instead of translating outgoing IPv4 packets, it will forward them
> unchanged inside of an IPv6 tunnel which endpoint is somewhere within the
> service provider network. That endpoint will decapsulate the packet and
> translate the original IPv4 packet to use a global IPv4 source address. Of
> course, that carrier grade NAT will have to use the IPv6 tunnel src address
> as part of its mapping table instead of the IPv4 address of the original
> packet.
>
> That way, there is effectively only one level of NAT. Manual port forwarding
> cannot be supported, of course. We are now studying what is the impact on
> p2p protocols and uPNP.
>
> Note: It is actually possible to run a 464 client on a stand alone device
> (ie not behind a home gateway) that is connected only with IPv6. That device
> pick up any random or well know IPv4 src address (even 127.0.0.1 could
> work), figure out the IPv4 destination (resolve A records over IPv6 DNS),
> and ship the packet over the 464 tunnel. That way, you can run v4 apps,
> browse the v4 Internet, all that on a v6-only configured device...
>
>   - Alain.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>