Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt

From: [email-masked] (Noel Chiappa)
Date: Sun, 18 Mar 2007 13:39:16 -0400 (EDT)

> From: Tony Li <[email-masked]>

    >> I have trouble understanding this figure even if the current TE
    >> patterns persisted in the hypothetical full immediate transition to
    >> IPv6

    > The comment stipulates a "full" transition to IPv6. ... In a full
    > transition where all sites get a PI prefix, I think that the number
    > quoted above is extremely conservative, perhaps laughably so.

The document probably ought to say roughly that (although I'd pick a
different term, perhaps something like "extremely conservative, and perhaps
a gross underestimate"); not sure if it already does.

	Noel

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

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Mar 2007 20:50:34 +0200 (EET)

> a gross underestimate"); not sure if it already does.

First of all, what do you (and the draft) mean with 'full IPv6 
transition'?  The scenario where IPv4 has been shut off, or 
dual-stack everywhere?  In any case this probably needs to be 
clarified.

Especially if you mean 'everyone is using v6', I'm skeptical of these 
statements.  Could someone give some ideas what exactly would 
contribute the IPv6 prefix count?  I've trouble figuring how to get to 
even 100K prefixes (transforming the _current_ v4 routing table to v6; 
in 2050 the situation is likely different :-).

The key point with IPv6 at the moment is that instead of an ISP having 
to have 100 identically-routed, non-contiguous prefixes, it could have 
just one or a couple of them.  End-sites also often have 
non-contiguous prefixes which wouldn't (by routing policy) need to be 
deaggregated.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Vince Fuller <[email-masked]>
Date: Sun, 18 Mar 2007 20:43:00 -0700

> non-contiguous prefixes which wouldn't (by routing policy) need to be 

It's very easy to see an ipv6 routing table exceeding 100K prefixes given
the following set of assumptions and observations about how prefixes are
routed and will be routed in the future:

1) Each site that has its own ASN for multi-homing requires a unique prefix.
   This gives 24K ipv6 prefixes if a wholescale replacement of IPv4 with
   ipv6 were to happen in a relatively short timeframe. This number has been
   growing linearly for some time.

2) The majority of more-specific prefixes in the global routing system are
   advertised intentionally for traffic engineering or other purposes. In
   other words, relatively few more-specifics are configuration errors that
   would go away if only network operators were better educated. One ipv6
   prefix would be needed for each of the observed IPv4 more-specifics that
   are intentionally advertised today. This is 74K prefixes.

3) ipv6 is deployed in parallel to and with a degree of ubiquity that is
   similar to IPv4.

4) Multi-homing and traffic engineering will be done the same way with ipv6
   as with IPv4, i.e. "PI for all" and advertisement of more-specifics for
   TE. All of the RIRs have modified their ipv6 assignment policies during
   the past year to enable/encourage such widescale "PI" use.

5) The trend will be toward at least as much multi-homing in the future as
   there is today. It's actually more likely that there will be *much more*
   multi-homing in the future as (and if) the Internet becomes a critical
   infrastructure requirement for business, as non-IP-based services are
   migrated to an IP-based substrate, and as it becomes ever less expensive
   to obtain multiple Internet connections (i.e. $19.99 for a DSL connection
   plus $19.99 for a cable connection isn't much of a barrier to entry,
   particularly if you have to buy those lines to get your IPTV-based TV
   and your VoIP-based phone service anyway)

Using the first three assumptions, it is easy to see 100K ipv6 prefixes in
the global routing system in a relatively short period of time. Applying
the latter assumptions, adding the assumption that IPv4 continues in
operational use indefinitely, and projecting recent growth patterns forward
gives some interesting numbers. See:

    www.vaf.net/~vaf/rrg.pdf

for more information (a presentation that I have given in various places,
most recently at RRG on Saturday, over the past year).

	--Vince

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Mar 2007 16:35:03 +0100

On 18-mrt-2007, at 19:50, Pekka Savola wrote:

> transition'?  The scenario where IPv4 has been shut off, or dual- 
> stack everywhere?  In any case this probably needs to be clarified.

I can't speak for the draft or its authors, but my definition is as  
follows:

Currently, the assumption is that every resource connected to the  
internet is reachable over IPv4, and it may or may not be reachable  
over IPv6. The point of interest on the line between the situation we  
have today and the one where there are no longer any IPv4 systems is  
the point where the assumption is that every resource is available  
over IPv6, and optionally over IPv4.

I.e., the day that the IPv6-only people turn off the gateways they  
use to reach the legacy IPv4 internet.

