Subject: RE: [RADIR] draft text for: 4.6 Dual Stack Pressure on the Routing Table

From: "Azinger, Marla" <[email-masked]>
Date: Tue, 17 Jul 2007 12:35:11 -0400

I have reviewed Jasons text.  

Below are some suggested word changes.  The first one I try to shorten it...but I dont think that really worked.  The rest of the suggested word changes are based on clarity. This is an international reaching document so I made suggestions for getting rid of the commentary phrases that may not translate well into other languages or fimiliar to other cultures.

In addition to the rewording below I think paragraphs 11, 12 and 13 need internal and external clarified within the paragraphs.
  
Paragraph 1 wording:
As a result, networks that are adopting IPv6 are likely to do so in
parallel with IPv4.  This results in the network being dual stack in part
or in whole, and requires the upstream network to either be dual stack, or
for IPv6 traffic to be forwarded to an independent network than IPv4
(usually via tunnels of some sort), as a result, the end site has two
footprints in the routing table, one in the IPv4 routing table and one in
the IPv6 routing table.  

Alternative wording:
As a result, networks both downstream and upstream are likely to build dual stack networks.  In cases where the upstream network is not dual stacked the IPv6 traffic will be forwarded to an independent network than IPv4
(usually via tunnels of some sort), as a result, the end site has two
footprints in the routing table, one in the IPv4 routing table and one in
the IPv6 routing table.  

Para. 2 wording:
The IPv6 adoption rate is likely to be s-curved, with a number of IPv4-only networks holding out.

Alternative wording:
The IPv6 adoption rate is likely to be s-curved, with a number of IPv4-only networks maintaining an IPv4-only network 
indefinatly.

Para 5 wording:
The IPv6 routing table is projected to be smaller than the IPv4
routing tabled based on the assumption that the larger initial assignments
to end sites will minimize de-aggregation that occurs when a site must go
back to the well and receive a second, non-contiguous assignment.

Alternative wording:
The IPv6 routing table is projected to be smaller than the IPv4 routing tabled based on the assumption that the larger initial assignments to end sites will minimize de-aggregation that occurs when a site must go
back to their upstream address provider and receive a second, non-contiguous assignment.

Para. 8 wording:
(If instead, you think some of the more specifics are accidental, then the
problem is much worse as the larger address space of IPv6 gives much more
rope for one to hang oneself.)

Alternative wording:
(If instead, you think some of the more specifics are accidental, then the problem is much worse based on the fact that IPv6 has a larger address space than IPv4.)  

Para. 14 wording:
Additional routing table growth could come from the resale or
sub-let of small unused fragments of existing IPv4 aggregate.  

Alternative wording:
There is also the possibility that routing table growth could come from the resale or sub-let of small unused fragments of existing IPv4 aggregate.

Thank you
Marla

-----Original Message-----
From: Jason Schiller [mailto:[email-masked]]
Sent: Friday, June 29, 2007 2:34 PM
To: [email-masked]
Subject: [RADIR] draft text for: 4.6 Dual Stack Pressure on the Routing
Table

Attached is some strawman text for section 4.6 talking about the impact of
IPv4 / IPv6 dual stack on the routing system.  The numbers are a bit
dated (03/07), and I hope to run a new batch early next week, but wanted
to get some text out to see if this is what we were looking for.  

It is a bit long, and not sure if you want actual number here or not.

Also, this isn't exactly a "pressure to de-aggregate" so maybe we could
rename section 4 to "pressures on the number of prefixes in the routing
system"  

___Jason

4.6 Dual Stack Pressure on the Routing Table

As of July 2007, the current uptake of IPv6 has been limited.  As a
result, the richness of interconnectedness of the IPv6 Internet is much
less dense in comparison to the IPv4 Internet.  Likewise, the availability
of content and services using IPv6 transport is much more sparse than
IPv4.  As a result, networks that are adopting IPv6 are likely to do so in
parallel with IPv4.  This results in the network being dual stack in part
or in whole, and requires the upstream network to either be dual stack, or
for IPv6 traffic to be forwarded to an independent network than IPv4
(usually via tunnels of some sort), as a result, the end site has two
footprints in the routing table, one in the IPv4 routing table and one in
the IPv6 routing table.  

It is likely that end sites will continue to be dual stack for the
foreseeable future.  The IPv6 adoption rate is likely to be s-curved, with
a number of IPv4-only networks holding out.  As connectivity to these
IPv4-only networks might be required, end sites adopting IPv6 are likely
to be dual stack until near total IPv6 adoption. 

The current impact of IPv6 on the Internet routing table is minimal.  As
of July 2007, there are 861 routes in the IPv6 Internet routing table
[CIDR6].  By comparison, the IPv4 routing table is 211,537 routes
[CIDR4].  The IPv6 Internet routing table is approximately 245 times
smaller than the current IPv4 Internet routing table.

