Hi again Per, You wrote:
> Any company and/or organisation today is expected to analyse the > behaviour of their market and client-base. How hard is it for the > internet registries to ask a statistically significant selection > of their clients (LIRs) and known legacy-allocation holders if > they're willing to give up some of their allocated blocks, how > much of it, and on which conditions? The scenario I am proposing depends to a large extent on map-encap. It could still happen to a limited extent by creating more and more BGP advertised prefixes, but that will be resisted because it would unfairly burden all DFZ router operators. For the RIRs to seriously consider the possibility I am suggesting, they would need to have a good understanding of the possibilities of map-encap schemes. Yet these schemes - with the exception of the LISP prototype code - are vapourware and hardly known outside the RRG. Even within the RRG not many people have much faith in them, and each of us map-encap developers has less faith in the other systems than in our own! I used to think I was being rather optimistic and imaginative with all this, but Tony's apparent desire to convert IPv6 to GSE in time to save the masses on Planet IPv4 is no less ambitious. As fresh space becomes harder and harder to get, there will be an increasing demand amongst end-user networks and ISPs for any space they can get. I think ISPs need large slabs, but I think many end-user networks could be happy with relatively small chunks of space, including especially fractions of a /24. I imagine there would be a curved relationship between the price per IP address and the number of IP addresses in the prefix which end-users want. I think you could find hundreds of thousands of end-users who would pay, say $20 a year per portable, multihomable IP address, for small amounts such as 1, 2, 8, 32 or so. I guess ISPs want /20s and shorter, and don't want to pay $80k a year for a /20. I imagine there are significant number of ISPs and end-user networks with excess space - space they are either not using at all, or space they could do without if they moved some of their hosts to a fraction of the space they currently have. They wouldn't want to do this to the point of feeling too hemmed in. Without a map-encap system there is no way of renting hundreds of thousands of end-user networks smallish chunks of PI space. With a map-encap system, it becomes easy - and it would be largely out of the hands of the RIRs. Whoever has the prefix allocated (assigned?) to them by the RIR can decide to put it into the map-encap system and split it up amongst potentially thousands of paying customers. I guess that this new use of address space would have to be agreed to by the RIRs. There should be no problem with this, because any such usage serves many more end-users than could be served in a scalable manner with that prefix without map-encap, so it would be considered a progressive, desirable, way to use the space. In this way, the map-encap system enables the provision of a highly valuable resource - portable, multihomable IPv4 space - in the small chunks which (I think) large numbers of customers want and will pay a high fee for. This is a high price per IP address but low per customer. It is easy to see where that would lead - a strong economic incentive to the tune of $10 or $20 a year for people sitting on sparsely used address space to clear themselves out of at least some of it, and rent, sell or whatever it to someone who will make much more profitable use from it by splitting it up with map-encap. Also, since the map-encap scheme enables all end-user networks to get portable multihomable space in small chunks (as well as large ones) then there is a lot less justification for existing PI space users holding on to large sparsely used blocks of space in case they might need it one day. It would not be quite so elegant to have a bunch of smaller prefixes for a largish end-user network as to have a single large one. However, each such map-encap prefix could be separately multihomed and used at any of the end-user's sites. Each could be split arbitrarily finely, down to individual IP addresses, each mapped to a different ETR, if that is what the end-user wanted to do with this space. The conventional convenience and simple aesthetics of having one largish prefix per end-user network won't be a valid justification for sitting on largely unused space as long as there is a global shortage of space and lots of smaller end-user networks are clamouring to spend $10 a year or more per IPv4 address. In addition, there is a potential market for TTR-mobility - where the laptop or cellphone is generally fine with a single IPv4 address. That could be a huge market, again driving up the value of any IPv4 space which can be put into the map-encap system as one largish block, and split up amongst many customers. > They haven't even tried, which speaks volumes about how realistic > they consider this to be. Yes, but to be fair, this map-encap stuff is revolutionary vapourware. Even within the RRG, it may not be a majority view that it should be attempted in IPv4 at all. > In this also consider that the > registries policies and work is directed by those exact companies > and organisations that depend on a viable path for future growth. I guess in a few years time when someone demonstrates a reasonably practical map-encap system - or builds one like Ivip primarily to run a TTR-based global mobility service - that the RIRs, ISPs etc. will think differently. - 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
