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

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




On Jun 12, 2008, at 6:58 AM, Robin Whittle wrote:

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 can attest that this is not accurate. A wide variety of future scenarios are and have been considered by the RIRs, including ones involving map & encap. However, if the primary function of the address resource administration system is to preserve over time the essential technical features/benefits for which the addressing system is designed (ala CIDR:RIR), then there's only so much that can be done before the addressing system and its goals are specified.

In the IPv4 context, the mere existence of (even abundant) quantities of public address space may be necessary but it is not sufficient to sustain the availability to those resources for future growth. Given the effort that was put into CIDR precisely to increase the carrying capacity of the existing routing and addressing system, it seems pretty clear that continued, unimpeded growth was a goal. But that didn't answer the question of what (else) causes or contributes to, or impedes or prevents growth. Is the goal of growth advanced by rigorous address request verification requirements, which help to conserve the address pool for as long as possible, or do such requirements impede growth by imposing burdensome administrative costs on current and aspiring operators? Is it advanced by contractual commitments and enforcement mechanisms that could bring idled address resource back into the pool for redistribution, or do those create too much controversy and overhead? Finally, in an environment where Internet services are being developed and delivered on a commercial basis, it's useful to remember that (one's own) growth is just one of many alternative strategies for achieving the primary goal, profitability; sometimes non-growth of current or potential competitors may be just as appealing.

Even if the apparent idleness of lots of routed address space is not just an artifact of measurement, it's not immediately obvious which among these and/or other factors is to blame -- not to me anyway.

I believe that the RIRs have done their best to facilitate the goal of growth despite the continuing ambiguity surrounding all of these questions. For any successor addressing system -- map & encap-based or otherwise -- to be approved, implemented, and judged successful over time, it's probably worthwhile to consider these questions up-front rather than waiting for them to answer themselves -- because sometimes they don't ;-)

Speaking for myself only,

Tom Vest
RIPE NCC Science Group


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


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