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

From: Robin Whittle <[email-masked]>
Date: Fri, 01 Aug 2008 18:48:24 +1000

I am replying to the 2008-06-11 messages from David Conrad and Tony Li:

  http://psg.com/lists/rrg/2008/msg01474.html
  http://psg.com/lists/rrg/2008/msg01483.html

who were responding to my message:

  http://psg.com/lists/rrg/2008/msg01467.html

At the end I discuss a new I-D from Alain Durant on the "Dual Stack
Lite" approach to providing IPv4 connectivity via a special NAT and
an IPv6 access network.

David Conrad wrote:

> [Apologies for the length]

I think your message was not very long.  Sorry for my delay in replying.

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

"pr0n"?  OK: http://en.wikipedia.org/wiki/Leet =="porn"

I agree.

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

Yes - I understand a single support call or complaint can wipe out
months of slender profits for that one customer.

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

Dual-stack doesn't help the IPv4 routing scaling problem at all.
Every end user still needs an IPv4 address.

Only when large numbers of end-users are on IPv6-only services -
including perhaps a service which uses special NAT arrangements to
share one IPv4 address with multiple end-users - will IPv6 be able
to help reduce the IPv4 scaling problem.

In mid-June the only plans I could find for this kind of
"concentrated NAT to IPv4" service were from Alain Durand:

  http://lists.arin.net/pipermail/arin-ppml/2008-June/thread.html
  IPv6 adoption, map-encap for IPv4?

  http://tools.ietf.org/html/draft-durand-v6ops-v4v6v4nat-00
  (2007-11-12)

Which I summarised as:

  Alain Durand's Comcast "464" plans are of interest to the
  question of adoption of IPv6-only services, which I think the
  RRG rough consensus involves some assumptions about.  464
  uses the IPv6 access network to tunnel IPv4 packets to a
  special kind of NAT.

  The result is each customer gets their own private IPv4 address
  space (such as 192.168/16) and has a single layer of NAT in the
  remote NAT box.  Manual port forwarding cannot be supported, so
  uPnP IGD can't be used - with consequent impact on P2P and
  probably other apps.

  So this would not really be an IPv6-only service - for most
  users it would be a NATed IPv4 service like what they get now,
  but without the possibility of grabbing a port to receive
  packets from a stable public IPv4 address.

This is clearly unsuitable for many customers who make extensive use
of Bittorrent etc.  I assume that P2P applications only work
properly when they can use uPnP IGD to get a public port so they can
accept incoming communications from other such programs.

Without your own P2P program being able to serve data to other
users' programs, I understand it gets a low score and does not work
very well for downloading files.

I don't see how such a service could be marketable, since it does
not suit a significant proportion of end-users.  The marketing would
have to be very careful so as not to promise too much.   Yet some
customers would still adopt the new service and be upset when it
doesn't do all the things an ordinary service does.

This approach would help reduce the routing scaling problem by
serving more end-users on less IPv4 addresses.  However, I can't see
how it could be successfully marketed as long as the customers could
choose an ordinary IPv4 service instead.

I believe there is a lot of scope for better utilization of IPv4
space, so I think we are a long way from the state of affairs where
Comcast and their competitors can't scrape together enough space to
offer the service that people are used to getting.

The latest version of the "464" proposal is "Dual Stack Lite":

  http://tools.ietf.org/html/draft-durand-dual-stack-lite-00
  (2008-07-07)

My analysis of Dual Stack Lite is at the end of this message.

My conclusion is that this sort of service is going to be difficult
or impossible to sell as long as customers can choose between it and
a competing service with a unique IPv4 address.  I think that it
will be a long time - a decade or more, perhaps never - before IPv4
space is really so expensive to obtain that Comcast or any other ISP
would find it more profitable to invest in a second-rate service
like Dual Stack Lite, compared to simply paying market prices for
IPv4 space.

Even if it is widely deployed, a service such as this doesn't do
much to wean people off IPv4 applications and websites etc.  The
native IPv6 connectivity would be good for IPv6 Bittorrent and
perhaps games - so it would make it more likely that "critical IPv6
mass" would be achieved in these areas.

Back to the RRG and what you wrote:

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

The rough consensus is:

   http://psg.com/lists/rrg/2008/msg01535.html  2008-06-13

      Our recommendation should be applicable to IPv6.

      It may or may not also apply to IPv4, but at the
      very least must provide a path forward for IPv6.

The IPv4 Internet has a routing scaling problem which has been
recognised for years.  It is reasonable to expect the rate of growth
in the DFZ routing table to increase in the next few years as fresh
IPv4 space becomes increasingly hard to get, causing people to slice
up existing space more and more in order to utilize it better.

  http://bgp.potaroo.net

IPv6 has no scaling problem whatsoever:

  http://bgp.potaroo.net/v6/v6rpt.html

There are 0.39% the number of prefixes and 2.9% the number of ASes
connected to the IPv6 Internet.

Let's say there is a forest fire, and the V4 Community Hall, which
everyone uses, has its paint blistering in the heat.  Burning embers
are falling out of the sky.  Folks are there with buckets of water,
and are furiously clearing the leaves out of the gutters.

Far from the fire is another, newer, V6 Community Hall.  Hardly
anyone uses it, because they like to be with everyone else, and
everyone has always been together in the V4 Community Hall.

The V6 Community Hall is just as combustible as the V4 one, and has
leaves in its gutters too.  Fortunately, it is nowhere near the fire.

The Fire Brigade arrives in force and assesses the situation.

