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

[Robin Whittle <rw@firstpr.com.au>]

Hi David,

You wrote:

> [This is going a bit far afield from routing research topics, so it'll
> be my last message on this thread]

OK, I will try to wind up too - though I think it is pertinent,
given that the question of IPv6 adoption is absolutely central to
any discussion about the future of the Internet, and due to my
understanding of the rough RRG consensus involving the assumption
that IPv6 adoption will occur soon enough and thoroughly enough to
make the IPv4 scaling problem not worthy of our primary focus.


>>> Since IPv6 currently uses the same routing technology as IPv4, the
>>> _Internet_ has a routing scalability problem.
>>
>> These are two separate Internets.
> 
> Yes they are two separate Internets, but they are sharing the same
> underlying resources (routers, bandwidth, engineers, etc).

I agree.

>> I think the benefit of fixing IPv4 routing is primarily that a
>> billion or more people can continue for the foreseeable future using
>> the Internet the way they do today.
> ...
>> There is no prospect of moving everyone to IPv6 as far as I can see
>> - it is too disruptive.
> 
> Again, I'd argue a billion or more people simply don't care if they're
> using IPv4 or IPv6.  What they care about is getting to the services and
> content they want/need.  

Yes, and IPv6 alone does not do this for them.  There is no prospect
in the foreseeable future for every significant application to be
rewritten or all the world's websites, game servers etc. made to
operate over IPv6 too.

That leaves everyone dependent on IPv4.  "Dual Stack Lite" seems to
be the most developed Western plan to give people IPv6 and reduce
their demands on the IPv4 address space.  However it is at the early
planning stages and if and when it is developed and deployed it will
not suit some significant subset of users and so will be hard to
market.  "Dual Stack Lite" doesn't really do much to encourage IPv6
applications, services etc. but at least it would boost the
currently small number of people who have native IPv6 connectivity.


> As I mentioned in my previous note, I suspect
> the best case scenario we're looking at right now is for ISPs migrate
> their own infrastructure over to IPv6 (tunneling IPv4 from customer to
> edge through that IPv6 infrastructure), thereby allowing them to reuse
> any IPv4 addresses they've used for internal infrastructure for customer
> assignments.  

Yes - it would be interesting to know how flexibly and efficiently
large and small ISPs assign their IPv4 addresses to active
customers, such as home, SOHO etc. mass-market end-users.


> This has the side benefit of allowing the ISP to provide
> IPv6 connectivity to their customers at no (significant) additional
> cost.  The economic incentives for an ISP to migrate their
> infrastructure to IPv6 would come from avoiding the cost of obtaining
> more IPv4 address space.  

However, I can't see it would be a cost-saving approach.  The ISP
would need to spend a lot of money buying, installing, managing,
maintaining and powering the shelves full of COTS boxes or racks of
blade servers or whatever which implement the special "carrier grade
NAT" IPv6-aware NAT arrangements by which multiple customers share a
single IPv4 address.

> "Dual stack lite" is a variation of this,
> adding in the ability to do "carrier grade NAT" within the ISP
> infrastructure. While some percentage of the existing customer base
> won't like the implications of carrier-managed NAT, there will likely be
> (extra cost) options that will keep those customers mollified.

I agree.

> Of course, one of the problems with this scenario is that the IPv6 being
> deployed is straight "Deering IPv6", which means there will be more
> "vast installed base" that will need to be dealt with if/when a scalable
> IPv6 architecture is developed.  Oh well.

Yes, but it is not a big fuss to change every customer's /64 address
just once sometime in the future - if that is necessary to make
these IPv6 prefixes part of the new scalable routing and addressing
system.

I don't assume that this would be necessary.  The IPv6 prefixes
Comcast already have are presumably large slabs of space, and it
will be fine to keep them and continue to give each HFC cable modem
customer a /64 of it or whatever, on a PA basis.

My view of portable, multihomable, end-user space in a future
scalable routing and addressing system is that it doesn't come from
your ISP.  You get it by renting space from some stable outfit which
 probably has nothing to do with your current ISP.  Then, you can
use that space through one or many ISPs, as you choose, anywhere in
the world, indefinitely.

So Comcast could keep its current prefixes for its cable modem
customers, and if any of them wanted to multihome, they would tunnel
from their current prefix to the nearest ETR, or Comcast could
organise some special routing link from that ETR, and allow the
customer to emit packets with source addresses matching their own
micronet / EID prefix.

I think a more likely scenario would be that the customer runs a
bi-directional tunnel from their cable modem /64 address to an ETR
somewhere - but this is not just an ETR, it is also a router which
can forward packets from the micronet address space to the rest of
the Net.  This now looks almost identical to the TTR (Translating
Tunnel Router) model, but without the frequent mobility.

  http://www.firstpr.com.au/ip/ivip/#mobile

For instance I have a single fixed IPv4 DSL address, but it wouldn't
matter if it was dynamically assigned.  I could get a dynamically
assigned cable modem service, IPv4 at present.  Both services could
have static or dynamically assigned IPv6 addresses in the future,
and perhaps no IPv4 addresses.

I would rent micronet space (IPv4 and/or IPv6) from some company and
my DSL and HFC ISPs would hopefully have TTR-style ETRs (of the
correct IPv4/6 flavor) in their networks.  I would tunnel to those
two TTRs and be happily mulithomed.  If there were no TTRs in these
networks, I would tunnel to one or two TTRs from a TTR company
(maybe two TTRs, each from a different TTR company), in the same city.

For big, static, end-user networks it would be different.  They
would make specialised arrangements with fibre links to two or more
ISPs and link directly into each ISP's ETRs.  Each ISP would know to
accept outgoing packets from the end-user network's micronet address
space, which wouldn't directly involve the ETR.

However for home and SOHO users who want to multihome, I think the
TTR model would be the only feasible approach, since it would be too
much fuss for the customer and the ISP to make special technical
arrangements about routing packets back and forth along a particular
DSL or cable modem service, where those packets are to and from some
address space the ISP has no relationship with.


>> I stand by all my arguments against the notion that ISPs will start
>> disconnecting their networks from certain portions of the Net, due
>> to marginal expense problems with running DFZ routers, due to desire
>> to urge people to use IPv6 or for any other purpose.
> 
> I'm not suggesting ISPs will filter for any other reason than
> self-preservation.  ISPs will filter out longer prefixes when they see
> their infrastructure at risk.  

I am suggesting it will be cheaper to buy new routers than to try to
replace the customers they would lose by not connecting them as
fully to the Net as competing ISPs.

> Having routers fall over, try to get back
> up, and fall over again is not a lot of fun for anyone involved. Given
> unconstrained routing system growth as implied by current policies and
> technology and no deployable alternative, I'm not sure what other
> options there are.

I think the first option is bigger routers.  Then, in the longer
term, a greater impetus for a scalable routing and addressing system
for both IPv4 (urgently) and IPv6 (ready for some time in the future
when IPv6 is widely used).

  - Robin


--
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