On 4/10/2007, at 11:07 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I haven't dug too deep into NAT-PT, but an obvious question comes to mind: Why would an ISP deliver an IPv6-only connection plus NAT-PT (and all the likely problems) with a surcharge for IPv4 instead of delivering RFC1918 IPv4 + NAT with a surcharge for routable IPv4?
Why is it an either/or situation? Given the fact that PC's have supported IPv6 for quite a while now
<crazy rambling> This last sentence (fragment) with NAT-PT above it made me ponder a bit. NAT-PT and whatever other solutions we're considering are all aiming to give transparent access to hosts on the IPv4 network from hosts on the IPv6 network (or vice-versa). It probably doesn't have to be so transparent - why couldn't there be some kind of NATv4-over-v6 hack that let it happen? Would GRE (over v6) with DHCP, and NAT on the concentrator work? Maybe L2TP (over v6) or something? OSes don't support this now (as I just pulled it out of thin air), but there's no reason they couldn't be made to, or something like it. Upside down Teredo + NAT. Sure it means we have to have NATs in the way - but as many people have suggested, NAT is an existing issue for most applications, and they work around it just fine. The advantage of doing this as opposed to handing customers' CPEs RFC1918 addresses is, they can do end-to- end over v6 if they want to. </crazy rambling> One does wonder if doing IPv6 and RFC1918 IPv4 at the same time might be easier. Do the IPv6 PPP things let you run IPv6 and IPv4 at the same time? (Maybe not RFC1918, maybe take a single non-RFC1918 /24 and assign those addresses to customers, and then re-use that /24 many many times, each behind a different non-RFC1918 address. To avoid address conflicts with people who NAT their address, etc.) The difference between the two things above is that the former is single NAT, the latter is double. The former is much more complicated, though. -- Nathan Ward