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