Start accepting longer prefixes as IPv4 depletes?
(My apologies if this has been discussed before, I haven't been keeping up with NANOG as well as I should lately.) As the IPv4 address space depletes, various types of use that requires IPv4 addresses will get harder. In some cases, this is unavoidable: if you want to connect a million broadband users you need a million addresses. But for hosting activities you don't need that much space. In fact, often people have to be very creative to qualify for a /24 (/20 even in ARIN-land?) just so they have a large enough assignment that they can announce it in BGP and expect it to be reachable. But you really don't need a /20 or even a /24 to host websites or the like. Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking about NAT46 solutions in the near future. (NAT46 is really best avoided.) There are two issues: 1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to < /28 instead of < /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch. 2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks. Thoughts? I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.
On Wed, Dec 8, 2010 at 10:30 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
(My apologies if this has been discussed before, I haven't been keeping up with NANOG as well as I should lately.)
As the IPv4 address space depletes, various types of use that requires IPv4 addresses will get harder. In some cases, this is unavoidable: if you want to connect a million broadband users you need a million addresses. But for hosting activities you don't need that much space. In fact, often people have to be very creative to qualify for a /24 (/20 even in ARIN-land?) just so they have a large enough assignment that they can announce it in BGP and expect it to be reachable. But you really don't need a /20 or even a /24 to host websites or the like.
Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking about NAT46 solutions in the near future. (NAT46 is really best avoided.)
There are two issues:
1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to < /28 instead of < /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch.
Just because we've been treading water as fast as possible to try to stay above the drowing point in small prefix ranges does *not* mean we have extra headroom to waste on even smaller ranges. I've started contemplating filtering out blocks smaller than /22, and trusting that somewhere, someone will be sending out a supernet that covers the smaller bits. As has been said elsewhere, previously; just because you have been allocated IP space does *not* in any way, shape, or form guarantee routability and reachability. The smaller your chunk of space, the less likely it is that other people will choose to listen to it as something discrete from the supernets that may cover it (up to, and including default). You are free to announce whatever small prefix size you would like already, today. However, it is unlikely anyone thinks so poorly of their routers as to blindly accept any and all such small prefixes from the internet at large. It is unlikely you will get much traction in getting those filters updated, due to the increasing stress todays routers are under.
2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks.
Thoughts?
Just move to v6, already. v4 is done. trying to keep it on life support is going to cost everyone time, money, and reduced life span due to increased stress. If you have not informed your senior executives that the IPv4 space you have today is likely to be all that you will ever have, as a techie, your are doing your company a disservice. If you have not informed them that in order to expand their business at all in the future, they will need to be prepared to do so using IPv6, and not IPv4, you are doing them a disservice. For new entrants into the market, who want to dip their toe into content hosting, but do not have IPv4 addresses of their own--work with an upstream provider, and get a rent-a-block of v4 from them. Get your primary infrastructure on IPv6, and use a rent-a-block of v4 space from an upstream to host a 4-to-6 proxy box to allow legacy v4 users to reach your content. I'm partial to http://trafficserver.apache.org/ myself as a v4/v6 proxy platform, but you can pick any platform you like. Configure your DNS to return quad-As that point to your real v6-based infrastructure, and configured the A record to point to your v4/v6 proxy box. All done. No need for anyone else to have to accept little tiny chunks of v4 space.
I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.
Sorry...can't help you on that front. :( Matt
On Wed, Dec 8, 2010 at 11:07 AM, George Bonser <gbonser@seven.com> wrote:
Just move to v6, already. v4 is done. trying to keep it on life support is going to cost everyone time, money, and reduced life span due to increased stress.
Exactly. People need to adopt the "v4 is done" mindset and work going forward on that premise.
+1 Good luck with that /27 of 1.0.0.0/8 space At the edge, with the down economy, i bet there are plenty of folks that are only accept /21s and shorter from their upstream ISP so they can get some more mileage out of their older gear. Cameron
On 12/8/2010 11:23, Cameron Byrne wrote:
At the edge, with the down economy, i bet there are plenty of folks that are only accept /21s and shorter from their upstream ISP so they can get some more mileage out of their older gear.
Hopefully they have a default route; ARIN now has PI /24 assignments, and none of those would have a large aggregate announcement. ~Seth
On Wed, Dec 8, 2010 at 11:37 AM, Seth Mattinen <sethm@rollernet.us> wrote:
On 12/8/2010 11:23, Cameron Byrne wrote:
At the edge, with the down economy, i bet there are plenty of folks that are only accept /21s and shorter from their upstream ISP so they can get some more mileage out of their older gear.
Hopefully they have a default route; ARIN now has PI /24 assignments, and none of those would have a large aggregate announcement.
Sorry, getting a default route from the provider was assumed in my mind and not in the email. It goes back to routers that can take only 256k routes ... they cant take full tables these days, so they just ditch the smaller blocks. The default route still work for reachability .... but not route optimization at the edge. Cameron
~Seth
On 12/8/10 11:59 AM, Matthew Petach wrote:
Just because we've been treading water as fast as possible to try to stay above the drowing point in small prefix ranges does*not* mean we have extra headroom to waste on even smaller ranges. I've started contemplating filtering out blocks smaller than /22, and trusting that somewhere, someone will be sending out a supernet that covers the smaller bits.
Except that when you have legacy resources (such as /24 end user allocations), there is no supernet announcement since these blocks could technically be anywhere in their respective regions. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On 8 dec 2010, at 19:59, Matthew Petach wrote:
Just because we've been treading water as fast as possible to try to stay above the drowing point in small prefix ranges does *not* mean we have extra headroom to waste on even smaller ranges.
It's not the size of the prefixes that's the problem, but their number. I'm working under the assumption that the new /28s (or whatever) will appear where /24s would have appeared in earlier years. We can think of several measures to limit the numbers of these small blocks, like only allowing one per AS number, or even limiting the number that the RIRs get to give out each year. Remember there's about 10 times as many prefixes as ASes, having one prefix for each of the 5000 new ASes that are given out each year is NOT the problem. It's the fact that existing ASes increase their prefix load year over year.
Just move to v6, already. v4 is done. trying to keep it on life support is going to cost everyone time, money, and reduced life span due to increased stress.
There won't be addresses to number new ISP customers in IPv4 anyomore pretty soon. But content doesn't need many addresses, especially if we get rid of artificial barriers like "you need 256 addresses to play". Eyeballs on v6 and content on v4 is workable, the other way around isn't.
and use a rent-a-block of v4 space from an upstream to host a 4-to-6 proxy box to allow legacy v4 users to reach your content.
You can't do this in a protocol agnostic way. You need to go in at layer 7 to make this work. 6 clients to 4 servers can be done with something that isn't much worse than regular NAT.
There are two issues:
1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to < /28 instead of < /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch.
2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks.
Thoughts?
Growth of the routing table will be a much larger issue once the stampede to v6 occurs. A v6 route takes 4x the resources of a v4 route. Assuming everyone multihomed in v4 space will also be multihomed in v6 space and assuming that people are going to operate in both v4 and v6 space at the same time, not only will the v4 table explode in size as it fragments, so will the v6 table explode in size at the same time. Granted there will be some consolidation through aggregation with v6 and entities who have multiple discontiguous v4 nets might consolidate into a larger v6 bloc but nevertheless, they are going to have announcements in both spaces. People dual-stacking that have routers capable of <1 million v4 routes are going to have to rethink their strategy if they are currently collecting full routes in both v4 and v6. If compromise must be made, where is one to make it? I believe that will happen with v4 because v6 will be seen as where the growth is and where the future lies and v4 seen as "legacy" and if one must compromise, compromise where you see future decline, not where there will be future growth. So, imagine a multihomed end site announcing a chunk out of one of their provider's PA space where they have that provider de-aggregate that route because the more specific is also being announced by one or more other providers. I believe the first place where compromises might be made in such cases is "I am not going to accept more specifics from PA space but I will accept small blocks from PI space". Some do that today in v6 space but I have a hunch that will begin to happen more in v4 as it begins to fragment and people become resource constrained. The result will be that some sites might find that their multihoming using v4 PA space isn't working as well as it used to, which will provide yet greater incentive to move to v6. To summarize: I believe it is going to be more difficult to get people to accept route announcements for smaller v4 blocks as the v6 table ramps up if they are dual-stacking v4 and v6 on the same gear. Put another way, I don't believe there is going to be a lot of support in bending over backwards to support yet more v4 brokenness or if the support is there in theory, there may not be as much support in practice once the herd begins to move to v6 and v4 starts to shatter into little tiny fragments.
On Dec 8, 2010, at 11:01 AM, George Bonser wrote:
There are two issues:
1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to < /28 instead of < /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch.
2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks.
Thoughts?
Growth of the routing table will be a much larger issue once the stampede to v6 occurs. A v6 route takes 4x the resources of a v4 route. Assuming everyone multihomed in v4 space will also be multihomed in v6 space and assuming that people are going to operate in both v4 and v6 space at the same time, not only will the v4 table explode in size as it fragments, so will the v6 table explode in size at the same time. Granted there will be some consolidation through aggregation with v6 and entities who have multiple discontiguous v4 nets might consolidate into a larger v6 bloc but nevertheless, they are going to have announcements in both spaces.
Actually, in most implementations, due to optimizations with IPv6 that aren't possible with IPv4, a v6 route only takes about 2x the resources of an IPv4 route. Additionally, IPv6 should go from a ~10:1 ratio of prefixes to ASNs to a ratio closer to 1.5-2:1. As such, I only expect the IPv6 table to be about 10-20x it's current size at full deployment. Significant, but, hardly what I would call an explosion.
People dual-stacking that have routers capable of <1 million v4 routes are going to have to rethink their strategy if they are currently collecting full routes in both v4 and v6. If compromise must be made, where is one to make it? I believe that will happen with v4 because v6 will be seen as where the growth is and where the future lies and v4 seen as "legacy" and if one must compromise, compromise where you see future decline, not where there will be future growth.
People running routers with less than 1MM IPv4 prefix capability probably can use defaults to cover for discarding some of the longer prefixes. Generally speaking, those are not major transit backbones where this would be harmful. (Major transit backbones have been out of room in such routers for some time now). Compromising in IPv6 won't buy much, so, I suspect the compromises will have to be made in IPv4. (let's face it, there's just not much there in a <60k route table to reduce).
So, imagine a multihomed end site announcing a chunk out of one of their provider's PA space where they have that provider de-aggregate that route because the more specific is also being announced by one or more other providers. I believe the first place where compromises might be made in such cases is "I am not going to accept more specifics from PA space but I will accept small blocks from PI space". Some do that today in v6 space but I have a hunch that will begin to happen more in v4 as it begins to fragment and people become resource constrained. The result will be that some sites might find that their multihoming using v4 PA space isn't working as well as it used to, which will provide yet greater incentive to move to v6.
People are doing this in IPv6? Really? What's the point? There simply aren't enough savings to make it significant.
To summarize: I believe it is going to be more difficult to get people to accept route announcements for smaller v4 blocks as the v6 table ramps up if they are dual-stacking v4 and v6 on the same gear. Put another way, I don't believe there is going to be a lot of support in bending over backwards to support yet more v4 brokenness or if the support is there in theory, there may not be as much support in practice once the herd begins to move to v6 and v4 starts to shatter into little tiny fragments.
Let's hope that's how it goes. The alternatives are significantly bad. Owen
Actually, in most implementations, due to optimizations with IPv6 that aren't possible with IPv4, a v6 route only takes about 2x the resources of an IPv4 route.
I considered that before I wrote the 4x but I couldn't be sure that my implementation was typical so I stuck with the worst case. It also depends on where you are talking about, RIB, FIB, or cache.
Additionally, IPv6 should go from a ~10:1 ratio of prefixes to ASNs to a ratio closer to 1.5-2:1. As such, I only expect the IPv6 table to be about 10-20x it's current size at full deployment. Significant, but, hardly what I would call an explosion.
Maybe. There are currently 36178 ASes announcing routes in v4. There are 2882 ASes announcing v6 routes. Assuming that every AS currently in v4 will eventually appear in v6 and also making an assumption that each AS in v4 will announce at least one route in v6, that would indicate at minimum a 12x growth above today. Once you get into deaggregation of PA space to accommodate multihoming or disconnected PI sites, all bets are off but 20x seems a reasonable start.
People running routers with less than 1MM IPv4 prefix capability probably can use defaults to cover for discarding some of the longer prefixes.
Yup. And that is where I was going with "their multihoming in PA space might not work as well as it used to" when that sort of thing happens on a broader scale.
Generally speaking, those are not major transit backbones where this would be harmful. (Major transit backbones have been out of room in such routers for some time now).
Yeah, I was considering networks like mine where I am trying to talk to a multihomed site that I am not directly peered with and one transit provider has some peering issue and loses a route to that destination. I need to be able to "see" that route via the other transit provider(s) in a hurry so a default probably isn't going to work well for me though I will be tempted to move in that direction once I come under resource pressure.
Compromising in IPv6 won't buy much, so, I suspect the compromises will have to be made in IPv4. (let's face it, there's just not much there in a <60k route table to reduce).
And I don't think anyone is going to *want* to compromise in v6, v4 is where they are going to begin to trim back as that is a dead-end path anyway. Compromising on the v6 side is going to generate an increase in problems going forward. Compromising on the v4 path will produce a decreasing amount of problems over time. The downhill path is the easiest to follow.
People are doing this in IPv6? Really? What's the point? There simply aren't enough savings to make it significant.
There was some chatter on this list of Verizon, for example, not taking smaller than a /32 out of PA space (but accepting down to a /48 in PI space). I don't have access to their routes so I can't say with any authority, I am repeating what was posted here by others. G
On Dec 8, 2010, at 12:01 PM, George Bonser wrote:
Actually, in most implementations, due to optimizations with IPv6 that aren't possible with IPv4, a v6 route only takes about 2x the resources of an IPv4 route.
I considered that before I wrote the 4x but I couldn't be sure that my implementation was typical so I stuck with the worst case. It also depends on where you are talking about, RIB, FIB, or cache.
FIB being the only place where there are meaningful resource constraints, I'm willing to treat it as the bottleneck. Most routers can handle several million paths in the RIB and cache overflows shouldn't be fatal if you have sufficient FIB resources.
Additionally, IPv6 should go from a ~10:1 ratio of prefixes to ASNs to a ratio closer to 1.5-2:1. As such, I only expect the IPv6 table to be about 10-20x it's current size at full deployment. Significant, but, hardly what I would call an explosion.
Maybe. There are currently 36178 ASes announcing routes in v4. There are 2882 ASes announcing v6 routes. Assuming that every AS currently in v4 will eventually appear in v6 and also making an assumption that each AS in v4 will announce at least one route in v6, that would indicate at minimum a 12x growth above today. Once you get into deaggregation of PA space to accommodate multihoming or disconnected PI sites, all bets are off but 20x seems a reasonable start.
Even at 20x (I think 15x is a more reasonable guestimate), I still wouldn't call it an explosion. 20x 3843 = 76,860 total IPv6 routes. even at 4x resources, that's less than the current IPv4 table (~340k routes). At the more realistic 2x, it's dramatically less.
People running routers with less than 1MM IPv4 prefix capability probably can use defaults to cover for discarding some of the longer prefixes.
Yup. And that is where I was going with "their multihoming in PA space might not work as well as it used to" when that sort of thing happens on a broader scale.
Actually, the people with the smaller routers are probably far enough away that it won't matter. This will only have negative impact on remote hosts that are on the same side of the closest common major transit provider.
Generally speaking, those are not major transit backbones where this would be harmful. (Major transit backbones have been out of room in such routers for some time now).
Yeah, I was considering networks like mine where I am trying to talk to a multihomed site that I am not directly peered with and one transit provider has some peering issue and loses a route to that destination. I need to be able to "see" that route via the other transit provider(s) in a hurry so a default probably isn't going to work well for me though I will be tempted to move in that direction once I come under resource pressure.
If both of your transit providers are default-free, then, likely the default will still work fine. It may not be optimal, but, it'll probably be functional in the vast majority of cases.
Compromising in IPv6 won't buy much, so, I suspect the compromises will have to be made in IPv4. (let's face it, there's just not much there in a <60k route table to reduce).
And I don't think anyone is going to *want* to compromise in v6, v4 is where they are going to begin to trim back as that is a dead-end path anyway. Compromising on the v6 side is going to generate an increase in problems going forward. Compromising on the v4 path will produce a decreasing amount of problems over time. The downhill path is the easiest to follow.
Compromising in v6 temporarily to preserve v4 functionality may be necessary in some cases. I'm not wiling to rule anything out at this point.
People are doing this in IPv6? Really? What's the point? There simply aren't enough savings to make it significant.
There was some chatter on this list of Verizon, for example, not taking smaller than a /32 out of PA space (but accepting down to a /48 in PI space). I don't have access to their routes so I can't say with any authority, I am repeating what was posted here by others.
Oh, yeah, that's JUST Verizon, and, I think they've started to get over that religion as well. However, now you're talking about the only provider on the planet with >1MM route capable routers that are actually overflowing due to the utter mess that is their intra-AS routing topology. Owen
Dear Iljitsh, Do you plan to put /28 into the DFZ routing table? You thought about routing table capacity of the today's routers.., I think prefix length around /22 is accepted, but blindly accepting any /24 prefix is not a reality today. What about the stability of the routing table without aggregation? Do you consider BGP churning? Do you think adopting LISP or similar architectures to reduce the problems mentioned above? Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 8 Dec 2010, Iljitsch van Beijnum wrote:
(My apologies if this has been discussed before, I haven't been keeping up with NANOG as well as I should lately.)
As the IPv4 address space depletes, various types of use that requires IPv4 addresses will get harder. In some cases, this is unavoidable: if you want to connect a million broadband users you need a million addresses. But for hosting activities you don't need that much space. In fact, often people have to be very creative to qualify for a /24 (/20 even in ARIN-land?) just so they have a large enough assignment that they can announce it in BGP and expect it to be reachable. But you really don't need a /20 or even a /24 to host websites or the like.
Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking about NAT46 solutions in the near future. (NAT46 is really best avoided.)
There are two issues:
1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to < /28 instead of < /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch.
2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks.
Thoughts?
I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.
On Wed, 08 Dec 2010 20:10:46 +0100, Mohacsi Janos said:
Do you think adopting LISP or similar architectures to reduce the problems mentioned above?
You're better off taking the mindset that it's time to stick a fork in IPv4, it's done. Focus your attention on getting LISP or similar adopted for IPv6 before *that* routing table explodes.
On Dec 9, 2010, at 2:10 AM, Mohacsi Janos wrote:
Do you think adopting LISP or similar architectures to reduce the problems mentioned above?
Yes. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
On Wed, Dec 8, 2010 at 11:31 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Dec 9, 2010, at 2:10 AM, Mohacsi Janos wrote:
Do you think adopting LISP or similar architectures to reduce the problems mentioned above?
Yes.
No. I still fail to see the value of LISP in a mature and sane IPv6 world. LISP may have value in a immature and insane IPv4 and IPv6 world. Cameron
On Dec 9, 2010, at 2:38 AM, Cameron Byrne wrote:
I still fail to see the value of LISP in a mature and sane IPv6 world.
Abstraction of the global routing table away from direct dependence upon the underlying transport in use at a given endpoint network alone offers huge benefits for futureproofing; there are lots of other benefits as well, for mobility, CDNs, and so forth. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
On Wed, Dec 8, 2010 at 11:41 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Dec 9, 2010, at 2:38 AM, Cameron Byrne wrote:
I still fail to see the value of LISP in a mature and sane IPv6 world.
Abstraction of the global routing table away from direct dependence upon the underlying transport in use at a given endpoint network alone offers huge benefits for futureproofing; there are lots of other benefits as well, for mobility, CDNs, and so forth.
I believe a lot of folks think the routing paths should be tightly coupled with the physical topology. If not, there is MPLS. If underlying transport is IPv6, i don't see the incremental value (hence mature IPv6 world comment, most major ISPs are pretty well along the way). IP Mobility as in Mobile IP already exists .... not terribly popular. There is already abstraction within most ISPs with MPLS. Yet another layer of abstraction is just not something i would consider lightly with Internet scale. Just my humble opinion. Today, IPv6 provides real value with larger address space. MPLS provides real value with FRR and network virtualization (MPLS L3 VPNs). In a mature IPv6 world, that is sane, i am not sure what the real value of LISP is. But, IMHO, i do think there is something to the long term value of ILNP. I am just very biased again additional tunnels, encapsulation/overhead, complexity, and that is what LISP is, edge to edge tunnels. Then there is the question of who benefits from LISP and who pays. The edge pays and the DFZ guys benefit (they deffer router upgrades).... i already pay the DFZ guys enough today. Cameron
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
Cameron, On Dec 8, 2010, at 12:01 PM, Cameron Byrne wrote:
I believe a lot of folks think the routing paths should be tightly coupled with the physical topology.
The downside, of course, being that if you change your location within the physical topology, you have to renumber. Enterprises have already voted with their feet that this isn't acceptable with IPv4 and they'll no doubt do the same with IPv6.
In a mature IPv6 world, that is sane, i am not sure what the real value of LISP is.
Sanity is in the eye of the beholder. The advantage a LISP(-like) scheme provides is a way of separating location from identity, allowing for arbitrary topology change (and complexity in the form of multi-homing) without affecting the identities of the systems on the network. Changing providers or multi-homing would thus not result in a renumbering event or pushing yet another prefix into the DFZ.
Then there is the question of who benefits from LISP and who pays. The edge pays and the DFZ guys benefit (they deffer router upgrades).... i already pay the DFZ guys enough today.
Increased size/flux in the DFZ as a result of PI allocations, more specifics announced for traffic engineering, and multi-homing _will_ increase the cost to the "DFZ guys" as they have to upgrade their routers to deal with growth. It is unlikely they'll not pass that cost on to their customers. Regards, -drc
On 12/8/2010 3:12 PM, David Conrad wrote:
Cameron,
On Dec 8, 2010, at 12:01 PM, Cameron Byrne wrote:
I believe a lot of folks think the routing paths should be tightly coupled with the physical topology.
The downside, of course, being that if you change your location within the physical topology, you have to renumber. Enterprises have already voted with their feet that this isn't acceptable with IPv4 and they'll no doubt do the same with IPv6.
In a mature IPv6 world, that is sane, i am not sure what the real value of LISP is.
Sanity is in the eye of the beholder. The advantage a LISP(-like) scheme provides is a way of separating location from identity, allowing for arbitrary topology change (and complexity in the form of multi-homing) without affecting the identities of the systems on the network. Changing providers or multi-homing would thus not result in a renumbering event or pushing yet another prefix into the DFZ.
I think the issue, and correct me if I'm wrong, is that LISP does not address issues of traffic engineering? A lot of the additional routes in DFZ are there specifically to handle traffic engineering. The flow of traffic is usually based on ASN from a human standpoint, but dividing networks up and changing priorities on a per network basis is the mechanism BGP allows for determining that flow of traffic. Another large increase in DFZ was due to constraints. Even with engineering, I might divide a /16 into 4 /18 networks and be able to obtain the metrics I need. ARIN, over the years gave me a lot of /20 networks. It has been hopeful (and policy is still evolving with ARIN to accomplish this for our region) that IPv6 would not suffer from having to receive multiple small allocations which do not align with our traffic engineering needs but just add additional routes. The policy currently being discussed on PPML supports assigning networks larger than the currently utilized one if necessary and not requiring a renumber (which effectively triples your allocated space or more but only adds a single additional route to DFZ). Jack
Date: Wed, 08 Dec 2010 15:34:47 -0600 From: Jack Bates <jbates@brightok.net>
On 12/8/2010 3:12 PM, David Conrad wrote:
Cameron,
On Dec 8, 2010, at 12:01 PM, Cameron Byrne wrote:
I believe a lot of folks think the routing paths should be tightly coupled with the physical topology.
The downside, of course, being that if you change your location within the physical topology, you have to renumber. Enterprises have already voted with their feet that this isn't acceptable with IPv4 and they'll no doubt do the same with IPv6.
In a mature IPv6 world, that is sane, i am not sure what the real value of LISP is.
Sanity is in the eye of the beholder. The advantage a LISP(-like) scheme provides is a way of separating location from identity, allowing for arbitrary topology change (and complexity in the form of multi-homing) without affecting the identities of the systems on the network. Changing providers or multi-homing would thus not result in a renumbering event or pushing yet another prefix into the DFZ.
I think the issue, and correct me if I'm wrong, is that LISP does not address issues of traffic engineering? A lot of the additional routes in DFZ are there specifically to handle traffic engineering.
Yes. Locator-ID separation means that you would no longer have to add prefixes to the DFZ for traffic engineering. That would be in the province of the locator part of the operation. I see nothing preventing this from being done in LISP and being done in a much more manageable manner. This does, of course, increase the number of locators in the FIB, but the number of locators would be tiny compared to the current FIB, so I don't see an issue.
The flow of traffic is usually based on ASN from a human standpoint, but dividing networks up and changing priorities on a per network basis is the mechanism BGP allows for determining that flow of traffic.
Another large increase in DFZ was due to constraints. Even with engineering, I might divide a /16 into 4 /18 networks and be able to obtain the metrics I need. ARIN, over the years gave me a lot of /20 networks. It has been hopeful (and policy is still evolving with ARIN to accomplish this for our region) that IPv6 would not suffer from having to receive multiple small allocations which do not align with our traffic engineering needs but just add additional routes.
So use locator to do the job right instead of twisting things with machinations in routing that the protocols were not designed for. I am simply amazed that, in this day and age, people still seem to not understand the value of locator-ID separation! Almost all early network protocols other than IP did this. IP, for good reason, became dominant and, in the process, the concept was largely forgotten. There was a contingent of folks who tried to get it into IPv6 as a base part of the standard, but they lost. (Yes, I understand the prevailing arguments, but it was till a HUGE mistake, IMHO.) It certainly would have been much better if locator-ID separation was built into the protocol (IPv6) rather than being shoe-horned in after the fact, but I really think we still need it. Note, LISP has some real corner case issues and may not be implementable on a general basis. I want locator-ID separation, but that does not necessarily mean LISP. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Dec 8, 2010, at 12:01 PM, Cameron Byrne wrote:
On Wed, Dec 8, 2010 at 11:41 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Dec 9, 2010, at 2:38 AM, Cameron Byrne wrote:
I still fail to see the value of LISP in a mature and sane IPv6 world.
Abstraction of the global routing table away from direct dependence upon the underlying transport in use at a given endpoint network alone offers huge benefits for futureproofing; there are lots of other benefits as well, for mobility, CDNs, and so forth.
I believe a lot of folks think the routing paths should be tightly coupled with the physical topology. If not, there is MPLS.
LISP doesn't separate the routing paths from the physical topology. It abstracts the end system identifiers so that they are not tied to the physical topology.
If underlying transport is IPv6, i don't see the incremental value (hence mature IPv6 world comment, most major ISPs are pretty well along the way). IP Mobility as in Mobile IP already exists .... not terribly popular.
It's barely had a chance to see even small deployments, so, judging its popularity is extremely premature. The value of LISP is the ability to have a strictly hierarchical routing table with good aggregation where the Locator (routing field) in the packet header is not directly tied to the Identifier (end-system globally unique value). IMHO, a more ideal way to do this would be to add 32 bits to the packet header for "destination ASN" and do IDR based on that, but, changing the packet header at this time is hard and would require a new IP version number.
There is already abstraction within most ISPs with MPLS. Yet another layer of abstraction is just not something i would consider lightly with Internet scale. Just my humble opinion.
MPLS doesn't accomplish IDR abstraction which is the value here.
Today, IPv6 provides real value with larger address space. MPLS provides real value with FRR and network virtualization (MPLS L3 VPNs). In a mature IPv6 world, that is sane, i am not sure what the real value of LISP is.
But, IMHO, i do think there is something to the long term value of ILNP. I am just very biased again additional tunnels, encapsulation/overhead, complexity, and that is what LISP is, edge to edge tunnels. Then there is the question of who benefits from LISP and who pays. The edge pays and the DFZ guys benefit (they deffer router upgrades).... i already pay the DFZ guys enough today.
I agree that tunnels and encapsulation are not ideal. Hence my thinking it would be better to rev. IP again and build the destination ASN into the packet header with a defined value for "not yet known". Owen
On 12/8/2010 4:12 PM, Owen DeLong wrote:
IMHO, a more ideal way to do this would be to add 32 bits to the packet header for "destination ASN" and do IDR based on that, but, changing the packet header at this time is hard and would require a new IP version number.
My only problem with this is how to get certain percentages of traffic to come through different transits. I realize I could specify a separate ASN, and balance traffic based on ASN instead of network, but I'm not sure what is saved. ie, 4 ASNs vs 4 networks? The other issue is that networks are not all equal. Thought I presume you could shift networks around to different ASNs to accomplish this. My hope is that the nature of v6 will actually reduce the routing table naturally (even though we are storing larger prefixes). Handing out address space on a 3-6 month curve is what has made it a nightmare. I'm going to go out on a limb (and not read the last BGP summary reports) and say that ISPs being assigned fragmented space has caused more routing table bloat than deaggregation for traffic engineering. Jack
On Dec 8, 2010, at 2:48 PM, Jack Bates wrote:
On 12/8/2010 4:12 PM, Owen DeLong wrote:
IMHO, a more ideal way to do this would be to add 32 bits to the packet header for "destination ASN" and do IDR based on that, but, changing the packet header at this time is hard and would require a new IP version number.
My only problem with this is how to get certain percentages of traffic to come through different transits. I realize I could specify a separate ASN, and balance traffic based on ASN instead of network, but I'm not sure what is saved.
If you have 200 prefixes and 3 routing policies, you need 3 ASNs in the global routing table instead of 200 prefixes in the global routing table.
ie, 4 ASNs vs 4 networks? The other issue is that networks are not all equal. Thought I presume you could shift networks around to different ASNs to accomplish this.
This assumes a 1:1 ratio between prefixes and routing policies. This is unrealistic in all but the most trivial of networks.
My hope is that the nature of v6 will actually reduce the routing table naturally (even though we are storing larger prefixes). Handing out address space on a 3-6 month curve is what has made it a nightmare. I'm going to go out on a limb (and not read the last BGP summary reports) and say that ISPs being assigned fragmented space has caused more routing table bloat than deaggregation for traffic engineering.
Yes... It should. However, even with the reduced IPv6 routing table, there will be circumstances where multiple prefixes can efficiently be coalesced into common routing policies. Unfortunately, the current designs of IPv4 and IPv6 do not allow us to actually do so. What I am proposing would. Owen
On 12/8/2010 5:07 PM, Owen DeLong wrote:
This assumes a 1:1 ratio between prefixes and routing policies. This is unrealistic in all but the most trivial of networks.
Yet we can achieve much closer to this with IPv6 due to looser allocation policies.
Yes... It should. However, even with the reduced IPv6 routing table, there will be circumstances where multiple prefixes can efficiently be coalesced into common routing policies. Unfortunately, the current designs of IPv4 and IPv6 do not allow us to actually do so. What I am proposing would.
I agree it would be good, and every new person to BGP always asks why we don't route packets by the AS (seems like common sense). However, I think we'll have to wait and see on how well v6 manages with the new allocation policies and if the routing table for it drops to a reasonable level. This would be more acceptable than trying to shim on the v6 protocol. The problem is, once a protocol is standardized and implemented by the masses, changing is very difficult. It's going to be a bumpy road as we complete v6 transition, and I doubt anyone is looking forward to another change of that magnitude. Jack
On 8 dec 2010, at 23:48, Jack Bates wrote:
I'm going to go out on a limb (and not read the last BGP summary reports) and say that ISPs being assigned fragmented space has caused more routing table bloat than deaggregation for traffic engineering.
Why would ISPs get fragmented space? The RIRs are still getting /8s from IANA at the moment. And most deaggregation is not for traffic engineering because the attributes are all the same.
On Dec 8, 2010, at 3:08 PM, Iljitsch van Beijnum wrote:
On 8 dec 2010, at 23:48, Jack Bates wrote:
I'm going to go out on a limb (and not read the last BGP summary reports) and say that ISPs being assigned fragmented space has caused more routing table bloat than deaggregation for traffic engineering.
Why would ISPs get fragmented space? The RIRs are still getting /8s from IANA at the moment.
Because ISPs get multiple blocks over years from RIRs and don't return their old small block and renumber into a new large one.
And most deaggregation is not for traffic engineering because the attributes are all the same.
Which would support the above statement. Owen
On Wed, Dec 8, 2010 at 5:08 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 8 dec 2010, at 23:48, Jack Bates wrote:
I'm going to go out on a limb (and not read the last BGP summary reports) and say that ISPs being assigned fragmented space has caused more routing table bloat than deaggregation for traffic engineering.
Why would ISPs get fragmented space? The RIRs are still getting /8s from IANA at the moment. And most deaggregation is not for traffic engineering because the attributes are all the same.
Because ISP networks are not fixed sized entities that never add more infrastructure (or more customers), like some end users might be. ISPs get contiguous assignments, but when they later require more IP address space, they apply for more space, and wind up with a new assignment that is not aggregable with the previous assignment(s). The RIRs do not predict their members' future requirements, and maintain enough unallocated buffer space around allocations to provide a contiguous extension when more address space is requested. -- -JH
On 8 dec 2010, at 20:10, Mohacsi Janos wrote:
Do you think adopting LISP or similar architectures to reduce the problems mentioned above?
Did the LISP guys solve failover after a locator goes away? And what about the MTU issue? Do you lose initial packets when there is no mapping state yet? (It's been a couple of years since I was current on the RRG stuff and LISP.)
On 12/08/2010 11:08 PM, Iljitsch van Beijnum wrote:
On 8 dec 2010, at 20:10, Mohacsi Janos wrote:
Do you think adopting LISP or similar architectures to reduce the problems mentioned above? [...] Do you lose initial packets when there is no mapping state yet?
Yes. But there are proposals to minimize the chances of that occurring, by pro-actively refreshing mappings in the local cache before their TTL expires, and warming up the cache with all entries of an upstream resolver (with a bulk cache transfer) at router boot time. -Lorand Jakab
On 08/12/2010 20:30, Iljitsch van Beijnum wrote:
Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking about NAT46 solutions in the near future. (NAT46 is really best avoided.)
This was discussed at length during the policy discussions at the recent AfriNIC conference. The soft landing policy was passed with a provision to allocate blocks as small /27. Warning labels were pasted all over this but were ultimately overlooked in favour of getting the policy adopted ASAP.
1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to< /28 instead of< /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch.
For one think the /24 limit places a barrier to entry on de-aggregation. I don't think that there will be a shortage of prefixes post exhaustion. /24s will be easy to carve out of larger allocations for trading/redistribution. On the operational side I have come across people who carry partial tables on their networks to avoid spending money on upgrades. One way that they seem to be pruning their tables is to drop long prefixes (just dropping /24 makes a big difference) I suspect that this will happen more as people focus their effort and CPU cycles on making IPv6 work.
2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks.
Its too late to really be thinking along the lines this kind of structured address allocation IMO. If we ever were to get to /28 allocations they would most likely be from many recovered fragments of address space.
I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.
I suspect that the operational community would not stand behind this :-) -- Graham Beneke
In a message written on Wed, Dec 08, 2010 at 07:30:52PM +0100, Iljitsch van Beijnum wrote:
I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.
There is no RIR policy here. There is no authority which can tell you what length are prefixes are accepted. Each backbone network makes their own decision on how to filter their customers and peers. If backbones find it commercially worth while to accept /28's from customers and route them, they will do just that. Some will do it relatively quickly, others will hold out and filter them for years. This is not something RIR's, IETF, NANOG, or anyone else can fix, and in fact they should not try to fix. It will sort itself out, in due time. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Dec 8, 2010, at 11:17 AM, Leo Bicknell wrote:
In a message written on Wed, Dec 08, 2010 at 07:30:52PM +0100, Iljitsch van Beijnum wrote:
I'm hoping to get some modest support here before jumping into the RIR policy shark tanks. There is no RIR policy here.
Minimum PI allocation size. Regards, -drc
participants (17)
-
Brielle Bruns -
Cameron Byrne -
David Conrad -
Dobbins, Roland -
George Bonser -
Graham Beneke -
Iljitsch van Beijnum -
Jack Bates -
James Hess -
Kevin Oberman -
Leo Bicknell -
Loránd Jakab -
Matthew Petach -
Mohacsi Janos -
Owen DeLong -
Seth Mattinen -
Valdis.Kletnieks＠vt.edu