Short version: When comparing map-encap proposals, we should consider their ability to help with the IPv4 address depletion problem. All of them should be capable of making a major contribution to improving address utilization.
This is the problem everyone knows about - so if we can say this routing scalability solution is also inherently a means of alleviating the IPv4 address "shortage", then it will be a lot easier to get people excited about it. Also, why we need to avoid changing hosts, even if that would be cheaper than changing and adding routers etc. Hi Xiaohu, You wrote, in part: > If I understood correctly, LISP, ivip and other similar proposals > are mainly based on one assumption: host should not be changed > because the cost of host change is believed to be much larger > than that of router change. I think this is true, but there are some other important aspects. We need the new kind of address space to be adopted by many, probably most and ideally all "end-users". "end-user" means anyone who wants or needs multihoming, traffic engineering, portability etc. and either can't get it now with BGP-based address slicing and dicing, or could get it, and so could add one or more routes to the DFZ routing table. No-one is in a position to force large numbers of such "end-users" to adopt the new address space, so we need to ensure at a minimum that the new space doesn't suck and secondly that it is is affordable - hopefully cheaper and better than the alternatives. Pretty much every such "end-user" uses their address space for servers and desktop machines etc. which need to communicate with a broad swath of other servers and desktop machines all over the world. Initially, all those other machines will not be using the new address space, and they will be completely unaltered. So the new address space has to support communications with the "rest of the world" in a way which works as well as, or is superior to, the alternatives - today's BGP managed PI or PA space. The new kind of space is not suitable for use by ISPs - but it will be highly suitable to end-users who are not selling connectivity to others. If the map-encap's address space involves degraded performance, even a little, except for when hosts at one or both ends have been upgraded (OS at least, applications far worse - it will never happen), then most end-users won't want it and the whole idea will sink. So for such a scheme A, even if the cost of upgrading all hosts was somehow less than the cost of upgrading routers, implementing some alternative map-encap scheme B etc. then scheme A will never succeed because potential early adoptors generally won't adopt it. > At least, the recent discussion about > the tradeoff between initial packet delay/loss and the > scalability of the mapping system is based on that assumption. > That is to say, the EID->RLOC mapping query is initialized by the > ITR, but not host. Provided that host could be changed and could > do the EID-RLOC mapping query on behalf of ITR and carry the > obtained RLOC information in the packets, most of the pain > discussed recently in RRG mail-list will not exist. With Ivip it would be possible to have a caching ITR function built into the sending host. However the system doesn't rely on this. It would make sense most where there are cost benefits for the person who runs the hosts. For instance, a server farm would have a choice between purchasing a bunch of high-powered ITRs to do all the work or installing some free software update to the OS of its servers. Assuming the task per server is not to heavy on CPU or RAM (as it would be, except perhaps for the busiest servers which send packets to a very wide range of destinations), putting the ITR function in the host would be the best approach. There's nothing about Ivip which makes in-host caching ITRs (ITFH - ITR Function in Host - not behind NAT) have higher performance, because the use of external ITRs provides the highest level of performance anyway. It is purely a cost-saving alternative which is attractive where the host OS can be changed without too much trouble. If you have some map-encap scheme X which has sub-optimal performance, except when the sending host is upgraded, then this scheme will be rejected by most end-users. These end-users need their networks to work just as well as with ordinary address space with the great mass of hosts out there, which initially will not have any scheme-X-friendly upgrades. > If the above assumption (host should not be change and still use > IPv4) is true, how will LISP, ivip and other similar proposals > deal with the address depletion problem? LISP, APT and Ivip can all slice and dice address space down to much smaller chunks than the 256 IPv4 address chunks which the BGP system is currently capable of. (This is an administrative matter, but clearly it is not going to get any finer, since we are trying to reduce the growth in the DFZ routing table.) LISP and APT does it in chunks of 1, 2, 4, 8, 16 etc. Ivip's micronets can be of any size, 1, 2, 3, 4, 5 etc. So Ivip is marginally more suited to the flexible, fine, slicing and dicing of IPv4 space we will need, assuming we are stuck with IPv4 for a long time, which I think we are. > Should we still use NAT to solve the address depletion issues? I think this is inevitable - unless someone can figure out a backwards compatible way of migrating end-users off IPv4 and onto IPv6 or some other kind of address system. > If so, we would have to tolerate the side-effect of NAT on the > new application design and deployment, especially > peer-to-peer applications which has already accounted for 80% > in total internet traffic volume nowadays. As long as we are using IPv4, I believe we are stuck with NAT - any widely used application needs to be able to fight its way out of whatever NAT or nested NATs, it finds itself in. There is a lot of potential for standardising how NAT is applied and how it can be auto-discovered. http://tools.ietf.org/wg/behave/ RFC 4787 but there will be plenty of NATs around for a long time which do not conform to any such standards. > Or should we adopt IPv6 (IPv6 can be adopted as EID in > the above proposals) to solve the address depletion problem? If > so, the change of host is unavoidable and this is conflicted with > the basic assumption of the above proposals. Or should we operate > on the Internet multiple times to solve the many existing > problems one by one? If the deadline of the routing scalability > issue is close to that of the address depletion issue, why not > solve them in one solution? I think a successful map-encap scheme will buy us a lot of time with IPv4 by making it much easier to increase address utilisation and accommodate many more multihomed end-user networks. The persistence of IPv4 will be for for better or worse depending on how you view the inherent merits of the world adopting IPv6. My guess is that about 200 to 300 million IPv4 addresses are currently in use. See: http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf and my analysis at the start of: http://www.firstpr.com.au/ip/host-density-per-prefix/ If we assume this to be 15% utilization of the 1.7 billion currently advertised IP addresses, and apply some factors: 1 - About twice this number of IP addresses could be advertised (theoretically 3.7 billion, I think), if push comes to shove, which it surely will in the next five to ten years. 2 - The new map-encap scheme could foster much better address usage, by a factor of two to five. I can imagine 75% of IP addresses being used, as their value becomes higher due to continuing demand and the physical limit of 3.7 billion. So I guess that by advertising all the space, and by using a map-encap scheme, we could get four to ten times the number of actively used IP addresses. To what degree NAT could be further applied to support more hosts (desktop machines, cellphones, Net-connected LCD "picture frames" etc.), more individual people using the Net etc. I am not sure. If NAT could be standardised so applications could fight their way out of two or more depths of NAT, then each DSL or ADSL modem, or each cellphone, could have a NATed address. Then in principle you could run an entire ISP from a single IP address and countless billions of hosts could have this form of IPv4 access. At the end of all this, someone will probably look back and observe it would have been easier to rip out every computer and router in 2015 and replace them with IPv6-compatible devices. Likewise escaping the ruts of MS Windows and qwerty keyboards! Since large numbers of desktop machines can be handled behind NAT on a single IPv4 address, in principle this population of machines can be handled almost indefinitely on a finite subset of the space, simply by applying NAT to a greater degree. Current practice is to give every cable modem or DSL customer a single public IPv4 address and let the modem NAT as many machines as they like. Giving them NATed addresses instead would mean two layers of NAT and (I guess) a variety of problems for existing applications, so I doubt this would happen unless all the alternatives were worse. > I doubt why the draft-irtf-rrg-design-goals-01 doesn't take the > IPv4 address depletion into account for a new routing and > addressing architecture. The IPv4 address shortage is the big problem virtually everyone knows about. Few people have heard of the routing scalability problem - and not everyone who has heard of it believes it really is a problem requiring the heroics we are contemplating with a map-encap scheme. I believe both the RRG Design Goals and RADIR Problem Statements: http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01 http://tools.ietf.org/html/draft-narten-radir-problem-statement-01 should recognise that a map-encap solution to the routing scaling problem can and should lead to new methods of address management which will be crucial in alleviating the IPv4 "address shortage". I wrote about this in July 2007 regarding the RADIR statement: http://www.ietf.org/mail-archive/web/ram/current/msg01772.html http://www.ietf.org/mail-archive/web/ram/current/msg01773.html and should have mentioned it regarding the RRG goals: http://psg.com/lists/rrg/2007/msg00199.html - Robin http://www.firstpr.com.au/ip/ivip/ -- 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