The Fire Chief decides on the Plan of Action:

   We will develop techniques to protect the V6
   Community Hall from fire.

   These techniques may or may not be applicable
   to the V4 Community Hall - but at the very least,
   we will ensure that the V6 Community Hall never
   catches fire in the future.

>From this, the community is entitled to conclude that the Fire Chief
doesn't care much for their favoured Community Hall.

Even if the you-beaut V6 Community Hall is the Way of the Future ...

Even if the Chief is later proven to be right about the long-term
benefits of everyone moving to the V6 Community Hall ...

Folks could be forgiven for thinking that the Chief's priorities are
not aligned with their own.

So they will work hard to protect the V4 Community Hall in their own
ways.

> 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 time-frame.

I agree in that scalable routing solutions are non-trivial.

I think IPv6's only substantial benefit over IPv4 is nearly endless
address space.  I think its addresses are 64 bits too long, bloating
headers, storage of addresses and causing 64 bit CPUs to resort to
shovelling long words just to convey a single IP address.

The bloated headers, especially for VoIP packets, are a marginal
concern, which can be overcome by more communications and computing
horsepower.

Other than its lack of compatibility with IPv4, my main gripe about
IPv6 is that DFZ routers seem to be doomed to expensive, slow,
power-consuming drudgery, chewing though up to 48 bits of
destination address for every packet they handle.

It seems wrong to me for two people to be chatting idly across the
globe, supposedly for free, when 50 VoIP packets a second traverse
20 routers in one or both directions at once, and each router has to
implement an onerous multi-step computation, with DRAM lookups, just
to forward each packet.

However, if my FLOWv6 scalable routing proposal proves to be practical:

  http://psg.com/lists/rrg/2008/msg02036.html

then this burden on the FIBs of DFZ routers would be greatly reduced.

I think there is so much tied up in IPv4 that there will be greater
and greater economic incentives to improve utilization of IPv4
address space.

One way of doing this is to slice and dice it more finely, without
burdening BGP.  All the map-encap systems would do this, and a
map-encap system could well be an economically profitable thing to
introduce, for the purposes of providing portable, multihomable,
address space to non-mobile end-users.  It doesn't have to wait for
IETF standards.

I think the commercial prospects of the TTR (Translating Tunnel
Router) mobility extensions to map-encap - or, with IPv6, to FLOWv6:

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

are even more attractive.

So even if the IETF never develops a scalable routing and addressing
solution for IPv4, I think there may be commercial developers who
will.  Their main aim might not be scalability as such, but if they
can do something with the broad slabs (/24 and bigger) of
BGP-managed space which are available, at a price, and turn them
into large numbers of smaller slabs of space (down to single,
portable, multihomable, IP addresses) then they can surely turn this
into a profitable business.  They will have to do it without overly
burdening BGP, and map-encap enables them to do exactly this.

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

I agree that routers will have more FIB and RIB capacity.  I am not
so confident anything can be done to significantly improve BGP - or
to replace it.

NAT will continue to be widely used, of course.

One attractive arrangement might be for businesses to get a single
IP address, or just a few, and multihome them via DSL and some other
mechanism for backup - such as HFC cable or WiMax.  Then they run
their mailserver, NAT boxes etc. on that one or a few IP addresses.

The only way they will be able to do this scalably, or affordably,
is with a little portion of address space - sliced and diced by
map-encap.

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

OK.

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

Residential and small business customers get a single IPv4 address
today.  Multi-layer NAT and "Dual Stack Lite" squeeze multiple
customers onto a single IPv4 address, at the cost of making their
service less usable - or unusable, to a significant proportion of
customers.  I think this would be a large enough proportion to make
the service impossible to market or support as if it was as good as
a conventional dedicated IPv4 address service.

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

As with Comcast's "Dual Stack Lite".

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

Yes - but I think that P2P factor is probably a fatal flaw in the
idea that these "Dual Stack Lite", NAT-PT or multi-layer NAT
services will ever be widely adopted.  I can't see how they could be
widely adopted as long as IPv4 addresses are available for a price
lower than the cost of deploying and supporting these services, the
extra cost of difficult marketing, the fact that they couldn't be
sold for the same price as a normal dedicated IPv4 address service
and the fact that a significant subset of customers won't take the
service at any price.

> I'd argue (1), (2), and (4) are extremely likely regardless of
> what the future might hold.

I agree.

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

I guess this will happen over the next five or ten years, as new
networks replace old (if they do) and assuming that there are some
reasonably tried and tested ways of doing all this.  Comcast, I
guess, is a pioneer in this field.

Can you or anyone else provide insight into Chinese or Asian IPv6
deployments?

> The big question marks are (5) and (6).

Yes.

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

I know next to nothing about P2P protocols, but it doesn't seem
inconceivable to me that these and other programs, such as games
servers, could work with a range of public port numbers, so it would
be OK to run them with "Dual Stack Lite", with the NAT box using
UPnP to give port X to one customer, port X+1 to another etc.

> However assuming this fanciful scenario pans out, at this point,
> you have IPv6-enabled end users and IPv6-enabled transport.

Yes, but how many and how soon is difficult to tell.

It is hard to see the benefit to an ISP ripping up their existing
network and installing IPv6 instead, with tunneling to preserve IPv4
connectivity.

I wonder how the DOCSIS CMTS head-end gear and the DSL DSLAMs
organise IP addresses.  I guess the latter is not tied to IP
addresses at all, since I get one ISP's fixed IP address through
another's DSLAM.

I understand Comcast's plans would depend on DOCSIS 3.0 cable modems
and CMTS gear, which only became available this year.

> What is (and has always been) missing is IPv6-enabled content.

Yes, people are perfectly happy having all their meetings and dances
in the V4 Community Hall.

If you had something to sell or give away, why would you do it only
on IPv6?  There is no reason at all.

Any website, service or whatever material it is has to be on IPv4.

Why would you also want to do it on IPv6, when every one of the
small number of people with IPv6 can already reach the material fine
with IPv4?

This is especially the case since it seems that IPv6 websites tend
to have different host names, which will surely just confuse people:

  http://www.google.com
  http://ipv6.google.com

  http://www.lisp4.net
  http://www.lisp6.net

> 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 time-frames.

Do you mean refusing to accept some subset of the routes they
currently accept?

For instance, some arbitrary or carefully chosen subset of the /24
prefixes, which dominate the number of prefixes BGP routers handle
but cover only a tiny fraction of the address space?

  Prefix Length Distributions
  http://bgp.potaroo.net/as6447/

     /8      18 	
     /9       9 	
    /10      16 	
    /11      46 	
    /12     146
    /13     293
    /14     525
    /15    1057
    /16   10142
    /17    4456
    /18    7706
    /19   16290
    /20   19696
    /21   18624
    /22   23226
    /23   24192
    /24  142984

That would lead to customer dissatisfaction, support calls etc. and
to competitors trumpeting the fact that they connect to the full
Internet.

I think this is an unlikely scenario.  The routing scaling problem
is a long-term concern, and unless the ISP suddenly finds the DFZ
routing table exceeding a hardware limit on their routers, as with
this example of a TCAM-based router with 244k entries:

  http://psg.com/lists/rrg/2008/msg01851.html

I don't imagine they will chop connectivity to parts of the Net.
That would be labour intensive - trying to decide what not to
connect to, and it wouldn't significantly affect their routers'
ability to converge (stabilise on the optimal best paths, after
comparing notes with all its neighbours).

However, I guess if there was a tendency to refuse certain routes,
those which change the most would be first on the list:

  http://bgpupdates.potaroo.net/instability/bgpupd.html

Unfortunately that sort of action renders useless any system which
has legitimate need for frequent updates, such as:

  http://en.wikipedia.org/wiki/Connexion_by_Boeing

which is still in use for the military, but is not used commercially
any more.

> As more filters are deployed, content providers will begin to see
> reductions in customers and thus will be incentivized to provide
> IPv6-only content.

I completely disagree.

There is no way ISPs are going to cut off connectivity to any prefix
which their customers actually want to access.

I think you are arguing something like this:

  1 - The scaling problem will bite a significant number of ISPs so
      hard that they will program their routers not to accept
      certain prefixes.

  2 - While some of those prefixes won't matter, a large enough
      number of them will be desired enough by the ISP's customers -
      some site, some content, some game server etc.  - that a
      significant number of them will be unhappy enough to complain
      to someone.

  3 - Rather than the customer complain to the ISP (which is very
      expensive for the ISP, and would surely cause them to
      let their routers use that route again) and rather than
      leaving the ISP and moving to a competitor which doesn't
      restrict its routers in this way, you are arguing that:

      a - The customers will complain to the website operators.

      b - The website operators will not tell them to get a proper
          ISP.

      c - The website operators will be motivated enough by
          the plight of these ISP customers to invest money
          and effort into making their site, game server etc.
          fully available on IPv6.

      d - The website owners will exhort the customer to get IPv6.

      e - If the ISP doesn't already supply IPv6 connectivity,
          the customer will exhort the ISP to do so.

      f - The customer will then purchase, install and configure
          a new DSL or cable modem, set up their PCs etc. for
          IPv6 - which will surely involve multiple support calls
          to the ISP.

      g - The customer will then be happy with their IPv4 challenged
          ISP, because they can access a small subset of sites via
          IPv6, and that subset includes all the sites they want
          to access which the ISP chose not to connect to.

There comes a time in every "IPv6 is going to be widely adopted real
soon now - or at least in the foreseeable future" discussion were
the argument in favour takes leave of this Earth and soars into a
zone of rarefied probability.

I don't believe this scenario is at all realistic.

The only benefit the ISP could get from this is that it wouldn't
have to upgrade its routers to cope with the growth in today's DFZ
routing table.

Yet surely its routers would cope with this, because they are not
hand-me-downs - the ISP has recently made its entire network IPv6
compatible, which presumably means investing in newish router and a
bunch of other stuff, DSLAMs, billing software etc.

You seem to be arguing that the ISP would incur the wrath of its
customers - costly wrath with every support call - and upgrade its
entire network, billing and customer support system to cope with
IPv6, just to save on upgrading its IPv4 routers.

I am sure this scenario would never occur.

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

It is a bit of a stretch . . .

Here is what the Fire Chief was thinking:

   That ol' V4 Community Hall - where I met my sweetheart wife!

   But look - its a goddamn Fire Trap.

   It's never gonna to be big enough, safe enough, for our
   growin' community!

   Its a fire trap in itself, it needs a lot of Maint'nence AND
   its right next to that dry and highly Combustible forest.

   We have to move to the V6 Community Hall one day.

   The sooner the better, I say.

   But Traditions and Sentiments won't die easily.

   Really, it would be easier if the damn place burnt down.  We
   can't keep protectin' it from fire year after year.

So he and his team devote themselves to protecting the V6 Community
Hall - and he looks forward to welcoming everyone to it the day
after the V4 Community Hall burns to the ground.

Maybe the Fire Chief is right.

Maybe we should let IPv4 tangle itself up in more and more BGP
updates, more and more expensive routers, until one day, enough
folks get sick of it - and of their own volition, come on over to
the Lasting Home of IPv6.

While I think this is a well intentioned approach, and while I think
many IETF folks have it - and while, in the very long run, it might
prove to be Right (in the opinion of all the community), I think it
is way out of step with what the vast majority of Internet users
want and need.

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

I don't think it is right or practical to walk away from IPv4 as if
it doesn't really matter much - which I think is what the current
RRG rough consensus does.

If we don't provide a fix for keeping IPv4 going nicely, someone
else will.

For better or worse, I think the IPv4 Internet has unstoppable
momentum - and there is so far no backwards compatible new form of
Internet to replace it.

Look how people are stuck with Windows, or vi.

Look how most people are stuck with using a mouse, which is an RSI
horror from the wrist to the shoulders.  If Logitech thumb-operated
trackballs had been introduced first, everyone would be using them
happily, and the only RSI would be of the thumb.

We are all thoroughly stuck with the QWERTY keyboard, even though
much better layouts exist.

Other than perhaps 3G cellphones and Chinese etc. IPv6 deployments
(which I hear about, but known nothing in detail), there is no
reason for people to invest in IPv6 and adopt it to the exclusion of
having an IPv4 address of their own.

The best scenario we have been able to find for this is the Comcast
"Dual Stack Lite" approach - but that has high costs in terms of
deployment, marketing, support, being a lower value service etc.

As long as IPv4 space is available for less than this cost, then
Comcast and all other ISPs will keep giving their customers the same
kind of IPv4 service they give today.

Even if a few hundred million people got a service such as "Dual
Stack Lite", this doesn't do much to wean people off IPv4
applications and Internet sites.  What it would do is extend the
life of IPv4, since it would be a major instance of more efficient
utilization of IPv4 space.

I am yet to see an argument for why IPv6 will actually be widely
adopted and used, without IPv4, which doesn't involve a leap a
series of events which are clearly unlikely to eventuate in the
foreseeable future.

Tony wrote:

> Others have replied to most of the points that you raised.
> As to this one, I'll just point out that most hosts interact with
> a very small number of servers.  If a large number of public web
> servers (e.g., Google, CNN, Yahoo, Amazon, etc.) and basic private
> servers for DNS, SMTP, IMAP and POP have v6 support, many folks
> would be quite happily working on v6.

That is a big If.

It is the same old chicken and egg problem.

Why would any of these companies (other than Google, who do it for a
lark) make the serious investment required to fully duplicate
everything they do for the IPv6 Internet?

I can't see any reason, short of massive government cash incentives.

Likewise, why should people who write mailservers, IMAP servers,
Thunderbird, countless web-mail systems etc. all work to make their
systems work flawlessly with dual stack or IPv6 only, whilst still
remaining robust with IPv4 only?

> The number of applications  that require true any-to-any v6
> support is pretty small (e.g., p2p protocols).

I am not so sure.

I would want to see a survey of all the programs people actually
use: their operating systems, their browsers, their Adobe Reader and
its constant habit of updating itself, all the shareware and
freeware programs they use, all the P2P file sharing programs they
use, all the IM, Yahoo Chat etc. programs they use.  Likewise the
firewalls, virus checkers etc. they download for free or pay for.

Likewise printers and printer drivers for the increasing number of
printers with Ethernet connections.

How many of these are ready to operate seamlessly in both dual-stack
and IPv6-only?

I am sure that not enough of them are ready enough for people to be
happy doing dual-stack.

Running a PC is hard enough as it is, without having to worry about
two separate types of TCP/IP which can't see each other, existing in
software, on the LAN and to and from the outside world.

Dual-stack would only complicate an already dicey IT installation.

Dual-stack wouldn't enable people to do anything they can't do
already, since everything of any value is always available just fine
on IPv4.

No-one could tolerate IPv6-only service at all, so that is just a
theoretical possibility.

> Thus, I think that once we get the infrastructure actually working
> with v6, it will be entirely possible to dual-stack individual
> hosts without too much difficulty.

I don't think it will be that easy, and I don't see why ISPs and
end-users have any substantial reason to invest in IPv6 - now or in
the foreseeable future.

Let's say the Fire Chief is right.

Probably the only way he is going to get everyone over to the V6
Community Hall is to sneak up at night, douse the old barn with a
drum-full of Volatile Hydrocarbons and send her up in smoke once and
for all himself.

Scorchings and burnings from forest fires won't do the trick.
Neither will increasing overcrowding, since the community will
rebuild, extend and find new ways of seating more people in their
familiar V4 Community Hall.

Maybe in the future we will regret saving or prolonging the life of
IPv4.  However it doesn't seem right to neglect it and all the
people who depend upon it, when the transition to IPv6 is so
difficult to make.

 - Robin

=============================================================

Dual Stack Lite
---------------

   http://tools.ietf.org/html/draft-durand-dual-stack-lite-00

The new material, compared to the 464 I-D:

     http://tools.ietf.org/html/draft-durand-v6ops-natv4v6v4-01

includes:

