[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] NAT-PT and other approaches to IPv6 adoption - Dual Stack Lite
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 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