Hi Iljitsch and Xu, I am responding to your replies to "Inviting people to join the RRG":
http://psg.com/lists/rrg/2007/msg00512.html Xu, regarding IPv4 address depletion and the routing scalability problems you wrote: > I agree that a new Internet architecture should address both > issues. Otherwise, Internet will need another evolution after we > just finished an evolution for routing scalability purpose. If > the routing scalability issue is not so urgent as imaged, we need > to give the matter further thought. I think the only solution to address depletion is to divide the remaining free space and currently allocated but underutilized space into smaller blocks than has been the case (longer prefixes), down to /30 or whatever. With the existing reliance on BGP alone, that would lead to a completely unsustainable explosion in the number of prefixes. So I think better utilisation of IPv4 space can only be achieved with a more scalable routing architecture. On its own, the current growth in the ~240k IPv4 prefixes is regarded as alarming by some, but not by all. Those who are not alarmed are probably not on this list. Few of the many people who are concerned about IPv4 depletion seem to think there is scope for better utilization - but I think that will change as the crunch progresses and more and more space is in fact better used. I and a few others - I think including Geoff Huston: http://psg.com/lists/rrg/2007/msg00512.html - think there is a lot of room for improvement. The stability and responsiveness of the BGP system is not ideal, but is not nearly disastrous. I understand (can someone confirm this?) that the CPU and memory burden on each DFZ router scales roughly in proportion to the number of prefixes multiplied by the number of peer routers, with a significant contributing factor being the number of changed advertisements. This last factor is driven by outages, permanent changes in network structure and in particular by a small subset of operators chopping and changing their advertised prefixes between different routers on an hourly or daily basis to achieve Traffic Engineering of incoming traffic. Since current routers are working with a wide range of numbers of peers: http://psg.com/lists/rrg/2007/msg00253.html as far as I know, there isn't some threshold over which the number of advertised prefixes would cause a precipitous increase in the number of current routers being unable to perform their tasks adequately. I think that growth rate will increase enormously (unless we have a new ITR-ETR scheme in place) once the only way of getting fresh space is to carve smaller chunks out of larger slabs of space which are currently not fully utilized. >> 2 - All the ITR-ETR schemes are capable of slicing and dicing >> IPv4 address space in many more pieces, and in finer pieces, >> than is ever likely to be practical with BGP. 3 - Therefore, >> any of the ITR-ETR schemes could make a major contribution to >> the more efficient utilisation of IPv4 space. > The current ITR-ETR schemes use IPv4 address as EID namespace, > and they do make some contribution to the efficient utilization > of IPv4 address space. But is that enough? I think the continuing need for IPv4 address space, including smaller chunks of it with greater use of NAT, will continue for the foreseeable future - 5 to 10 years at least. Having an IPv6 address does not alter the need of the vast majority of users for direct (or via NAT) access to IPv4. My guess is that a combination of these two approaches, either of which is effective on its own, will keep virtually all end-users (apart perhaps from research and cellphone networks) connected to the IPv4 Internet for the next 5 to 10 years at least - and perhaps for much longer: 1 - Better utilisation of IPv4 space through more dense address usage by existing address holders, combined with splitting up space into far more, smaller, chunks for new ISPs and end-user networks. 2 - Increased use of NAT. All home and office applications have to work with NAT now, so despite its ugliness and the terrible burdens it places on application developers and (when it doesn't work) on end-users and hapless ISP help-line people, I think NAT is part of life, except for servers, and will be used more and more. I am not saying this is elegant or desirable. Its just that no-one has been able to convince me that IPv6 will in fact be widely enough adopted in the next decade or two for ordinary end-users to be happy without IPv4 access. Until then, IPv6 is no solution to the IPv4 address crisis. > Provided that a new address space needs to be deployed as EID > namespace sooner or later in order to provide enough address > space, should we go ahead further to embed some useful features in > this new namespace from the start, such as build-in security > mechanism? Hmmm . . . If my prediction about continuing ubiquity of IPv4 turns out to be valid, then the new ITR-ETR scheme should definitely be amenable to important extensions such as this. (I believe an ITR-ETR scheme will be developed and widely deployed, though it will probably take quite a few years.) I think at this early stage of development it would be premature to hard-wire a new feature into the ITR-ETR scheme, but I think it would be good to ensure the system is expandable to do things we can and can't think of now. We may be stuck with the scheme for decades. I can't imagine a new feature giving benefits to the end-user without host changes. Perhaps some new features might work with only an OS change, or only an application change. Others would require both. Assuming the new features were genuinely useful and elegant - so as not to tangle the Net with complexities of marginal value - perhaps this could encourage adoption of the ITR-ETR mapped address space. >> 4 - We are stuck with IPv4 for the next decade or so. IPv6 >> provides few, if any, benefits for ordinary end-users, is >> complex and is not ubiquitously supported by applications, >> firewalls etc. No ordinary Internet user is likely to be >> happy with an IPv6-only address in the foreseeable future. > Agree. Thanks for agreeing with this, which is an unpopular view in some quarters. > Sooner or later we will need a global unique EID namespace > and locator namespace with enough space in order to realize > ubiquitous communication. It's better not to patch the Internet > architecture again and again because each upgrade will be a hard > experience. I agree. Both NAT and an ITR-ETR scheme are kludges, with real costs and limitations. Neither would have been necessary if IPv4 had more than 32 bits of address space - probably 48 would have been fine - and if the routing system could cope with millions or billions of separately routed prefixes. The first might have been vaguely possible, but most computers were 32 bits. The latter could only be achieved by some really elaborate protocols and far more CPU power, memory and bandwidth than could have been contemplated in the early 80s. I think this latter goal can really only be solved by an ITR-ETR scheme. As far as I know, no single, unified, routing system can scale to those sizes and at the same time remain responsive to changes. Iljitsch, despite what you wrote and what quite a few people believe about IPv6 and about IPv4 utilization, still I believe (for all the reasons I stated) that IPv6 offers no short to medium term (1 to 5 years) benefit to ordinary Internet users (and therefore their ISPs) compared to the costs of adopting it. I still believe that for the next 5 to 15 years most users will find it better to squeeze more usage out of IPv4 address space than to adopt IPv6-only space, where they can only communicate with other IPv6 users or with IPv4 users via a strictly limited range of protocols (via proxies or a handful of dual-mode applications). I still believe any of the ITR-ETR schemes can and should be used to finely slice and dice IPv4 space. NAT is ugly but I think that most most users would prefer it to having no direct IPv4 reachability. Theoretically, IPv4 can't be the long-term (~forever) future, but either can burning fossil fuels. Still, most folks will be burning coal, oil and natural gas until the immediate (personal, a few years timeframe) incremental costs exceed the alternatives. I think we may be stuck with IPv4 and NAT for a very long time (decades), with higher overall costs than would be entailed by a wholesale upgrade to IPv6 - because the shorter term costs of abandoning direct (including via NAT) IPv4 connectivity are too high at any one time for most users. You wrote: >> 1 - IPv4 address depletion is the most urgent architectural >> problem facing the Internet - and far better recognised than >> BGP stability and router scaling problems with the growth of >> advertised prefixes. > > Ah, but that's a solved problem. RRG = research, IETF = > engineering. IPv4 depletion = operation. We all know what needs > to be done here. A wise man once said: just do it. I see no consensus at all on what needs to be done regarding IPv4 address depletion. I think you imply that we all agree the answer is to move to IPv6. The trouble is, as I outlined above, IPv6 only solves the IPv4 address depletion problem once everyone - or almost everyone - has moved to IPv6. Until then, IPv6 offers no benefit to most users, since they can't do anything with it they can't already do with IPv4. An important exception is the highly complex IP Multimedia Subsystem - which was apparently designed to work only over IPv6. This was intended for 3G cellphone systems, but is apparently being considered for other uses as well. It is not IPv6's fault that this is the case. IPv4 had no upgrade path. I think it was a mistake for IPv6 to have such long addresses, adding to the length of every packet. 64 bits should have been fine - this would have saved 16 bytes of overhead per packet. But that is not what is holding up IPv6 adoption. It had to be a completely new address space, with correspondingly new protocols. It had to have a major impact on the OS and applications, making life costly and difficult for developers, network administrators and often users. >> 2 - All the ITR-ETR schemes are capable of slicing and dicing >> IPv4 address space in many more pieces, and in finer pieces, >> than is ever likely to be practical with BGP. > >> 3 - Therefore, any of the ITR-ETR schemes could make a major >> contribution to the more efficient utilisation of IPv4 space. > > I'm not convinced. The issue isn't the number of places that need > an address block, but the number of places that need an > individual address. I think it is both, although NAT tends to reduce the quantity of addresses each end-user network needs. >> 4 - We are stuck with IPv4 for the next decade or so. IPv6 >> provides few, if any, benefits for ordinary end-users, is >> complex and is not ubiquitously supported by applications, >> firewalls etc. No ordinary Internet user is likely to be happy >> with an IPv6-only address in the foreseeable future. > > The alternative is NAT, which is worse. NAT sucks immensely, but people live with it now. Just like Windoze. (I am using both at this moment.) Virtually no Internet user can live without IPv4 connectivity. So expecting them to be happy with only an IPv6 address any time in the next 5 years is like expecting them to stop breathing entirely - rather than expecting them to continue to suck as they (we) have learned to do already. >> 5 - IPv4 address space utilisation could easily be improved if >> there were suitable policies and slicing and dicing >> technologies. Ping responsive host rates in advertised space >> are around 4%: > > Meaningless. First of all, they also pinged unrouted space. It is not meaningless. My survey and the much better work at USC ISI: http://www.isi.edu/ant/address/ http://www.firstpr.com.au/ip/host-density-per-prefix/ both surveyed address space which was advertised in BGP. If you criticise these results as being so quantitatively inaccurate as to be meaningless, I think you need to provide quantitatively verifiable estimates of how many genuinely used addresses are not being picked up by ping. The ISI people face the same critique, also without any quantitative estimates of how inaccurate their figures are. > Second, current Windows doesn't respond to pings. Googling indicates Vista doesn't respond to pings. Firstly, not that many people use Vista. Secondly, many who do would have their machine behind NAT - and plenty of NAT devices such as DSL and cable modems do respond to ping. > Third, there's NATs and firewalls. I got high ping response rates from prefixes with reverse address mapping indicating they were DSL blocks. Also, the cable modem block 24.0.0.0/8 had a 17.6% response rate. > Fourth, not all systems are > turned on 24/7. Fifth, this is an average that includes both stuff > given out under the current fairly tight policies and large > amounts of stuff given away to people who aren't using it anymore. There is a wide distribution of ping response rates, as the graphs at my site show: http://www.firstpr.com.au/ip/host-density-per-prefix/all-graphs/ This wide distribution of rates is surely explained, to quite a large degree, by genuine variations in utilization. >> So there is plenty of room for improvement. > > No. Any effort spent on getting back IPv4 space for new uses is > wasted effort, because we need to move to IPv6 in the slightly > longer run anyway. Geoff Huston estimates 5 to 20% utilization. http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-ipv4.pdf Even with 20% - which means 3/4 of used addresses don't respond to pings - there is great scope for improvement. In the really long term, IPv4 with an ITR-ETR scheme and ubiquitous NAT would be a horrible kludge - but perhaps it may still be tolerable enough to keep sucking at, unless and until so many people have fully IPv6 compatible OSes and applications, without any investment of effort on their own, that the few people without IPv4 addresses can be forgotten about, except via proxies for a few key protocols. IPv6 is years - probably decades - away from being sufficiently widely and robustly deployed in applications and OSes. >> We are attempting to devise something really challenging here - >> and I think more expertise, more energy and wider perspectives >> would be very helpful. > > Again: no. We made our beds over the past 15 years. We have > another few years to fluff the pillows, then it's time to go to > sleep. Even if it's possible to go back and redo the IPv6 effort > and arrive at substantially better results (debatable), it's too > late for that now. The message should be: you have three more > years to start running IPv6 if you don't want to be left behind > on a network that isn't going anywhere in the medium- to long > term. That is the message from the IPv6 camp. But why would I, or most other end-users (and their ISPs) get IPv6 connectivity, ensure our most important devices, hosts OSes and applications are IPv6 compatible, when there is no benefit now or in the next few years over continuing to use IPv4 and leaving my computer undisturbed? That is just the first stage - to convince individual end-users and network operators to adopt IPv6, whilst retaining IPv4 connectivity. I can't think of a single practical, businesslike reason most users should do this. But in order for IPv6 to help at all with the IPv4 address shortage, you need to get "enough" end-users to adopt IPv6 in order that a significant number of end-users will be happy not to have an IPv4 address. "Enough" is probably close to 100%. Year after year we hear the same thing from the IPv6 camp and nothing substantial in user-land or ISPs happens - because IPv6 adoption involves effort and confusion and no tangible benefits. I am not saying it is good that the only viable complete alternative to IPv4 is so hard to get going. I am just saying it is. - Robin -- 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
