[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] NAT-PT and other approaches to IPv6 adoption



[Apologies for the length]

Robin,

On Jun 10, 2008, at 6:28 AM, Robin Whittle wrote:
Is there a test-bed showing how IPv6-only services can be
implemented such that ordinary end-users would pay for such a
service when they could also choose an ordinary IPv4 service?

The vast majority of end users don't care about IPv4 or IPv6. They buy "Internet service" and assume what their ISP gives them works with the devices they use to get their work done/surf their pr0n. If the end user is unable to get their work done/surf their pr0n, they will call their ISP and complain. As such, I imagine deploying IPv6 to end users right now is actually dis-incentivized, particularly at larger ISPs due to the costs associated with customer complaints.

I don't see how
the RRG can assume that IPv6-only adoption and consequent migration
from IPv4 will happen anything like soon enough that the IPv4
routing scaling problem doesn't need to be solved.

I don't believe RRG is assuming IPv6-only. I believe RRG is assuming dual-stack with (at least) a more scalable IPv6 routing infrastructure that may also be applicable to IPv4.

My personal view is that it is _extremely_ unlikely any non-trivial technology change can be deployed that significantly alters the IPv4 infrastructure in any reasonable timeframe. Instead, what we'll see is incremental, evolutionary improvements along the lines of bigger/ faster/more expensive routers, additional filtering mechanisms, FIB compression, BGP enhancements, etc., along with vastly increased use of NAT.

At this point, what I suspect is a realistic best case scenario (ignoring mandates and special communities like cell phones):

Assume:

1. increased cost in obtaining IPv4 addresses due to the IPv4 free pool runout.

This will naturally drive:

2. increased IPv4 address space utilization efficiency

which includes

3. deployment of IPv6 internally within ISP infrastructures so that any IPv4 addresses used in those infrastructures can be re-purposed to revenue generating customers (with IPv4 tunneled through IPv6)

and

4. increased deployment of IPv4 NAT (including multi-layer NAT), e.g., only offering customers a single dynamically-assigned public IPv4 address

with (3) enabling:

5. IPv6 connectivity being provided to end users (since it would be essentially zero cost, assuming the CPE supports it)

and (4) encouraging:

6. IPv6-only use since NAT tends to be challenging for lots of applications people are increasingly tending to use (e.g., P2P).

I'd argue (1), (2), and (4) are extremely likely regardless of what the future might hold. (3) is a bit of a reach, but hopefully ISPs will see it in their best interests to go the IPv6 route instead of the RFC 1918 IPv4 route to do this. The big question marks are (5) and (6). It may be that ISPs can't rationalize providing an "additional service" without charging more for it or that people apply more and more hacks to make NAT more palatable. However assuming this fanciful scenario pans out, at this point, you have IPv6-enabled end users and IPv6-enabled transport.

What is (and has always been) missing is IPv6-enabled content. One possible scenario to address this: as IPv4 continues to get sliced and diced, ISPs will be forced to start deploying more and more draconian filters in order to keep their routers from falling over/converging in reasonable timeframes. As more filters are deployed, content providers will begin to see reductions in customers and thus will be incentivized to provide IPv6-only content.

So, if you buy into this scenario, fixing IPv4 routing would actually be detrimental to moving to IPv6 as there would be no observable loss of customers to content providers to drive them to spend the money to deploy IPv6. A bit of a reach, I know. However if somehow you do fix IPv4 routing, all you would be enabling is the increased use of NAT -- there simply is not enough IPv4 address space to meet projected demand without NAT. While I am not particularly a NAT-hater, I dislike the direction it tends to lead (e.g., walled gardens).

Regards,
-drc




--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg