[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] IPv4/6/ngng or IPv4-map-encap then IPngng



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