There are several IPv4/IPv6 co-existence technologies under
development that attempt to resolve the asymmetry Bill notes here,
where IPv4 addresses are already scarce and IPv6 addresses may
reasonably be treated as less so. They include IVI, NAT64/DNS64, and
dual-stack lite.
See for example the lightning talk last Wednesday in Austin on AFTR,
ISC's free, open source implementation of dual-stack lite, or the
panel discussion at APRICOT earlier this week.
It's only been in the last couple of years that the IETF and the
vendors have been taking seriously the problem of moving IPv4-IPv6
co-existence mechanisms into the network, away from host-based
dual-stack and into use cases where legacy infrastructure has to
co-exist with the need for growth. But now that they have, there's an
embarrassment of what we can hope turn out to be riches in this
area....or at least a pony amongst the, err, bulk of material.
> er... what part of dual-stack didn't you understand?
> dual-stack consumes exactly the same number of v4 and v6 addresses.
>
> if you expect to dual-stack everything - you need to look again.
> either you are going to need:
>
> lots more IPv4 space
>
> stealing ports to mux addresses
>
> run straight-up native IPv6 - no IPv4 (unless you need to talk to
> a v4-only host - then use IVI or similar..)
>
> imho - the path through the woods is an IVI-like solution.
There are several IPv4/IPv6 co-existence technologies under
development that attempt to resolve the asymmetry Bill notes here,
where IPv4 addresses are already scarce and IPv6 addresses may
reasonably be treated as less so. They include IVI, NAT64/DNS64, and
dual-stack lite.
See for example the lightning talk last Wednesday in Austin on AFTR,
ISC's free, open source implementation of dual-stack lite, or the
panel discussion at APRICOT earlier this week.
It's only been in the last couple of years that the IETF and the
vendors have been taking seriously the problem of moving IPv4-IPv6
co-existence mechanisms into the network, away from host-based
dual-stack and into use cases where legacy infrastructure has to
co-exist with the need for growth. But now that they have, there's an
embarrassment of what we can hope turn out to be riches in this
area....or at least a pony amongst the, err, bulk of material.
there is a real danger here ... wholesale adoption of a
translation technology, esp one that is integrated into
the network kind of ensures that it will never get pulled out -
or that the enduser will have a devil of a time routing around
it when it no longer works for her - but the ISP sees her as a
statistically anomaly.
I would argue that the right/correct place for such translation
technology is very close to the edge - in much the same way as
NAT technology is roughl an "edge" technology. (ok - it used to be but w/
CGN .. its clearly moved.
we -need- the technologies - but only for a while. otherwise they
become a drug that we are dependent on. and we will be stuck on the
dual-stack plateau for a much longer time that we should.
there is a real danger here ... wholesale adoption of a
translation technology, esp one that is integrated into
the network kind of ensures that it will never get pulled out -
or that the enduser will have a devil of a time routing around
it when it no longer works for her - but the ISP sees her as a
statistically anomaly.
I would argue that the right/correct place for such translation
technology is very close to the edge - in much the same way as
NAT technology is roughl an "edge" technology. (ok - it used to be but w/
CGN .. its clearly moved.
we -need- the technologies - but only for a while. otherwise they
become a drug that we are dependent on. and we will be stuck on the
dual-stack plateau for a much longer time that we should.
imho of coure ... YM (and business models) MV
Bill,
While the DS-LIte mechanism does involve moving the NAT
towards the Core instead of leaving it at the edge, the advantage
is that you can route around it very easily as an end-user. Every
thing the end user sends to an IPv6 destination bypasses the NAT
box completely and only IPv4 is afflicted.
I think that will be fairly easy to deprecate over time vs. many
many edge-NATs and layers of NATs near the edge.
there is a real danger here \.\.\. wholesale adoption of a
translation technology, esp one that is integrated into
the network kind of ensures that it will never get pulled out \-
or that the enduser will have a devil of a time routing around
it when it no longer works for her \- but the ISP sees her as a
statistically anomaly\.
I would argue that the right/correct place for such translation
technology is very close to the edge \- in much the same way as
NAT technology is roughl an "edge" technology\. \(ok \- it used to be but w/
CGN \.\. its clearly moved\.
we \-need\- the technologies \- but only for a while\. otherwise they
become a drug that we are dependent on\. and we will be stuck on the
dual\-stack plateau for a much longer time that we should\.
imho of coure \.\.\. YM \(and business models\) MV
Bill,
While the DS-LIte mechanism does involve moving the NAT
towards the Core instead of leaving it at the edge, the advantage
is that you can route around it very easily as an end-user. Every
thing the end user sends to an IPv6 destination bypasses the NAT
box completely and only IPv4 is afflicted.
NAT64/DNS64 is the same way, it gracefully drops out of the network as
more and more content provides publish their own AAAA records. Most
mobile providers today do NAT44, so NAT64 from an IPv6-only host
(phones) is very appealing and familiar The day we switch from NAT44
to NAT64 (it's not a flag day, one new device model at a time), we
will have a substantial NET savings in NAT state since all the IPv6
content folks with AAAA will no longer have their content hobbled by
the NAT44 that exists today. Mobile network operator will begin to see
the light at the end of the NATx(x|y) tunnel. The end of the NAT
tunnel means lower cost and higher availability.
And once again, the content folks passing IPv4 literals may have
heart burn since IPv6-only won't initiate a connection to an IPv4
literal address embedded in HTML / XML .... DNS64 helps with this in
the normal FQDN case, but passing IPv4 literals breaks the model and
communications fails.