> Especially if you mean 'everyone is using v6', I'm skeptical of  
> these statements.  Could someone give some ideas what exactly would  
> contribute the IPv6 prefix count?  I've trouble figuring how to get  
> to even 100K prefixes (transforming the _current_ v4 routing table  
> to v6; in 2050 the situation is likely different :-).

> The key point with IPv6 at the moment is that instead of an ISP  
> having to have 100 identically-routed, non-contiguous prefixes, it  
> could have just one or a couple of them.  End-sites also often have  
> non-contiguous prefixes which wouldn't (by routing policy) need to  
> be deaggregated.

If you telnet to route-views.oregon-ix.net and type "show ip bgp  
regexp _6461_1103$" you'll see the list of prefixes announced by  
Surfnet, the Dutch academic network. It's a very long list. It used  
to be much shorter: a number of years ago, they announced 145.0.0.0/9  
(IIRC) but now they announce all the class B blocks falling within  
that more or less individually. Apparently, so many of these blocks  
have moved away that announcing the aggregate no longer made sense.

These same issues will be present in IPv6 when it gets widely  
deployed. However, the question is open as to how much deaggregation  
the community will allow. In IPv4, /24 is as long as prefixes get.  
Currently, many people filter on /32 in IPv6, which may or may not  
persist in the future. But I don't think the community at large will  
accept arbitrary /48s, because there are / can be so many of them: it  
only takes a few /32s deaggregated into /48s to melt down your router.

I got heckled in (I think) the IEPG meeting when someone said the  
prefixes WILL be announced and I said they WILL be filtered. Sure,  
you can pay an ISP to carry more specifics. But you can't pay them  
all. Also, in IPv6 you can filter with relative impunity because it  
doesn't really break connectivity with IPv4 to fall back on.

How large the IPv6 table will be in the future is anyone's guess, but  
I'm pretty sure simply extrapolating IPv4 figures won't get us very  
close.

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Mar 2007 15:50:51 +0000

> over IPv6, and optionally over IPv4.

I think this view or question needn't be correct.   It's quite possible
that new application domains (e.g. peer-to-peer or those where the servers
are mobile or in SOHO networks) will use IPv6, while users quite merrily
(including web browsing for example).

> doesn't really break connectivity with IPv4 to fall back on.

I met Marc Blancet this morning.  He has IPv6 PI, and is now having fun
seeing where his /48 is seen :)
 
-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Mar 2007 15:50:51 +0000

-- 
Tim

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 19 Mar 2007 16:13:12 +0000

[stripped iab from the list, don't think they need more of my spam ;) ]

Tim Chown wrote:
[..]

> seeing where his /48 is seen :)

According to: http://www.sixxs.net/tools/grh/dfp/arin/

it (2620:0:230::/48) is being seen by 63% of the GRH participants.

2620:0:c0::/48 is at 83%

And it is very easy to see, by following the LG link, which ISP's are
filtering it out. A couple of the larger transits are still filtering it
though, but it won't take too long before that is resolved.

Greets,
 Jeroen
(who just bugged the ipv6-ops list to resolve the rest of the filters :)

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 19 Mar 2007 16:00:23 -0400

>    are intentionally advertised today. This is 74K prefixes.

Since some of the entities advertising more-specifics have likely  
obtained multiple blocks of address space, from which the more- 
specifics are taken, then it would seem to follow that in the IPv6  
case where we assume that each entity really just needs a single  
address block, they'll advertise fewer more specifics.  That is to  
say, there may be more than one more-specific per site now, because  
of the history of how address blocks were allocated, but in the IPv6  
world one would hope for only a single more-specific per site.

So 74k seems like an overcount, though I imagine not grossly so.   
(I.e., I wouldn't dispute it as a rough estimate, which I guess is  
all it purports to be.)

--John

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Mar 2007 08:39:51 +0100

On Mar 19, 2007, at 9:00 PM, John G. Scudder wrote:

> of the history of how address blocks were allocated, but in the  
> IPv6 world one would hope for only a single more-specific per site.

I find myself a bit skeptical of this.  I would imagine that there  
are v4 sites that are generating more than one specific from a single  
aggregate for TE purposes.  I would expect that behavior to continue  
in v6.  Perhaps the multiplier for multiple prefixes will go away,  
but I see no reason to believe that the underlying techniques for TE  
will change.

How big of a problem this is, I can't say.  I don't know if anyone  
has done any kind of analysis of the average number of more specifics  
if someone does decide to de-aggregate.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 20 Mar 2007 05:05:10 -0700

