On Fri, Mar 05, 2010 at 12:39:19PM +0000, bmanning@vacation.karoshi.com wrote:
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. Suzanne
On Fri, Mar 05, 2010 at 03:21:53PM +0000, Suzanne Woolf wrote:
On Fri, Mar 05, 2010 at 12:39:19PM +0000, bmanning@vacation.karoshi.com wrote:
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. imho of coure ... YM (and business models) MV --bill
Suzanne
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. Owen
On Fri, Mar 5, 2010 at 10:16 AM, Owen DeLong <owen@delong.com> wrote:
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.
I think that will be fairly easy to deprecate over time vs. many many edge-NATs and layers of NATs near the edge.
Owen
participants (4)
-
bmanning＠vacation.karoshi.com -
Cameron Byrne -
Owen DeLong -
Suzanne Woolf