Re: [rrg] IPv4 & IPv6 routing scaling problems

[Robin Whittle <[e-mail]>]

Short version:  Joel seems to be stating that map-and-encaps (AKA
                CES) for IPv4 would lead to worse disaggregation -
                more prefixes in the DFZ.  I don't understand this
                at all, since CES architectures such as LISP and
                Ivip are intended to, and would, greatly reduce this.


Hi Joel,

Chris Morrow (msg05965) agreed with Dale Carder that once there was
money to be made reselling IPv4 address space, that the slicing and
dicing would "really begin" - which I understand means an increase
the growth rate of the number of prefixes in the DFZ.

I think this applies to any ISP and PI prefixes which are compacted
and then split in two, with the empty half going directly or
indirectly to either an ISP or an end-user network.

The CEE and CES routing scaling solutions help by enabling end-user
space to be portable and multihomable without advertising each chunk
of it in the DFZ.  So to the extent that this slicing and dicing
would greatly increase the number of PI end-user prefixes in the DFZ,
CES and CEE architectures can largely eliminate this problem.

Chris also wrote that in addition to the sale of space, another
factor in the growth of prefixes would be an end to the current
practice of not passing on any IPv4 routes in the DFZ longer than /24.

In the absence of a scalable routing solution, I think this too
could lead to more PI prefixes in the DFZ, particularly if those with
a handful of /24s sold them in a spit form, or handed them back and
they were for some reason split again.  I assume that only end-user
networks would be using these /24s and anything longer which was
universally accepted in the DFZ.

Even within the /24 limit, there's tremendous scope for growth in PI
prefixes.  Today: http://bgp.potaroo.net/as6447/ 163,261 /24s are
advertised, which is more than half of the prefixes in the DFZ.  Yet
this only covers 34.8 million IPv4 addresses, which is less than 1%
of the global unicast address space.

Chris indicated that router vendors regard 2 million prefixes as the
maximum for today's routers - and that for both IPv4 and IPv6, the
number of prefixes in the DFZ could quickly get larger than what
current and planned routers can handle.

He also agreed with Dale that the RIRs are gearing up for (in my
words) some kind of market in address space.

You wrote:

> I may be missing something, but it seems like the driver for such
> disaggregation in v4 would be more obvious with some of the
> map-and-encaps than with the current architecture.

By "more obvious" I guess you mean that the pressure to advertise
more prefixes in the DFZ would increase as a result of using "some of
the map-and-encaps".  Since you haven't mentioned any specifically, I
assume you mean LISP, Ivip and the Core-Edge Separation solutions in
general.

Any one of the following shows how a CES architecture will greatly
reduce the pressure for the space of end-user networks to be
advertised as individual PI prefixes in the DFZ, which is the cause
of the scaling problem and is exactly what Chris was concerned about:

  http://tools.ietf.org/html/draft-ietf-lisp-06
  http://tools.ietf.org/html/draft-whittle-ivip-arch-03
  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

so I don't understand why you think a CES solution would make things
worse.


> Once things are worth money, residential and SOHO folks be NATed.  I
> don't like it, but that simply seems to be inevitable.  

I don't understand why you think this.  IP addresses would need to be
worth a large amount of money before it was more profitable to force
residential and SOHO customers onto a behind NAT address, rather than
giving them a single PI global unicast IPv4 address like they get
today.  This is in part because the single address enables the
customer to port-forward as they wish - which can't happen if
multiple such customers are behind NAT and sharing a single IP address.

For this to occur, we would need to get to a stage of very high
address utilization right across the 3.7 billion range.  As long as
any space is not widely used, it would always be cheaper and more
profitable for all concerned to compact the usage into one part of an
underutilized prefix and then to sell, rent or whatever the now empty
part to an ISP.

As long as ISPs can get space like this, they will use it as they do
now - one IPv4 address per customer.  This is because giving the
customer a NATed address, behind a NAT box which also serves other
customers, is always going to be a lower value service - and the ISP
will be competing with others who can get space on the same market,
and provide single IPv4 address DSL etc. services as are used today.


> Hence they will not be contributing disaggregated prefixes into
> the pool.

I don't understand this.  Even if ISPs did put a large number of
residential and SOHO customers behind NAT, this wouldn't affect the
general problem of disaggregation of IPv4 space: the advertisement of
more and more prefixes in the DFZ.  An ISP with a /16 could have, in
theory at least, ~64k single IPv4 customers on this prefix.  If they
converted some or all of it to NAT boxes each serving 8 customers,
then they could get ~512k customers.  But this doesn't mean there
would be any more disaggregation - any more prefixes advertised in
the DFZ.


> In fact, as far as I can tell, anyone who is NATed can happily be
> aggregated (because the NAT will take care of renumbering / isolation
> issues for the customer.)

I don't understand what you are saying here. As I just wrote, whether
customers get a straight IPv4 address or an address behind NAT won't
alter how ISPs advertise their prefixes in the DFZ.


> Folks who need to host a small number of servers might be able to get by
> with a very long prefix, but no one else could.  They either need more
> addresses, or none.

With a CES system - which is what you are discussing - those
end-users which wanted 2, 8, 32 or whatever portable, multihomable,
IPv4 addresses would get it through the CES system, without
contributing to growth in the number of DFZ prefixes.

Each IPv4 address the CES system provides - "edge" address space: EID
space in Ivip or SPI micronet space in Ivip - is still an IPv4
address. So the overall value of IPv4 space will affect the cost of
renting or "owning" this space just as it affects the cost of ISPs
getting space for their PA customers, including all those residential
and SOHO customers with a single IPv4 address.


> Again, if we assume economics is kicking in, it would seem that using
> hosting providers, who get benefits of scale, would be more cost
> effective than trying to host servers using very long prefixes, for
> which you pay money.

I think most end-user networks running web-servers and the like would
continue to use hosting companies rather than run the servers on
their own premises, and pay their ISP for the traffic.

Hosting companies are end-user networks too, so they could be using
the scalable "edge" address space provided by the CES system.


> No, I can not prove any of that analysis.

I can't understand a lot of what you wrote - and the part I think I
understand, that a CES architecture would worsen the routing scaling
problem -

   "it seems like the driver for such disaggregation in v4
    would be more obvious with some of the map-and-encaps
    than with the current architecture."

seems completely contrary to what LISP, Ivip or any other effective
CES architecture which worked would do.

> And all other things being equal, I would prefer a solution that
> addresses IPv4.
>
> What I don't want to do is rule out good architectural solutions because
> they only address IPv6.

I think it is not absolutely necessary to have the same architecture
for IPv4 and IPv6.

For instance, if for some reason CEE was decided as the best solution
for IPv6, CES may still be the best for IPv4, since no CEE solution
works for IPv4.

This is because with CEE (Locator / Identifier Separation - not to be
confused with LISP) multihoming a /20 end-user network with two ISPs
requires the use of two /20 prefixes of PI space - one from each ISP.
 There's no way this wastage of space is feasible for IPv4 due to the
shortage of address space.


> (One path would be to figure out what we think the right answer looks
> like.  Then figure out if it applies to IPv4.  AIf not, we can figure
> out what reasonable paths we ought to explore in case Chris is right and
> the v4 economics actually drive an explosion in disaggregated prefixes.)

OK - CEE can't work for IPv4 and so far the only non-CEE proposals are:

    LISP, Ivip, TIDR and RANGER (CES)

    hIPv4

    Aggregation with Increasing scopes

Maybe the last two will turn out to fit the architectural pattern of
CES too - I haven't read them yet.

 - Robin