On Mar 20, 2007, at 12:39 AM, Tony Li wrote:
>> say, there may be more than one more-specific per site now,  
>> because of the history of how address blocks were allocated, but  
>> in the IPv6 world one would hope for only a single more-specific  
>> per site.
>
>
> are v4 sites that are generating more than one specific from a  
> single aggregate for TE purposes.  I would expect that behavior to  
> continue in v6.  Perhaps the multiplier for multiple prefixes will  
> go away, but I see no reason to believe that the underlying  
> techniques for TE will change.

Also another big factor that has not been mentioned (or maybe I  
missed it since I have not read all the msgs:(  is the IPv4 address  
shortage, which has been a very effectively constraint on the DFZ  
table growth.

> has done any kind of analysis of the average number of more  
> specifics if someone does decide to de-aggregate.

We did some measurements on de-aggregation a few years ago (see ref's  
at the end of our RRG presentation slides, available on RRG wiki page).
as part of PHAS (prefix hijack alert system) Colorado State has  
collected data for the current de-aggregation. If people are  
interested, we can package up the data and upload to RRG page.

I wonder what Tony meant by "analysis of the average number of more  
specifics if someone does decide to de-aggregate"--do you mean if  
someone does decide to de-aggregate IPv6 prefix?

Lixia
PS: I removed IAB from cc-list, as this thread has moved away from  
RAWS report comments.

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Mar 2007 13:44:24 +0100

> someone does decide to de-aggregate IPv6 prefix?

Lixia,

Specifically what I'd like to see is for aggregates that have more  
specifics present, what is the average number of those more specifics  
per aggregate?

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 20 Mar 2007 07:44:39 -0700

On Mar 20, 2007, at 5:44 AM, Tony Li wrote:

>>> How big of a problem this is, I can't say.  I don't know if  
>>> anyone has done any kind of analysis of the average number of  
>>> more specifics if someone does decide to de-aggregate.
>>
>> I wonder what Tony meant by "analysis of the average number of  
>> more specifics if someone does decide to de-aggregate"--do you  
>> mean if someone does decide to de-aggregate IPv6 prefix?
>
>
> Lixia,
>
> specifics present, what is the average number of those more  
> specifics per aggregate?
>
> Tony

thanks for the clarification.  The data Colorado State currently has  
(Yan Chen did it, I copied him on this reply) has all de-aggregation  
data sorted along various dimensions, should not be hard to dig out  
the number you asked.

Lixia

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Mar 2007 22:31:19 +0100

On Mar 20, 2007, at 9:55 PM, Yan Chen wrote:

> Among 248,297 prefixes RV oreg 47 peers have seen during Jan 2007,
> there are totally
> 91,519 aggregates. 11,991 aggregates are covering some prefixes
> (specifics), and on average each of them has about 13 specifics. And
> an aggregate can have specifics up to 8,000.

Thank you very much.

So, then it's reasonable to assume that when a domain that is  
performing traffic engineering via more specifics converts to IPv6  
that they will collapse the number of aggregates, but one aggregate  
will still be partitioned into multiple more specifics.

Tony

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 20 Mar 2007 22:41:09 +0100

> will still be partitioned into multiple more specifics.

That's roughly what I was trying to say (although I think I threw the  
word "site" in and muddied the water).  The point being that instead  
of M prefixes each with a deaggregation factor of N, one might expect  
1 prefix with a similar deaggregation factor.  It's not a big deal,  
but does seem to indicate that the originally cited 74k prefixes  
might be an overcount.

--John

---

From: "Yan Chen" <[email-masked]>
Date: Tue, 20 Mar 2007 14:55:41 -0600

Hi,

If I understand correctly, I think following is what you want.

I assume that "aggregates" means prefixes without any other prefixes
covering them.

If you want more detailed statistics, please let me know.

Thanks
Yan

On 3/20/07, Lixia Zhang <[email-masked]> wrote:
> >From [email-masked] Tue Mar 20 17:42:55 2007
From: "John G. Scudder" <[email-masked]>
Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt
Date: Tue, 20 Mar 2007 22:41:09 +0100
To: Tony Li <[email-masked]>
Cc: [email-masked]

--John

---

From: Jason Schiller <[email-masked]>
Date: Tue, 20 Mar 2007 17:38:39 -0500 (EST)

> will still be partitioned into multiple more specifics.

So if you wanted to project how large the IPv6 Internet table would be
tomorrow if everyone migrated to IPv6 you could do the following.

Take the existing Internet table and break it into three types of routes:
1. "Aggrgeate"  -- this is the first prefix assigned to the site.

2. "non-contiguous de-aggrgeate" -- when a site gets a second aggregate
that is not contiguous to the first aggrgegate.  (for example a site gets
assigned 1.2.3.0/24 and the three years later needs more space and gets
2.3.4.0/22)

3. "intentional more specifics" -- when a site intentionally advertises
a more specific of an aggregate (for example 2.3.4.0/22, 2.3.4.0/23,
2.3.6.0/23, and 2.3.7.0/24)

As an example take an existing site that is advertising the following:

1.2.3.0/24 
2.3.4.0/22
2.3.4.0/23
2.3.6.0/23
2.3.6.0/24

You have five prefixes that could be aggregated down to two CIDR prefixes.
If you take the total number of prefixes (5) and subtract the number of
CIDRs you could aggregate down to (2) you get the number of intentional
more specifics for TE (3).

If you take the number of intentional more specifics (3) and a single
aggregate for each AS (in this case 1) you can calculate the project IPv6
routing table (4).

If you do this for the Internet as a whole you might get something like
the following:

2007-03-21 CIDR report:
Date         Prefixes        CIDR aggrgegated
21-03-07     212772          137673

AS Sumary:
24579  	Number of ASes in routing system

212772 - 137673 = 75099 "intentional more specifics"

Add to that one aggregate for each active As in the routing system:

75099 + 24579 = 99678 routes in the IPv6 routing table if everyone did
dual stack tomorrow and multi-homing in the same was as currently done of
IPv4

=====================

ASSUMPTIONS:

ok, so there are some assumptions here.

1. All "intentional more specifics" in the IPv4 are in the routing table
for a reason, and not as an accident.  If you think some of those prefixes
in there are an accident, then the the number of routes in the IPv6
Internet table will be much worse as IPv6 provides much more roap to hang
yourself with.  (listen to my 65,536 /64s in my /48 as compaired
to my 4 /24s in my /22 when I accidentally redistribute my routes into
BGP)

2. This does not account for a single AS that has two non-contiguous
assignments that would still advertise the same number of prefixes to the
Internet routing table if it had a single contiguous
assignment. (e.g. Company.com has 3.4.5.0/24 and 4.5.6.0/24.  Both
prefixes are orignated by AS1234.  Compnay.com has an East coast HQ and a
West coast HQ.  These networks are not interconnected, but both get
transit from the same two upstream ASes.  Compnay.com trades 3.4.5.0/24
and 4.5.6.0/24 for 6.7.8.0/23.  Since each location is a stub, it will
still announce two prefixes 6.7.8.0/24 and 6.7.9.0/24.)

3. This does not account for all of the ASes that announce only a single
/24 to the Internet routing table, but would announce more specifics if
they were generally accepted.  When all sites get a /48 then something
more specific than a /48 will need to be permitted to allow fine grained
TE.  This means even small sites will be able to advertise more specifics
to do fine grained TE.  This might increase the average number of more
specifics as compaired to the total number of aggregates.

4. This does not account for all of the networks that hide behind multiple
NAT addresses from multiple providers who change the NAT address for
TE.  With IPv6 and the removal of NAT, they may need a different TE
mechanism.  That mechinism may be to advertise more specifics into the
routing table.

5. The routing size is only projected form the current IPv4 routing
table.  This does not consider the potential new IPv6 networks, such as
putting an IPv6 address on every cell phone, toaster, car, RFID, every
household in China, etc...

6. It assumes wide spread adoption of IPv6 happening tomorrow...  While
that is unlikely, is it unlikly that it might happen by 2010? 2012? 2014?

The point to this excersize is to figure out how big the routing table
might be.  If you look at historical trends for the number of ASes, the
number of routes, and the number of intentional more specifics, you can
project how big the routing table might be by 2010, 2012, 2014 if wide
spread IPv6 adoption happens by then.

You then need to examine your internal route growth and project the number
of IPv6 internal routes you might have.  From this you can project how
long befor you are required to upgrade gear, and how long current state of
the art gear will last in the network if you upgrade now.  

Lastly add in your normal equipment refresh cycle, life time you expect
out of your equipment, and how many years you depreciate your equipment
over.  From this you can tell your vendors when you need new hardware, and
how big it will need to be.

So if you are on the verge of starting a new equipment refresh, and it
takes you 2 years to fork-lift upgrade your network, and you depreciate
your equipment for 5 years, and you think you need to ready for wide
spread adoption of IPv6 by 2014, then you need to buy gear that will scale
to the needs of the projected routing table size of 2014 (1,245,412
routes).  And seven years from that repeat the process and look for gear
that can scale to a projection of seven years out from then (2,386,401
routes).

___Jason

---

From: JFC Morfin <[email-masked]>
Date: Wed, 21 Mar 2007 05:55:29 +0100

I am afraid that the reason why we users would convert to IPv6 is to 
have everyone benefit of an equal support, as it is the case with TV, 
radio, Fax, telephone today.

Each individual (will soon have/has) serveral access through local 
line, wifi, powerlines, cable as a back-up or due to some servicing 
or local constraints or policies. I have three ISPs for my SoHo, 
including an IPv6 address. If multi-homing is permitted for one it 
must be permitted for all. I am attending a multi-candidate meeting 
tomorrow organised by ISOC France for the Presidential campaign. An 
IPv6 lobby have started a campaign for "everyone his/her permanent IP 
address". I am sure that main candidates will agree to pass a law 
establishing the PI concept as on the telephone (the French 
equivalent to the FCC has run a questionnaire 2 years ago where a 
permanent telephone number area was to be related to permanent IPv6 
addresses).

I think we really have to consider that whatever the way they are 
implemented PI will be for everyone. Moreover, that an ITU /3 block 
with a topographic numbering plan as discussed some time ago, would 
considerably reduce the international tables while permitting 
national PI to everyone. Managed in using the numbering plan I 
proposed, this would be built-in, whatever the ISP being used in 
parallel or not.

jfc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 21 Mar 2007 11:44:43 +0100

> tomorrow if everyone migrated to IPv6 you could do the following.

[...]

> more specific than a /48 will need to be permitted

I'm sure a lot of people will feel that they need this, but I'm  
equally sure a lot of people will feel that they need to avoid  
prefixes longer than a /48 in their view of the global routing table.

The question that remains unanswered here is the maximum prefix  
length that will be generally accepted throughout the network. For  
IPv4, that's a /24. If you announce anything longer than that, your  
chances of seeing that announcement appear in many remote places  
aren't good.

Currently, if you go to:

http://www.apnic.net/db/min-alloc.html
http://lacnic.net/en/registro/index.html
https://www.ripe.net/ripe/docs/ripe-ncc-managed-address- 
space.html#special_purpose_ranges
http://www.arin.net/reference/micro_allocations.html

you can see that /48s are given out from the following IPv6 ranges:

2001:0C00:/23
2001:1200::/23
001:0500::/30

and /35 from:

2001:0200:/23

(There is some additional internet exchange stuff but that shouldn't  
be in the global table anyway.)

Apart from the above, the minimum allocation size is always /32. So  
it's extremely easy for operators to build filters that disallow any  
more specifics beyond /48 in the above ranges and beyond /32 for  
anything else. For IPv4, this is much more difficult and there are a  
lot of special cases that such a filter wouldn't catch.

This means, that operators who care to do so, can easily filter on  
RIR boundaries in IPv6 so only holders of a prefix shorter than /32  
get to deaggregate.

I guess this means that the deaggregators will counter by simply  
requesting more prefixes, but I don't see that approach succeeding in  
the long run.

My conclusion is that the IPv4 rules just don't apply to the IPv6  
space and the best estimate for the IPv6 global table size is the  
number of active ASes adjusted by a small factor for < /32  
deaggregation and mergers. However, now that the PI cat is out of the  
bag it's very possible that the number of ASes with a PI block will  
grow faster in IPv6 than what we've seen in IPv4.

> spread IPv6 adoption happens by then.

Don't count on wide scale IPv6 adoption before we effectively run out  
of IPv4 space. For anyone who has their IPv4 space today and doesn't  
need any extra, the incentive to move to IPv6 is minimal, and this  
won't change even after the IPv4 depletion. Since everyone else is  
still on v4, new internet users will need to connect to the existing  
v4 world in one way or another, which probably means heavy NAT,  
meaning very many users per IPv4 address. This is much more  
inconvenient than today's light NAT where, generally, only a small  
number of devices shares an IPv4 address and the end-user can control  
port mappings.

For those new users, it makes sense to adopt IPv6 in addition to  
NATed IPv4 so they can communicate amongst themselves. Only after  
this has taken off, it becomes interesting for regular IPv4 users to  
also adopt v6 to connect to the NAT-hampered users.

(Don't forget that for people who need a /24 or such, there will  
always be enough IPv4 space. It's the Comcasts and * Telecoms of this  
world that burn through millions of addresses per year that will hit  
the brick wall once they've consumed the remaining 1249 million IPv4  
addresses.)

The problem with all of this is that we probably can't make  
reasonable projections 7 years in advance so starting an upgrade  
cycle today for stuff that has to last for 7 years is problematic.  
Then again, we're only at the beginning of the video over IP  
revolution and 10 Gbit ethernet is getting long in the tooth so there  
are other reasons why I don't see today's gear being deployed in the  
core in the year 2014.