|  2.3. Additional impact on new broadband deployment
|
|     Even when considering new, green field, broadband deployments,
|     such as always-on 4G, service providers have to face the same
|     situation as described above, that is, contents and services
|     available on the Internet are, today, generally accessible
|     only over IPv4 and not IPv6.  This makes adoption of IPv6 for
|     green field deployment difficult.  Solutions like NAT-PT, now
|     deprecated, do not provide, as of today, a satisfying and
|     scalable answer.
|
|  2.4. Burden on service providers
|
|     As a conclusion, broadband service providers may be faced with
|     the situation where they have IPv4 customers willing to
|     communicate with IPv4 servers on the Internet but may not have
|     any IPv4 addresses left to assign to them...  However, without
|     some form of backward compatibility with IPv4, the cost and
|     the benefits of deploying IPv6 are not a aligned, making
|     incremental IPv6 deployment very difficult.

The proposal seems to be the same as 464:

|  2.5. The dual-stack lite model: IPv4 address sharing on top of
|       IPv6-only provisioning
|
|     The core idea behind dual-stack lite is to move from a
|     deployment model where a globally unique IPv4 address is
|     provisoned per customer and shared among several devices
|     within that customer premise to a deployment model where that
|     globally unique IPv4 address is shared among many customers.
|     instead of relying on a cascade of NATs, the dual-stack lite
|     model is build on IPv4 over IPv6 tunnels to cross the
|     network to reach a carrier-grade IPv4-IPv4 NAT.  As such, it
|     simplify the management of the service provider network and
|     provide the customer the benefit of having only one layer of
|     NAT.  The additional benefit of this model is to gradually
|     introduce IPv6 in the Internet by making it virtually backward
|     compatible with IPv4.
|
|
|  3.1. Expectations for home gateway based scenarios
|
|     This section mainly address home style networks characterized
|     by the presence of a home gateway.
|
|     Legacy, unmodified, IPv4-only devices inside the home network
|     are expected to keep using RFC1918 address space, a-la
|     192.168.0.0/16 and should be able to access the IPv4 Internet
|     in a similar way they do it today through a home gateway IPv4
|     NAT.

(Except for getting a public port on the NAT box . . . )

|  3.3. Application expectations
|
|     Most applications that today work transparently through an
|     IPv4 home gateway NAT should keep working the same way.
| *   However, it is not expected that applications that requires
| *   specific port assignment or port mapping from the NAT box will
| *   keep working.
|
|
|  3.4. Service provider network expectations
|
|     The dual-stack lite deployment model is based on the notion
|     that IPv4 addresses will be shared by several customers.
                                            -------

|     This implies that the NAT functionality will move from the
|     home gateway to a device hosted within the service provider
|     network.  It is important to observe that this functionality
|     does not have to be performed deep in the core of the network
|     and that it might be better implemented close to the
|     aggregation point of customer traffic.

This indicates that Dual Stack Lite will reduce IPv4 address
requirements by an order of "several" - but see below where a factor
of 100 is mentioned.

Further sections describe the IPv4 over IPv6 tunnel arrangements,
with the home gateway doing no address translation, and providing
RFC1918 address space.  MTU problems are possible over this tunnel.

The key new technology (the same as with "646") is a NAT box, shared
by multiple customers, presumably with a single IP address, which
uses the IPv6 address of the various customers' packets to
distinguish between the sessions, as well as the customer-end IPv4
addresses and port numbers.  So multiple customers can be using
192.168.0.10 TCP port 2000 and the NAT box can keep each session
separate.

|  4.5. Dual-stack lite carrier-grade NAT
|
|     A dual-stack lite carrier grade NAT is a special IPv4 to IPv4
|     NAT deployed within the service provider network.  It is
|     reachable by customers via a series of point to point IPv4
|     over IPv6 tunnels.
|
|     A dual-stack lite carrier-grade NAT uses a combination of the
|     IPv6 source address of the tunnel and the inner IPv4 source
|     address to establish and maintain the IPv4 NAT mapping table.
|
|     A dual-stack lite carrier-grade NAT does not have to perform
|     any IPv6-IPv6, IPv6-IPv4 or IPv4-IPv6 NAT.
|
|     A dual-stack lite carrier-grade NAT should implement a
|     full-cone NAT with hair-pinning (symmetric NAT may break
|     applications using several simultaneous connections).  It will
|     have to implement the ALGs to support the classic
|     applications.  However, manual port forwarding or UPnP may or
|     may not be supported.

It would be impossible to support port forwarding properly, in a
situation where, for instance, two customers on the one NAT box both
wanted TCP port 80.

This roughly accords with Alain Durand's mid-June description on PPML:

||     Think of IPv6 a a wonderful end to end L2 taking our packets
||     to the nearest IPv4-IPv4 NAT box ;-)

||     Manual port forwarding cannot be supported, of course. We are
||     now studying what is the impact on p2p protocols and uPNP.

|  4.6. Carrier-grade NAT considerations
|
|     Because IPv4 addresses will be share among customers and
|     potentially a large address space reduction factor may be
|     applied, in average, only a limited number of TCP or UDP port
|     numbers will be available per customer.  This means that
|     applications opening a very large number of TCP ports may have
|     a harder time to work.

Actually, they will intermittently stall or fail - and the flakiness
will drive customers and help-desk staff bananas.

|     For example, it has been reported that a very well know web
|     site was using AJAX techniques and was opening up to 69 TCP
|     ports per web page...

I knew there would be a catch to all that AJAX bling!

|     If we make the hypothesis of an address space reduction of a
|100> factor 100 (one IPv4 address per 100 customers), and 65k ports
|     per IPv4 addresses available, that makes a total of 650 ports
|     available simultaneously to be shared among the various
|     devices behind the dual-stack lite tunnel end-point.

This seems unrealistic to me.  Firstly, each customer may have a
bunch of PCs running in their house. Secondly, each PC may be
running a bunch of applications, including P2P applications talking
to dozens of other PCs the world over, and multiple busy AJAXified
web pages.

