Creating demand for IPv6
Nathan Ward
nanog at daork.net
Fri Oct 5 03:46:36 UTC 2007
On 4/10/2007, at 11:07 PM, <michael.dillon at bt.com>
<michael.dillon at 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
More information about the NANOG
mailing list