The IPv6 Internet routing table is currently growing at less than 100K
routes per year.  At this growth rate, it would take over two thousand
years for the IPv6 routing table to grow to the current size of the IPv4
Internet routing table.  This growth rate is indicative of the slow uptake
of IPv6.  It is not expected that the slow uptake of IPv6 nor the current
low growth rate of the IPv6 Internet routing table will continue for the
foreseeable future.

Once wide spread adoption of IPv6 occurs, most end sites will consume
routing slots in both the IPv4 Internet table, and the IPv6 Internet
table.  The IPv6 routing table is projected to be smaller than the IPv4
routing tabled based on the assumption that the larger initial assignments
to end sites will minimize de-aggregation that occurs when a site must go
back to the well and receive a second, non-contiguous assignment.

It is possible to extrapolate what the size of the IPv6 Internet routing
table would be if wide spread IPv6 adoption occurred, from the current
IPv4 Internet routing table.  The projection makes a few assumptions.  The
first assumption is that all sites run IPv4 and IPv6 in parallel.  The
second assumption is that each end site will use the same number of more
specific prefixes for traffic engineering in IPv6 as they currently do in
IPv4.  The third assumption is that any IPv4 site that is currently
advertising multiple non-contiguous IPv4 prefixes, could simply announce a
single large IPv6 aggregate.  (This may not be the case if the multiple
non-contiguous IPv4 aggregates are distributed across multiple stub sites
sharing a single origin ASN).    

This extrapolation assumes that all of the ASes that announce a single /24
prefix only require a single prefix for traffic engineering, and will
likewise only announce a single IPv6 prefix.  Instead, it is quite likely
that ASes that announce a single /24 prefix do so only because they are
limited by standard ISP routing practices of rejecting more specifics than
a /24 from Peers.  As a result in IPv6 when the end site is assigned a
/48, they may advertise multiple more specifics.  This extrapolation also
does not account for end sites that perform traffic engineering by
masquerading behind multiple NAT addresses.  If IPv6 does indeed eliminate
the need for NAT then these sites will likely need some other sort of
traffic engineering mechanism.

Using Geoff Huston.s CIDR report [CIDR4] we can extrapolate what the size
of the IPv6 Internet table would be given that wide spread IPv6 adoption
occurred instantaneously.  As of March 12, 2007 there are 211,573 routes
and 24,561 active ASNs in the IPv4 Internet routing table.  Of the 211,573
routes, they can be aggregated down to 137,100 routes.  This means that
there are 74,473 more specifics.  We can assume that all of the 74,473
more specifics are intentional and used for traffic engineering.  (If
instead, you think some of the more specifics are accidental, then the
problem is much worse as the larger address space of IPv6 gives much more
rope for one to hang oneself.)  

If we assume that each active AS has one IPv6 aggregate (24,561), and the
same number of intentional more specifics for IPv6 as there currently are
for IPv4 (74,473) then we can calculate the size of the IPv6 Internet
routing table as 24,561 + 74,473 = 99,034.

The IPv4 Internet table and the IPv6 Internet table would be 99,034 +
211,573 = 310,607 routes.

In addition to the Internet routing table, networks must also carry their
internal routing table.  For a large ISP, the internal IPv4 table can be
between 50,000 and 150,000 routes.  The IPv6 internal table can be
projected to be between 40,000 and 120,000.  

Assuming wide spread IPv6 adoption, the routing table of a large ISP is
projected to be between 400,607 and 580,607 routes.

Furthermore, examination of the past growth rate for the IPv4 Internet
table, IPv4 Internet more specifics, and the Active number of ASes in the
routing system, it is possible to predict the size of the IPv4/IPv6
Internet routing table five years out.  Also considering the past growth
rate of internal routes from a large ISP, it is possible to predict the
five years out routing table requirements of a large ISP.   Such an
analysis reveals that the projected routing table for January 1, 2011 is
888,491 routes for a large ISP network.

It is worth pointing out that this is a fairly conservative projection
based only on past growth.  Past growth is not necessarily a good
indicator of future growth.  The future growth is unbounded, and could be
potentially worse than present growth trends.  This is quite possible if
every car, every kitchen device, and every RFID tag requires a unique IPv6
network.  Additional routing table growth could come from the resale or
sub-let of small unused fragments of existing IPv4 aggregate.  

[CIDR4]  Geoff Huston IPv4 CIDR report March 12, 2007.  I will update with
July numbers shortly.

[CIDR6]  Geoff Huston IPv6 CIDR report.  I will update with July numbers
shortly

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir