Print

[onefouronenet]

Ok, so I was thinking.
Currently how many routes are in the IPv6 BGP table?
How is BGP going to stand up to millions of routes?
I work for a local ISP and our router has 286K and some change, IPv4 that is.
I know we have customers that test BGP and try it on a slower box, and it gets hammered working through all of the routes (ipv4).
Am I missing something or could this be a real problem with BGP and IPv6? We haven't run ipv6 BGP yet.
Sorry if this was discussed already.

Your Thoughts?

[kcochran]

Currently, there are about 1900 routes in the BGP tables for IPv6.  Now, do note that only approximately 5% of IPv4 ASNs also announce IPv6 prefixes at this time.  If it were a linear progression, you'd only be looking at about 40,000 v6 prefixes when everyone's onboard.  I don't think it's going to be linear.  We'll see as the next two years pan out how this growth line is going to go, and whether it'll be more geometric or exponential.

More information on v4 vs. v6 usage and numbers can be found at http://bgp.he.net/ipv6-progress-report.cgi

[onefouronenet]

How could there only be 40,000 routes (possibly)
If the ipv4 table we pull has 284,000?
BGP route aggregation?
If I look at the prefixes in the table, they are all /32's 48's or 40's
And That would be my guess why there aren't that many prefix's in it yet.

[kcochran]

There'd only be 40k routes if each ASN that isn't announcing IPv6 announces as many as those that are.  I don't see that likely.  Also some current ASNs are constrained on their traffic engineer options due to upstreams not supporting IPv6.  Odds are we'll see something more akin to the existing IPv4 count than 40k routes.  Now where on the line between the two, we won't know for a while yet.

[onefouronenet]

Well yes, This wouldn't be for quite awhile. I'm talking once we hit the point of almost full ipv6 usage. To the point of ipv4 being phased out.
And its that point I'm thinking BGP is going to get overwhelmed.

[kcochran]

You're also looking at several years of advancements in router hardware and software before that point.  Folks running downrev equipment will likely just have to cope with partial feeds or default only sessions.

[onefouronenet]

Thats a very good point, and something I wasn't thinking about. In a few years we could have routes capable of full ipv6 tables no problem. I guess I was taking todays hardware at the level of years ahead of this time. Kind of like trying to run vista on a 486

[jimb]

I've had similar thoughts but more about IGPs than EGPs and what sort of hardware it will take to handle IPv6.  Especially ones like Comcast who serve legions of residential end users.

I'm presuming that many ISPs will be assigning fairly long prefixes to end users... single or multiple /64s, maybe /48s, /56s or /60s.  Will that not result in a bunch of OSPF or EIGRP routes and pretty huge tables?  I know that a lot of the routes will be aggregated as they get closer to the core, but I expect that the routers closer to the edge which serve a lot of customers will have some pretty big tables, as every customer would need at least one /64 route, no? 

And of course the management complexity of all this will get more difficult also.  I suspect that customer facing routers will need a lot of dynamically configured static routes, unless CPE routers, or the cable or DSL modems or whatever can be trusted to participate in the IGP.

Also, what about the hardware?  Does most equipment these days have "hardware accelerated" support for v6, dedicated ASICs, etc, like they've had for v4 for years?  Or will many ISPs have to upgrade their SUP cards in their 65XXs and such?  RAM requirements of course bill be bigger too, no?

Although, I'd hope that just about anything made in the last five years or so will be in pretty good shape.

[snarked]

Note that there's also fewer routes because each organization is getting a single IPv6 /32, which is enough (2^96 addresses) to cover their entire network regardless of who they are, as opposed to some organizations that have several IPv4 allocations that can't be combined/simplified.  Therefore, less fragmentation of routes => simpler table.  Thus, the IPv6 table will start reaching the density of the current IPv4 table when alot of new organizations that never had an IPv4 allocation start joining in the fun/mess.

Older equipment may have a problem eventually as the IPv6 information necessary to be stored will be about 3x the size of IPv4 information, due to the 4x size of the IP address fields.  There's alot of old-equipment out there - because some people are of the opinion:  "It works so why upgrade it?"  They don't recognize the change coming.  For example, Cogent, one of the top 10 tier 1 carriers, has an IPv6 allocation since 2003 but has yet to deploy IPv6 in their network.  Many domain registrars still don't accept IPv6 glue for .com domains (e.g. register.com).  In contrast, the registrar I use will store IPv6 glue even for domains in TLD's that don't yet accept IPv6 glue - for when they finally do.

When it comes to ISPs that subdivide and farm out smaller ranges (like HE), they still publish a single /32 to the world, even if internally, they split up smaller CIDR routes to individual peering points (e.g. tunnel servers, etc).  So, what external BGP servers see is only the /32, thus keeping the routing table simpler than if every provider published each /64 that was routable because a client was assigned.

Why would a provider need to assign multiple /64's to any client?  Technically, IPv6 stateless autoconfiguration need not occur at a /64 boundary.  Despite the RFCs on the topic, any smaller CIDR boundary (higher-valued number) should be possible.

For example, my co-location provider, which HE is its only IPv6 transit peer, has a /32.  I'm assigned officially a /64 (which might be a /48 as my 4th quad is all zeros), and the rest is apparently unassigned for now (as I'm the only IPv6 customer currently - so there are (2^32)-2 /64's available - they reserved the all-zero entry for themselves; currently unused).  However, the BGP table will show only the /32.  Only when packets for unassigned sub-routes hit their network will anyone find out whether a sub-route smaller than /32 is actually routable.  Within my /64, only about 27 individual addresses will respond to the outside even though I have (2^64)-3 available (3 excluded are: all zeros*, all ones*, and the gateway address on my ethernet assigned to the facility's router).

* - I am aware that under IPv6, a node that doesn't know its own address uses "::" instead of all zeros within its prefix-masked-network, and that there is technically no "broadcast" (all ones) defined for IPv6, but this holdover in design from IPv4 is still present in some IPv6-capable routers.

Some people will still have to upgrade.

Also remember that due to "6to4", anyone who has an IPv4 address also has a /48 in the 2002::/16 "network."  2^80 IPv6 addresses isn't enough (by itself, let alone in combination with any native IPv6 allocation)?

[jimb]

@snarked: not sure if you were answering me.  I wasn't really talking about BGP.  It's presumed that routes will be aggregated in the BGP core.

Anyway, I realize that >64 prefix lengths are possible.  I'm just not sure how that works out with autoconfiguration.  Sure, "technically" it could work, but I think the standard requires the generation of EUI-64s.  I haven't read the RFC though so I don't know if there is provision for smaller host numbers.  /64s seem to be "the standard" at this point.  I should try to run radvd with a longer prefix and see if interfaces still autoconfigure on various OS' proto stacks.  It could be as simple as carefully truncating an EUI-64, perhaps. 

Putting that question aside, of course, someone assigned a /64 could subnet it any way they please if they use manual assignment or DHCPv6.  Actually, I was somewhat surprised that HE uses /64s for tunnel interface IPs.  I expected a more IPv4-like /126 (equiv of a /30 under v4, which I've commonly used for these sorts and other "transit net" situations).  So it seems that /64s are the commonly accepted longest prefix length.

And getting back to what I was really talking about in my post, even in cases where end users are assigned single /64s, there will still be a need to assign a route for that /64, however it's done.  Right now, in most residential internet situations, customers either get assigned a single public IP via DCHP or PPPoX, and their internal nets are all RFC-1918/NAT, not requiring a route entry to be created by the ISP except for the LAN on which all those customer IPs live.  With IPv6 this will change, since customer IP space wont just live on "the edge" anymore.  Residential situations will become more like business internet situations where routes are often needed and public space often lives behind a user's edge router/firewall.