Not that AJAX necessarily involves lots of ports - I guess it would
depend on the browser's HTTP pipelining behaviour.  The latest
Firefox has it off by default, presumably for good reason:

   http://www.mozilla.org/projects/netlib/http/pipelining-faq.html
   (2005)

   Search for pipelining at: http://support.mozilla.com

In Firefox, type: "about:config" and Enter, and see the
"network.http.pipelining" option.

A third consideration is how much traffic a single NAT box could
handle.  I assume that racks of blade or COTS Linux servers will be
pressed into service.  With each customer potentially sucking HDTV
data rates of 10Mbps or more, I don't see how a single box is going
to NAT 100 customers worth of data.

So I don't believe this 100 customers per IPv4 address idea.  5 or
10 sounds more realistic.  That is a fully fledged Linux machine to
run and cool 24 hours a day, for 5 or 10 customers.  The capital
cost would be non-trivial, but the power and maintenance costs would
be substantial.

All for the sake of saving 4 or 9 IPv4 addresses.

The Dual Stack Lite I-D continues with comparisons with double NAT,
DSTM (draft-bound-dstm-exp-04 2005-10-17) and in greater detail, NAT-PT.

I guess such a service could be deployed, say around 2012.  I doubt
it could be commercially successful, due to its limitations, and I
doubt that IPv4 space will be so scarce that it would make sense to
invest in this second-rate type of service.

Assuming a service like this was successfully introduced to millions
of customers, it would provide a modest boost to real IPv6 adoption,
which also relies on the ability of applications to use IPv6 without
a hitch, and on there being a sufficient number of servers or other
such P2P applications on IPv6 to make it worthwhile.

--
to unsubscribe send a message to [email-masked] 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

---

From: [email-masked]
Date: Fri, 1 Aug 2008 08:05:13 EDT

In einer eMail vom 01.08.2008 10:48:07 Westeuropäische Normalzeit schreibt  
[email-masked]:

The IPv4  Internet has a routing scaling problem which has been
recognised for  years. 
... and which is immanent to its current design only

It is  reasonable to expect the rate of growth
in the DFZ routing table to  increase in the next few years as fresh
IPv4 space becomes increasingly  hard to get, causing people to slice
up existing space more and more in  order to utilize it better.
... but no one wants to give up prefix building, prefix caching, etc.  etc. 

I think its addresses are 64 bits too  long,
agreed; with 64 bits each square centimeter oof the surface of this planet  
can be identified.
I don't know how to call that tiny spot which could be identified by using  
128 bits.

If I were given the chance to prove my solution:
 
20 routers along the path, each doing forwarding by a single table offset  
rather than by about 20 prefix compares, not only means 20 times fast forwarding 
 but 20 x 20 = 400 times faster forwarding. 

A few years ago there were quite some more voices against BGP. But where  are 
they now ?
All disadvantages forgotten ? 
 
Heiner

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Aug 2008 18:47:34 +1200

> I don't know how to call that tiny spot which could be identified by using  

That's not, and never has been, anything to do with the choice of 128 bits.
There's been garbage marketing of IPv6 along those lines for many years,
of course. "2^128 will be definitely adequate as it is comparable to the
number of particles in the universe. " etc etc.

      Brian

---

From: David Conrad <[email-masked]>
Date: Mon, 4 Aug 2008 05:46:24 -0700

Robin,

> Dual-stack doesn't help the IPv4 routing scaling problem at all.

True.  It doesn't hurt it either.  The protocol being used is a bit  
orthogonal to whether the routing system scales.

> Every end user still needs an IPv4 address.

Well, every NAT would still need an IPv4 address.  But this is also a  
bit orthogonal to whether the routing system scales.

What matters in routing scalability is how addresses are aggregated.   
You can make IPv4 or IPv6 scale or not depending on how the addresses  
are allocated and announced to the routing system.

> to help reduce the IPv4 scaling problem.

Not necessarily.  You seem to be assuming IPv6 will be allocated in  
ways that promote aggregation and/or address recipients won't announce  
more specifics of the blocks they received from their allocators.  If  
(as is the current trend at all RIRs) IPv6 addresses are assigned as  
"provider independent", we'll have recreated the non-scalable IPv4  
swamp.  Yay us.

Currently, IPv6 is additive to the size of routing system, that is  
IPv6 routes do not displace IPv4 routes.  As such, it exacerbates the  
routing scalability problem.

[Alain's "dual stack lite"]
> accept incoming communications from other such programs.

I haven't been following the P2P stuff particularly closely but my  
understanding is that there are a common set of conventions that allow  
P2P applications to bypass NATs.  This would be what I would expect:  
applications will evolve to meet the constraints of the environment  
they must operate in to be successful.  If the preponderance of  
networks an application will be used in sit behind NAT, then the  
application will have to cope with NAT or no one will use it.

And gee, from Comcast's perspective wouldn't it be just horrible for  
Comcast (you know, the folks who just got slapped by the FCC because  
they were trying to stop P2P from sucking up all their upstream  
bandwidth) if P2P stuff didn't work anymore?

> have to be very careful so as not to promise too much.

Not promise too much?  This is a type of marketing I'm not familiar  
with. (:-))

> offer the service that people are used to getting.

Given someone from Comcast is proposing "dual stack lite", I suspect  
you are underestimating the situation Comcast believes they're  
facing.  For example, while it is very clear that IPv4 address  
utilization efficiency can be greatly increased, the question is how  
do you incent folks to be more efficient.  This gets into religion and  
questions of address allocation policy that I suspect we don't want to  
get into here.  If you're interested in this sort of thing, I'd  
recommend [email-masked] (and/or seeing a therapist).

> a competing service with a unique IPv4 address.

As you know, the free pool of IPv4 address space is projected to run  
out in 2011 (last I looked).  My guess is Comcast (et al.) will change  
their default allocation to their new customers.  The vast majority of  
customers most likely won't notice.  Those that do will likely be  
given the option of purchasing "SuperDuperPowerBooster(tm)" (or some  
other marketing term) for an additional (say) $9.95 a month which will  
grant them a dynamically allocated IPv4 address that can be used for  
NAT.

> The IPv4 Internet has a routing scaling problem which has been

Since IPv6 currently uses the same routing technology as IPv4, the  
_Internet_ has a routing scalability problem.  The symptoms of that  
problem are most apparent in IPv4 because that is where the vast  
majority of prefixes come from, however the benefit of fixing IPv4  
routing is merely enabling further penetration of (potentially multi- 
layer) NAT.  And if we're doing that, then what's the point of  
deploying IPv6?

> is with a little portion of address space - sliced and diced by

If businesses are sitting behind one or two addresses (e.g, a NAT and  
a public service machine), then the addresses can be 'provider  
aggregatable'.  Multi-homing of the kind you describe can be done with  
"Stupid DNS Tricks" without burdening the routing system.  You now  
have an InterNAT that scales to O(2^32) end points.

Yes.

> I think this is an unlikely scenario.

We've been here before, circa 1996.  Some of still have the t-shirts.   
We have an empirical proof that ISPs will do what they feel necessary  
to protect their own infrastructure including filtering long  
prefixes.  Some argue that such prefix length filters are unstable,  
that commercial pressures result in a tendency to remove the prefix  
length filters.  My view is that there is a tension between operators  
and sales folk.  As routers get upgraded, sales folk win battles and  
prefix length filters are relaxed.  As routers fall over, operators  
win battles and the prefix length filters are put back in.

> which their customers actually want to access.

How many routes do you think a typical end user customer of an ISP  
like Comcast or NTT need to see?  I figure (with no actual data) that  
the typical end user accesses a minute fraction of the 250K routes.   
Yes, a few customers will be unable to reach their pr0n and will  
whine.  If enough customers whine about the same prefix, the ISP will  
undoubtely allow the route.  If only a few people whine, the ISP can  
then say to those few customers "pay an additional $10/month and will  
let that route through".  This would lead to a natural incentive for  
folks to figure out ways to not pay the 'long prefix surcharge',  
including potentially deploying IPv6.

> I am sure this scenario would never occur.

:-)

http://markmail.org/message/i6ckia4vhsy5duql

Regards,
-drc

---

From: Robin Whittle <[email-masked]>
Date: Tue, 05 Aug 2008 00:40:31 +1000

Hi David,

> orthogonal to whether the routing system scales.

I agree that this is probably the basis of the RRG's rough
consensus.  I was just observing that it does nothing to help with
the IPv4 scaling problem until such time that it leads to people
being able to rely on IPv6 so much that they can happily do without
IPv4 addresses.

> bit orthogonal to whether the routing system scales.

Every residential and office end-user needs a single IPv4 address in
order to be able to run the full set of applications that a
substantial proportion of users are currently used to running.

This is one reason for the consumption of IPv4 addresses, and why
solutions such as Dual Stack Lite will be hard to sell unless they
somehow support port forwarding the way current services do.

The IPv4 scaling problem would still exist without the shortage of
address space, but the shortage of address space will make the
scaling problem much worse than it otherwise would be in the next
five years due to the need to slice up existing space into more and
finer pieces (as separately advertised BGP prefixes) in order that
more and more of the space goes to organisations which need it.

> are allocated and announced to the routing system.

The map-encap, translation and now my Ivip6 proposals all seek solve
the problem by having most end-user prefixes in the future not
individually advertised in the BGP core, while providing the
portable, multihomable, space which many end-users want and need.
Then, it doesn't matter how poorly the provider prefixes are
aggregated, because there won't be so many of them to constitute a
serious scaling problem.

(There also needs to be Mapped Address Blocks - MABs - advertised in
BGP, each containing thousands of micronets.  This is necessary for
the Open ITRs in the DFZ to support hosts sending packets from
networks without ITRs.  These MABs need to be not so numerous as to
overly burden the BGP system so they need to be generally large
enough to cover the micronets of thousands of end-user networks.)

> Not necessarily.  You seem to be assuming IPv6 will be allocated in ways
> that promote aggregation and/or address recipients won't announce more
> specifics of the blocks they received from their allocators.  If (as is
> the current trend at all RIRs) IPv6 addresses are assigned as "provider
> independent", we'll have recreated the non-scalable IPv4 swamp.  Yay us.

I agree.  I was assuming the the RRG efforts would solve the IPv6
routing scaling problem in time, but would not involve a fix for the
IPv4 scaling problem.

> Currently, IPv6 is additive to the size of routing system, that is IPv6
> routes do not displace IPv4 routes.  As such, it exacerbates the routing
> scalability problem.

I think they are two separate problems.  IPv4 is a problem with 260k
advertised prefixes and IPv6 is nowhere near a problem with only a
thousand or so.

> applications will evolve to meet the constraints of the environment they
> must operate in to be successful.  If the preponderance of networks an
> application will be used in sit behind NAT, then the application will
> have to cope with NAT or no one will use it.

Yes, but I think that mechanism is uPnP IGD to request a public
port.  If not, then Alain wouldn't be so concerned about the
restrictions "Dual Stack Lite" places on a substantial proportion of
ordinary users who like Bittorrent etc.

> bandwidth) if P2P stuff didn't work anymore?

Yes - as long as customers had an alternative, it would quickly get
around that Comcast sucks, at least in respect of popular P2P apps,
and anyone who wanted to get a public port to run a gameserver or
whatever else.

Actually, it is a nice little informal protocol to enter "xxx sucks"
  into Google and see what turns up.  30,800 pages for "Comcast
sucks" - but they have a huge number of customers, most of them
presumably happy.

> Not promise too much?  This is a type of marketing I'm not familiar

OK - I admit your point . . .

> Given someone from Comcast is proposing "dual stack lite", I suspect you
> are underestimating the situation Comcast believes they're facing.  For
> example, while it is very clear that IPv4 address utilization efficiency
> can be greatly increased, the question is how do you incent folks to be
> more efficient.  This gets into religion and questions of address
> allocation policy that I suspect we don't want to get into here.  If
> you're interested in this sort of thing, I'd recommend [email-masked]
> (and/or seeing a therapist).

Actually, I am trying to give up PPML.

> As you know, the free pool of IPv4 address space is projected to run out
> in 2011 (last I looked).  My guess is Comcast (et al.) will change their
> default allocation to their new customers.  The vast majority of
> customers most likely won't notice.  Those that do will likely be given
> the option of purchasing "SuperDuperPowerBooster(tm)" (or some other
> marketing term) for an additional (say) $9.95 a month which will grant
> them a dynamically allocated IPv4 address that can be used for NAT.

I don't have time to research how many people use Bittorrent etc.

My point is that the lack of uPnP IGD is apparently a serious
drawback to Comcast's plans, so I assume it would impact a
significant number of ordinary users, such as 20 to 70%.

> _Internet_ has a routing scalability problem.  

These are two separate Internets.

If they were the same Internet, it would be possible to communicate
freely from from an IPv4 host to and from an IPv6 host.  This is not
possible, because they are two separate networks which do not
communicate, except indirectly for some protocols by ALGs and via a
handful of protocols such as email which work the same on both networks.

> The symptoms of that
> routing is merely enabling further penetration of (potentially
> multi-layer) NAT.  And if we're doing that, then what's the point of
> deploying IPv6?

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.  The Net is an enormously
valuable thing, not least for the interpersonal connections it
enables - and for being a hard-to-resist support system for
democratic reform movements who are opposed to despotic governments.

There is no prospect of moving everyone to IPv6 as far as I can see
- it is too disruptive.  Maybe that would be the best thing for
everyone to move over soon - viewed in some long-term perspective by
the billions of people themselves at some time in the future.
However it would be exceedingly disruptive to do it now, and
virtually no-one wants to do it.

> If businesses are sitting behind one or two addresses (e.g, a NAT and a
> public service machine), then the addresses can be 'provider
> "Stupid DNS Tricks" without burdening the routing system.  You now have
> an InterNAT that scales to O(2^32) end points.

I am sure Bill Herrin could write a counter argument to this.

It is not my understanding of what people want and need with
multihoming - which is one or more stable IP addresses.  If what you
write was the case, then we wouldn't be here on the RRG trying to
devise a scalable architecture which supports multihoming with
stable IP addresses during the failure event.

> We have an empirical proof that ISPs will do what they feel necessary to
> protect their own infrastructure including filtering long prefixes. 
> Some argue that such prefix length filters are unstable, that commercial
> pressures result in a tendency to remove the prefix length filters.  My
> view is that there is a tension between operators and sales folk.  As
> routers get upgraded, sales folk win battles and prefix length filters
> are relaxed.  As routers fall over, operators win battles and the prefix
> length filters are put back in.

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.

> How many routes do you think a typical end user customer of an ISP like
> Comcast or NTT need to see?  I figure (with no actual data) that the
> typical end user accesses a minute fraction of the 250K routes.  Yes, a
> few customers will be unable to reach their pr0n and will whine.  If
> enough customers whine about the same prefix, the ISP will undoubtely
> allow the route.  If only a few people whine, the ISP can then say to
> those few customers "pay an additional $10/month and will let that route
> through".  This would lead to a natural incentive for folks to figure
> out ways to not pay the 'long prefix surcharge', including potentially
> deploying IPv6.
> 

OK: I am sure this scenario would never occur in the future to any
significant degree in a situation where customers had a choice
between an ISP who did this and one who didn't, which is typically
the case.

  - Robin

---

From: David Conrad <[email-masked]>
Date: Mon, 4 Aug 2008 16:52:06 -0700

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

Robin,

On Aug 4, 2008, at 7:40 AM, Robin Whittle wrote:
>> IPv6

As far as I'm aware, they share the same resources.

> sucks" - but they have a huge number of customers, most of them

Or, as in my case, there is no real alternative.

>> This gets into religion and questions of address

Yeah, I bailed back in February. I have better walls to bash my head  
against... :-)

> These are two separate Internets.

Yes they are two separate Internets, but they are sharing the same  
underlying resources (routers, bandwidth, engineers, etc).

> the Internet the way they do today.
...
> - 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.  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.  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.  "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.

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.

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

Regards,
-drc

---

From: Robin Whittle <[email-masked]>
Date: Tue, 05 Aug 2008 10:53:33 +1000

Hi David,

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

I agree.

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

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