Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
Nice article relating to the original subject of the post. I didn't see if it had be previously posted. http://ccie-in-3-months.blogspot.com/2011/03/trying-to-calculate-ipv6-bgp-table-in.html -Hammer- I was a normal American nerd. -Jack Herer On Sat, Mar 12, 2011 at 9:13 PM, Joe Maimon jmai...@ttec.com wrote: Leo Bicknell wrote: In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong wrote: On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: Well, I at least think an option should be a /80, using the 48 bits of MAC directly. This generates exactly the same collision potential as today we have with a /64 and an EUI-64 constructed from an EUI-48 ethernet address. The router is already sending RA's for SLAAC to work, sending along one of a well-known set of masks would be a relatively minor modification. How would you use that on a Firewire netowrk or FDDI or any of the other media that uses 64-bit MAC addresses? It wouldn't. Yes it would. It works for any size subnet that can fit both the RA node and the auto configuring one, from /0 - /127. And it is even backwards compatible. 1) Listen to RA, discover subnet size and whether to perform autoconfiguration, for backwards compatibility, assume /64 size if not included in RA. 2a) Generate address using phy bits, right aligned up to the lesser of subnet/phy size. Use 1fff as leftmost host bits if the subnet size is 64 and the phy is 48. 2b) Use any other algorithm that may be more desirable, such as one that helps preserves privacy and that contains /dev/random as one of its inputs. The randomness can be optionally initially confined to the subnet bits that exceed the phy bits, if any. 3) Perform DAD 4a) Collision, goto 2b, remembering the previous values and avoiding them. Retry 2a and forget all avoided values when they total up to (subnet size ** 2) - 3. 4b) No collision, happy surfing. 5) RA values change/expire, goto 1 Why is the ability to blindly embed the phy L2 into an auto-configured L3 address considered a prerequisite, let alone a universally good idea? I'm not proposing a solution for everything, just a useful case for some things. I don't want to change say, RIR policy that you can allocate a /64, just allow operators to use /80's, or /96's in a more useful way if they find that useful. Basically I think the IETF and IPv6 propoents went a bit too far down the one size fits all route. It has nothing to do with how many numbers may or may not be used, but everything to do with the fact that you often have to fit inside what's been given to you. If you're stuck with a monopoly provider who gives you a /64 to your cable modem there should be easy options to split it up and get some subnets. Leaving scarcity behind should not mean kicking flexibility to the curb as well. Just because SLAAC may work best with /64 should not mean that it must only work with a /64. And failing with an unconfigurable stack when DAD detects a collision means that SLAAC is not a guaranteed safe general use option, contrasted with DHCP and the possibility of conflict detection and reaction. Using bad design choices as justification for requiring additional ones simply means that SLAAC is broken as designed. It also means attempts to fix it are going to run up against entrenched opposition. Which is readily apparent. DHCPv6 needs to be fixed with address and router options and then all DHCPv6 servers/helpers should be configurable to disable all RA on a segment by way of beaconing their own poison-reverse RA. Joe
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 11, 2011, at 11:22, Jeff Wheeler wrote: I think there are a lot of people who throw around the SLAAC argument like it's actually good for something. Do these people know what SLAAC does? For core networks, it doesn't do anything. For hosting/datacenter networks and cluster/VPS environments, again, it doesn't do anything. Zero benefit. Doesn't SLAAC give you automatic MAC address to IP mapping? It'll save you manually doing that (in an otherwise well controlled environment). - ask
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On 14 Mar 2011, at 23:30, Ask Bjørn Hansen a...@develooper.com wrote: Doesn't SLAAC give you automatic MAC address to IP mapping? It'll save you manually doing that (in an otherwise well controlled environment). No, it doesn't. On some systems, the mac address is used to create the ipv6 address, but not on others (e.g. windows 7). Nick
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 14, 2011, at 16:38, Nick Hilliard wrote: Doesn't SLAAC give you automatic MAC address to IP mapping? It'll save you manually doing that (in an otherwise well controlled environment). No, it doesn't. On some systems, the mac address is used to create the ipv6 address, but not on others (e.g. windows 7). Sorry, I made the mail a bit too short I supposed. Well controlled environment in my case is a bunch of relatively homogeneous linux server systems (plain hardware and virtualized), all managed by the same team. - ask -- Ask Bjørn Hansen, http://askask.com/
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Fri, Mar 11, 2011 at 8:14 PM, Jeff Wheeler j...@inconcepts.biz wrote: It's the same thing that happens if you toss a /8 on an IPv4 LAN and start banging away at the ARP table, while expecting all of your legitimate hosts within that /8 to continue working correctly. We all know that's crazy, right? This is a valid concern. However... How is it suddenly less crazy to put an even larger subnet on an IPv6 LAN without gaining any direct benefits from doing so? [...] This is not a valid statement. I understand that you don't value the benefits we find with /64 or less, but we find value there, and it's really important to us, and they're things which were explicitly hoped for and planned for with IPv6 transition. The problem you pointed out, with a single host overrunning switch tables, can be outsmarted rather than brute forced by mandating small enough subnets that it doesn't exist. If we presume that the originating host doesn't fake its' layer 2 MAC as it's faking its layer 3 address, it's pretty trivial; you build in a software option that puts a maximum number of IPs per MAC. You balance virtualization cluster size limits with preemptive defense against this type of DOS when you do that, but balance points around 1E2 to 1E3 seem to me to be able to handle that just fine. You build in an override for switches / L2 gateways, or by port, or whatever other tuning mechanisms make sense (default to 10, override for your VMware cluster box and your switches...). If the originating host does try to fake its layer 2 MAC, you can detect new floods of new MACs via existing mechanisms. Plenty of port MAC map / allowed MAC mechanisms already exist for basic LAN security purposes. You just dump the fake MACs on the floor. The world is not perfect, and I'm sure there are still new vulnerabilities out there. But we can smart this one. If we can't smart this one, I'll be extremely surprised and disappointed. -- -george william herbert george.herb...@gmail.com
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
Leo Bicknell wrote: In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong wrote: On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: Well, I at least think an option should be a /80, using the 48 bits of MAC directly. This generates exactly the same collision potential as today we have with a /64 and an EUI-64 constructed from an EUI-48 ethernet address. The router is already sending RA's for SLAAC to work, sending along one of a well-known set of masks would be a relatively minor modification. How would you use that on a Firewire netowrk or FDDI or any of the other media that uses 64-bit MAC addresses? It wouldn't. Yes it would. It works for any size subnet that can fit both the RA node and the auto configuring one, from /0 - /127. And it is even backwards compatible. 1) Listen to RA, discover subnet size and whether to perform autoconfiguration, for backwards compatibility, assume /64 size if not included in RA. 2a) Generate address using phy bits, right aligned up to the lesser of subnet/phy size. Use 1fff as leftmost host bits if the subnet size is 64 and the phy is 48. 2b) Use any other algorithm that may be more desirable, such as one that helps preserves privacy and that contains /dev/random as one of its inputs. The randomness can be optionally initially confined to the subnet bits that exceed the phy bits, if any. 3) Perform DAD 4a) Collision, goto 2b, remembering the previous values and avoiding them. Retry 2a and forget all avoided values when they total up to (subnet size ** 2) - 3. 4b) No collision, happy surfing. 5) RA values change/expire, goto 1 Why is the ability to blindly embed the phy L2 into an auto-configured L3 address considered a prerequisite, let alone a universally good idea? I'm not proposing a solution for everything, just a useful case for some things. I don't want to change say, RIR policy that you can allocate a /64, just allow operators to use /80's, or /96's in a more useful way if they find that useful. Basically I think the IETF and IPv6 propoents went a bit too far down the one size fits all route. It has nothing to do with how many numbers may or may not be used, but everything to do with the fact that you often have to fit inside what's been given to you. If you're stuck with a monopoly provider who gives you a /64 to your cable modem there should be easy options to split it up and get some subnets. Leaving scarcity behind should not mean kicking flexibility to the curb as well. Just because SLAAC may work best with /64 should not mean that it must only work with a /64. And failing with an unconfigurable stack when DAD detects a collision means that SLAAC is not a guaranteed safe general use option, contrasted with DHCP and the possibility of conflict detection and reaction. Using bad design choices as justification for requiring additional ones simply means that SLAAC is broken as designed. It also means attempts to fix it are going to run up against entrenched opposition. Which is readily apparent. DHCPv6 needs to be fixed with address and router options and then all DHCPv6 servers/helpers should be configurable to disable all RA on a segment by way of beaconing their own poison-reverse RA. Joe
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 11, 2011, at 2:33 PM, Owen DeLong wrote: There's a HUGE difference between IP unnumbered and link-local. In all honesty, at the macro level, I don't see it; if you wouldn't mind elaborating on this, I would certainly find it useful. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Thu, Mar 10, 2011 at 10:51 PM, George Bonser gbon...@seven.com wrote: And I say making them /127s may not really make any difference. Say you make all of those /127s, at some point you *are* going to have a network someplace that is a /64 that has hosts on it and that one is just as subject to such an attack. If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. The end result is the same. You have managed to re-arrange the deck chairs. Have another squeeze at that water balloon. Again, this is the argument put forth by the RFC wavers, that you can't solve the problem because you must want to configure /64s for ... what, exactly? Oh, right, SLAAC. More on that below. If I'm a content provider, I don't have to configure a /64 for my content farm. I can configure a /120 or whatever subnet size is practical for my environment. I can also use link-local addressing on my content farm LANs and route subnets to my content boxes, if that is somehow more practical than using a smaller subnet. If you are a service provider where practically all of your links are point to points, sure. No, you can avoid configuring /64s if you don't need SLAAC. Who needs SLAAC? I don't. It has absolutely no place in any of my environments. It seems to me that DHCPv6 will do everything which SLAAC does, and everything SLAAC forgot about. The complexity argument is pretty much indefensible when the trade-off is configuring DHCPv6 vs turning a bunch of router knobs and hoping no one ever targets your LANs with an NDP DoS. We didn't need much more host addressing, we needed more subnet addressing. I would have settled for 16 bits of host addressing and 112 bits of subnet addressing and I suppose nothing prevents me from doing that except none of the standard IPv6 automatic stuff would work anymore. None of that standard IPv6 automatic stuff works today, anyway. The state of IPv6 support on end-user CPE generally ranges from non-existent to untested to verified-to-be-broken. This is the only place in your network where /64 can offer any value, and currently, CPE is just not there. Even the latest Cisco/Linksys CPE does not support IPv6. Sure, that'll change; but what won't change is the total lack of any basis for configuring /64 LANs for content farms or any similar non-end-user, non-dynamic segments. I don't want 16 bits of host addressing. I want to choose an appropriate size for each subnet. Why? Because exactly zero of my access routers can handle 2**16 NDP entries, let alone 2**16 entries on multiple interfaces/VLANs. I would like to see much larger ARP/NDP tables in layer-3 switches, and I think vendors will deliver on that, but I doubt we'll soon see even a 10x increase from typical table sizes of today. VPS farms are already pushing the envelope with IPv4, where customers are already used to conserving addresses. Guess what, customers may still have to conserve addresses with IPv6, not because the numbers themselves are precious, but because the number of ARP/NDP entries in the top-of-rack or distribution switch is finite. And again, are you talking about all the way down to the host subnet level? I suppose I could configure server farms in /112 or even /96 (/96 has some appeal for other reasons mostly having to do with multicast) but then I would wonder how many bugs that would flush out of OS v6 stacks. I'm not getting reports of problems with smaller-than-/64 subnets from customers yet. Am I confident that I never will? No, absolutely not! Like almost everyone else, I have some customers who have configured IPv6, but the amount of production traffic on it remains trivial. That is why I allocate a /64 but provision a /120 (or similar practical size.) I can grow the subnet if I have to. I do know that /64 LANs will cause me DoS problems, so I choose to work around that problem now. If /120 LANs cause me OS headaches in the future, I have the option to revise my choice with minimal effort (no services get renumbered, only the subnet must grow.) Why would you suggest /96 as being more practical than /64 from the perspective of NDP DoS? Again, this is an example of the in-between folks in these arguments, who seem not to fully understand the problem. Your routers do not have room for 2**(128-96) NDP entries. Typical access switches today have room for a few thousand to perhaps 16k, and typical bigger switches are specifying figures below 100k. This doesn't approach the 4.3M addresses in a /96. In short, suggesting /96 is flat out stupid -- you get the worst of both worlds, potential for OS compatibility issues, AND guaranteed NDP DoS vulnerability. passing traffic. That doesn't protect against rogue hosts but there might be ways around that, too, or at least limiting the damage a rogue host can cause. How do you suggest we limit the damage a
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
Jeff Wheeler wrote: I'm glad SLAAC is an option, but that's all it is, an option. /64 LANs must also be considered optional, and should be considered useful only when SLAAC is desired. That also could be optional, automatic host configuration does not actually require 64 bits, unless there is a naive assumption that DAD need not occur. Which it must always and for many reasons. rfc3927 does not require 64 bits and works sufficiently well wherever it is employed. SLAAC should be redesigned to be configurable to work with however many bits are available to it and it should be a standard feature to turn that knob all the way from on - off with 128 bit stops in between. And now DHCP-PD can start at any point in the connected hierarchy, working with whatever amount of space is available and not requiring complete upstream support. I dont accept that IPv6 is set in stone. IPv4 wasnt/isnt set in stone and people were/are actually using it because they depend on it. Joe
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: rfc3927 does not require 64 bits and works sufficiently well wherever it is employed. SLAAC should be redesigned to be configurable to work with however many bits are available to it and it should be a standard feature to turn that knob all the way from on - off with 128 bit stops in between. Feel free to explain how SLAAC should work on a /96 with 32 bits of host address (or any amount smaller than the 48 bits most MAC addresses provide). Remember in your answer to deal with collisions. It's one thing to say it should be redesigned. It's another matter entirely to actually come up with a scheme that doesn't suck even harder than screw it, it's a /64. pgpzoN07WarGf.pgp Description: PGP signature
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
valdis.kletni...@vt.edu wrote: On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: rfc3927 does not require 64 bits and works sufficiently well wherever it is employed. SLAAC should be redesigned to be configurable to work with however many bits are available to it and it should be a standard feature to turn that knob all the way from on - off with 128 bit stops in between. Feel free to explain how SLAAC should work on a /96 with 32 bits of host address (or any amount smaller than the 48 bits most MAC addresses provide). Remember in your answer to deal with collisions. Is there something fundamentally wrong with rfc3927? It's one thing to say it should be redesigned. It's another matter entirely to actually come up with a scheme that doesn't suck even harder than screw it, it's a /64. I dont have to, its already been done. In ipv4. Joe
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
At 01:33 AM 3/11/2011, Owen DeLong wrote: On Mar 10, 2011, at 11:22 PM, Dobbins, Roland wrote: On Mar 11, 2011, at 2:02 PM, Owen DeLong wrote: Frankly, unless you have parallel links, there isn't a definite need to even number PtoP links for IPv6. Every thing you need to do with an interface specific address on a PtoP link can be done with link local. Which is why IP unnumbered caught on so well in IPv4-land, heh? There's a HUGE difference between IP unnumbered and link-local. Frankly, absent parallel links, there was a lot to be said for IP unnumbered and I think that if people had better understood the implications of where and when it was a good vs. bad idea and tied it properly to loopbacks instead of $RANDOM_INTERFACE, it might have caught on better. Owen Is anyone else considering only using link local for their PtoP links? I realized while deploying our IPv6 infrastructure that OSPFv3 uses the link-local address in the routing table and than the global address, so if I want to have a routing table which makes sense, I need to statically assign a global address AND the link-local address. Then I realized, why even assign a global in the first place? Traceroutes replies end up using the loopback. BGP will use loopbacks. So is there any obvious harm in this approach that I'm missing? -James
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
In a message written on Fri, Mar 11, 2011 at 01:07:15PM -0500, valdis.kletni...@vt.edu wrote: On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: rfc3927 does not require 64 bits and works sufficiently well wherever it is employed. SLAAC should be redesigned to be configurable to work with however many bits are available to it and it should be a standard feature to turn that knob all the way from on - off with 128 bit stops in between. Feel free to explain how SLAAC should work on a /96 with 32 bits of host address (or any amount smaller than the 48 bits most MAC addresses provide). Remember in your answer to deal with collisions. Well, I at least think an option should be a /80, using the 48 bits of MAC directly. This generates exactly the same collision potential as today we have with a /64 and an EUI-64 constructed from an EUI-48 ethernet address. The router is already sending RA's for SLAAC to work, sending along one of a well-known set of masks would be a relatively minor modification. That said, ND has built into it DAD - Duplicate Address Detection. There is already an expectation that there will be collisions, and the protocols to detect them are already in place. I see little to no reason you couldn't use a different length subnet (like the /96 in your example), randomly select an address and do DAD to see if it is in use. Indeed, this is pretty much how AppleTalk back in the day worked (with a 16 bit number space). The probability of collision is pretty low, and the penalty/recovery (picking a new address and trying again) is rather quick and cheap. If a service provider is going to end up giving me a /64 at home (I know, a whole different argument) I'd vastly prefer to use /80 or /96 subnets with either of these methods, and still be able to subnet the space. I suspect if /64's are given out one or both will come to be standard. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp9s6W9xlusw.pgp Description: PGP signature
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Fri, Mar 11, 2011 at 1:55 PM, James Stahr st...@mailbag.com wrote: Is anyone else considering only using link local for their PtoP links? I realized while deploying our IPv6 infrastructure that OSPFv3 uses the link-local address in the routing table and than the global address, so if I want to have a routing table which makes sense, I need to statically assign a global address AND the link-local address. Then I realized, why even assign a global in the first place? Traceroutes replies end up using the loopback. BGP will use loopbacks. So is there any obvious harm in this approach that I'm missing? For now I have allocated /64s per p-t-p, but I'm doing ipv6 unnumbered loopback0 I quite like how the core route table looks. It also lets me avoid The Point to Point Wars :-) Maybe there will be a good reason to go back and slap globals on there, but I've not been convinced yet. -- Tim:
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Fri, Mar 11, 2011 at 1:07 PM, valdis.kletni...@vt.edu wrote: Feel free to explain how SLAAC should work on a /96 with 32 bits of host address (or any amount smaller than the 48 bits most MAC addresses provide). Remember in your answer to deal with collisions. Why should SLAAC dictate the size of *every subnet* on the IPv6 Internet? This is what people who I label IPv6 Fundamentalists wish to do. They refuse to admit that their ideas were conceived in the mid-90s, that technology has advanced a great deal since that time, and ARP/NDP is a real limit now, while VLSM is no longer a tough challenge (vendors have had a couple decades to make it work really well!) I think there are a lot of people who throw around the SLAAC argument like it's actually good for something. Do these people know what SLAAC does? For core networks, it doesn't do anything. For hosting/datacenter networks and cluster/VPS environments, again, it doesn't do anything. Zero benefit. You probably don't configure these things using DHCP today. Wait, you do? Oh, it's a good thing we've got DHCPv6, which clearly can run alongside your DHCP for IPv4. Is SLAAC for end-user access networks? Not so much. See recent discussions on this list about things which are not included in SLAAC that DHCPv6 does do today. SLAAC can provide an advantage if you can live without those things, but that advantage is limited to one thing: the subnet doesn't need a DHCPv6 server (or proxy/forwarding of packets to same.) IPv4 has gotten along just fine for a long time with both full-featured and light-weight DHCP servers, and statically configured subnets. Is SLAAC solving any problem? Sure, for some situations, like SOHO networks, it's a nice option, but it's just that, an option. It isn't needed. Is SLAAC for fully peer-to-peer networks, with no central gateway? No. To function, SLAAC requires an RA message from something that decides it is a router. It isn't going to facilitate a headless, ad-hoc network to support the next revolution with peer-to-peer cell phones. So what we know is that the sole arguments from IPv6 Fundamentalists in favor of /64 LANs are * VLSM is hard (it isn't; vendors are really good at it now, otherwise IPv4 wouldn't work) * SLAAC needs it to work (not all LANs need SLAAC) * it's the standard (more on this below) I believe everything except the it's the standard argument is fully and completely debunked. If anyone disagrees with me, feel free to correct me, or argue your point until you are blue in the face. I have often been reminded that I should have been more vocal about this matter 10+ years ago, but frankly, I thought vendors, large ISPs, veterans with more public credibility than myself, or the standards folks themselves, would have straightened this out a long time ago. If you can decide for yourself that VLSM is easy and you trust your vendor to do it right (if you don't, summarize to /64 towards your core, or do one great thing IPv6 allows us to do, and summarize to *even shorter* prefixes towards your core, and carry fewer routes in core) then you are half-way there. If you realize SLAAC isn't a tool for your VPS farm or on your backbone link-nets, you're all the way there. At this point, you can deploy your IPv6 without it being broken by design. The only thing broken here is the Fundamentalists, who are stuck in a mid-1990s mindset. These guys need to get out of the way, because they are impeding deployment (for those smart enough to recognize this problem) and they are creating an almost certain need for a future re-design (for those who aren't smart.) This future doesn't depend on anything except v6 actually getting deployed enough to where DDoS happens over it at any appreciable scale. In the current state of the Internet, it is certain that this problem will happen. No visible progress has been made on solving it, except by guys like myself who are happy to cry the sky is falling, configure our networks in a non-standard way, and tell the standards folks they are wrong. The Cisco knob is progress only in that Cisco recognizes customers are concerned about this problem and allow them to steer their failure mode. If the DDoS happens before vendors provide a real solution, or before standards are revised or thrown out, you can thank those of us on the sky is falling side of this argument for testing the work-around (by never having exposed ourselves to the problem in the first place.) It's one thing to say it should be redesigned. It's another matter entirely to actually come up with a scheme that doesn't suck even harder than screw it, it's a /64. This is true. I think the price of energy is continuing to rise and our future is very uncertain as a result. I don't know how to fix it. Does that mean I should keep my opinion to myself? Of course not. Recognizing a problem is the first step on the path to a solution. I imagine the same arguments taking place before VLSM
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Fri, Mar 11, 2011 at 12:55:33PM -0600, James Stahr wrote: link-local address. Then I realized, why even assign a global in the first place? Traceroutes replies end up using the loopback. BGP will use loopbacks. So is there any obvious harm in this approach that I'm missing? Traceroute replies most assuredly do NOT use loopbacks on most networks, and it would make troubleshooting massively more difficult if this was the only option. Imagine any kind of complex network where there is more than one link between a pair of routers (and don't just picture your own internal network, but imagine customers connecting to their ISPs as well) , and now tell me how you plan on identifying a particular link with a traceroute. The two words that best sum this up would be epic disaster. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
Leo Bicknell wrote: Three people have now mailed me privately saying that DAD does not provide a way to select a second address if your first choice is not in use. So fix that as well while we are at it, how bout it? Its code, not stone.
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On 03/11/2011 04:05 PM, Joe Maimon wrote: Leo Bicknell wrote: Three people have now mailed me privately saying that DAD does not provide a way to select a second address if your first choice is not in use. So fix that as well while we are at it, how bout it? Its code, not stone. So it is simple, use privacy (3041) addresses scaled appropriately for the appropriate netmask... remember the last D in DAD is detection; what you do about it is in another protocol. -- Pete
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 11, 2011, at 5:53 AM, Jeff Wheeler wrote: On Thu, Mar 10, 2011 at 10:51 PM, George Bonser gbon...@seven.com wrote: And I say making them /127s may not really make any difference. Say you make all of those /127s, at some point you *are* going to have a network someplace that is a /64 that has hosts on it and that one is just as subject to such an attack. If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. The end result is the same. You have managed to re-arrange the deck chairs. Have another squeeze at that water balloon. Again, this is the argument put forth by the RFC wavers, that you can't solve the problem because you must want to configure /64s for ... what, exactly? Oh, right, SLAAC. More on that below. If I'm a content provider, I don't have to configure a /64 for my content farm. I can configure a /120 or whatever subnet size is practical for my environment. I can also use link-local addressing on my content farm LANs and route subnets to my content boxes, if that is somehow more practical than using a smaller subnet. Yes, you can bring as much of the pain from IPv4 forward into IPv6 as you like. You can also commit many other acts of masochism. Personally, I prefer to approach IPv6 as a way to reduce some of the more painful aspects of IPv4, such as undersized subnets, having to renumber or add prefixes for growth, limited aggregation, NAT, and more. If you are a service provider where practically all of your links are point to points, sure. No, you can avoid configuring /64s if you don't need SLAAC. Who needs SLAAC? I don't. It has absolutely no place in any of my environments. It seems to me that DHCPv6 will do everything which SLAAC does, and everything SLAAC forgot about. The complexity argument is pretty much indefensible when the trade-off is configuring DHCPv6 vs turning a bunch of router knobs and hoping no one ever targets your LANs with an NDP DoS. SLAAC is a very useful and convenient way to deal with client networks. I would agree it's of limited use in a content provider scenario, but, there is utility to /64s beyond just SLAAC. Yes, they are a hard requirement for SLAAC. We didn't need much more host addressing, we needed more subnet addressing. I would have settled for 16 bits of host addressing and 112 bits of subnet addressing and I suppose nothing prevents me from doing that except none of the standard IPv6 automatic stuff would work anymore. None of that standard IPv6 automatic stuff works today, anyway. The state of IPv6 support on end-user CPE generally ranges from non-existent to untested to verified-to-be-broken. This is the only place in your network where /64 can offer any value, and currently, CPE is just not there. Even the latest Cisco/Linksys CPE does not support IPv6. Sure, that'll change; but what won't change is the total lack of any basis for configuring /64 LANs for content farms or any similar non-end-user, non-dynamic segments. As someone using SLAAC in a number of environments, I'm confused by this statement. It seems to be working quite well in many places and end-user residential networks are certainly not the only places where it is useful. Yes, residential end-user CPE is rather limited and somewhat less than ideal today. I would argue that there are probably at least as many end-user hosts on non-residential networks that could take advantage of SLAAC if the administrators wanted to. I don't want 16 bits of host addressing. I want to choose an appropriate size for each subnet. Why? Because exactly zero of my access routers can handle 2**16 NDP entries, let alone 2**16 entries on multiple interfaces/VLANs. I would like to see much larger ARP/NDP tables in layer-3 switches, and I think vendors will deliver on that, but I doubt we'll soon see even a 10x increase from typical table sizes of today. VPS farms are already pushing the envelope with IPv4, where customers are already used to conserving addresses. Guess what, customers may still have to conserve addresses with IPv6, not because the numbers themselves are precious, but because the number of ARP/NDP entries in the top-of-rack or distribution switch is finite. What do your access routers have to do with your content farm? Sounds like you've got some pretty darn small access routers as well if they can't handle 64k NDP entries. Yes, larger tables in switches would be a good thing, but, I hardly think that's a reason to use smaller netmasks. Most of the top-of-rack switches I'm aware of have no problem doing at least 64k NDP/ARP entries. Many won't do more than that, but, most will go at least that far. And again, are you talking about all the way down to the host subnet level? I suppose I could configure server farms in /112 or even /96 (/96 has some appeal for other reasons
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: In a message written on Fri, Mar 11, 2011 at 01:07:15PM -0500, valdis.kletni...@vt.edu wrote: On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: rfc3927 does not require 64 bits and works sufficiently well wherever it is employed. SLAAC should be redesigned to be configurable to work with however many bits are available to it and it should be a standard feature to turn that knob all the way from on - off with 128 bit stops in between. Feel free to explain how SLAAC should work on a /96 with 32 bits of host address (or any amount smaller than the 48 bits most MAC addresses provide). Remember in your answer to deal with collisions. Well, I at least think an option should be a /80, using the 48 bits of MAC directly. This generates exactly the same collision potential as today we have with a /64 and an EUI-64 constructed from an EUI-48 ethernet address. The router is already sending RA's for SLAAC to work, sending along one of a well-known set of masks would be a relatively minor modification. How would you use that on a Firewire netowrk or FDDI or any of the other media that uses 64-bit MAC addresses? That said, ND has built into it DAD - Duplicate Address Detection. There is already an expectation that there will be collisions, and the protocols to detect them are already in place. I see little to no reason you couldn't use a different length subnet (like the /96 in your example), randomly select an address and do DAD to see if it is in use. Indeed, this is pretty much how AppleTalk back in the day worked (with a 16 bit number space). Detect, yes. Mitigate, no. DAD on the link-local results in Interface shutdown. In an environment where there's a very low probability of collision, that's an acceptable risk that is easily mitigated in most cases. In an environment where you create a much higher risk of collision, such as 1/2^32 or less, vs. 1/2^48 or more, I think that's a rather ill advised approach. The probability of collision is pretty low, and the penalty/recovery (picking a new address and trying again) is rather quick and cheap. IPv6 does not try to pick a new address and try again in SLAAC, at least not what it's supposed to do. If a service provider is going to end up giving me a /64 at home (I know, a whole different argument) I'd vastly prefer to use /80 or /96 subnets with either of these methods, and still be able to subnet the space. I suspect if /64's are given out one or both will come to be standard. If a service provider attempts to give ma a /64 at home, I'd opt for a new provider instead. Owen
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong wrote: On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: Well, I at least think an option should be a /80, using the 48 bits of MAC directly. This generates exactly the same collision potential as today we have with a /64 and an EUI-64 constructed from an EUI-48 ethernet address. The router is already sending RA's for SLAAC to work, sending along one of a well-known set of masks would be a relatively minor modification. How would you use that on a Firewire netowrk or FDDI or any of the other media that uses 64-bit MAC addresses? It wouldn't. I'm not proposing a solution for everything, just a useful case for some things. I don't want to change say, RIR policy that you can allocate a /64, just allow operators to use /80's, or /96's in a more useful way if they find that useful. Basically I think the IETF and IPv6 propoents went a bit too far down the one size fits all route. It has nothing to do with how many numbers may or may not be used, but everything to do with the fact that you often have to fit inside what's been given to you. If you're stuck with a monopoly provider who gives you a /64 to your cable modem there should be easy options to split it up and get some subnets. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpWiT2xsQGU0.pgp Description: PGP signature
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Fri, Mar 11, 2011 at 6:33 PM, Owen DeLong o...@delong.com wrote: Yes, you can bring as much of the pain from IPv4 forward into IPv6 as you like. You can also commit many other acts of masochism. This is the problem with Fundamentalists, such as yourself, Owen. You think that fixing things which work fine (like reasonable-sized VLSM LANs for content farms) is worth introducing a DDoS vulnerability for which there is no current defense, and for which the only feasible defense is either reversing your choice and renumbering the subnet from /64 to /smaller, or waiting until your vendors supply you with patched images for your routers and/or switches. You need to move beyond this myopic view that /64 provides a benefit that is worth this kind of operational sacrifice. When vendors cough up some more knobs, I'll be right there with you, configuring /64 subnets. I've already allocated them! It's pretty easy for me to renumber my /120 subnets to /64, after all -- I don't have to update any zone files for public-facing services, or modify significant configuration for software -- I just have to reconfigure my router and host interfaces from /120 to /64. You, on the other hand, may have addresses in use all over that /64, and condensing them into a smaller subnet is guaranteed to be at least as hard as my work for growing my subnet, and may be much more difficult -- every bit as difficult as renumbering from one IPv4 block to another. Given the current state of IPv6, your Fundamentalist way introduces new problems *and* brings the old ones forward. This makes no sense, but Fundamentalists rarely do. Personally, I prefer to approach IPv6 as a way to reduce some of the more painful aspects of IPv4, such as undersized subnets, having to renumber or add prefixes for growth, limited aggregation, NAT, and more. I look forward to that when it works. As I've noticed, I have prepared to take advantage of those things as soon as the NDP issue is resolved. None of that standard IPv6 automatic stuff works today, anyway. The state of IPv6 support on end-user CPE generally ranges from As someone using SLAAC in a number of environments, I'm confused by this statement. It seems to be working quite well in many places and end-user residential networks are certainly not the only places where it is useful. Your definition of working quite well in many places is different than mine. I'll come around to your point of view when it is possible to get working IPv6 connectivity from most major end-user ISPs, and all (or close enough) the CPE being sold at Fry's and Best Buy works right. We are pretty far from that right now. This is another thing the IPv6 Fundamentalists seem to ignore. CPE support is almost non-existent, ISP support is not there (some tier-1 transit networks still have no IPv6 product!), and the major IXPs still have three orders of magnitude more IPv4 traffic than IPv6. Cogent, Level3, and Hurricane Electric still can't decide that it's in their mutual interest to exchange IPv6 traffic with each-other, and their customers don't care enough to go to another service provider, because IPv6 is largely unimportant to them. None of this stuff works today. You aren't seeing DDoS scenarios on the v6 network today because the largest IPv4 DDoS attacks are larger than the total volume of inter-domain IPv6 traffic. Most of the top-of-rack switches I'm aware of have no problem doing at least 64k NDP/ARP entries. Many won't do more than that, but, most will go at least that far. Owen, this statement is either: 1) a gross misunderstanding on your part, because you can't or don't read spec sheets, let alone test gear 2) you've never seen or used a top-of-rack switch or considered buying one long enough to examine the specs 3) your racks are about 3 feet taller than everyone else's and you blow 100k on switching for every few dozen servers 4) an outright lie, although not an atypical one for the IPv6 Fundamentalist crowd I'd like you to clarify which of these is the case. Please list some switches which fit your definition of top-of-rack switch that support 64k NDP entries. Then list how many top-of-rack switches you are currently aware of. Don't bother listing the ones you know don't support 64k, because I'll gladly provide a list of plenty more of those, than the number of switches which you find to support 64k in a ToR form-factor. For those following along at home, how many ToR switches do indeed support at least 64k NDP entries? Unlike Owen, I know the answer to this question: Zero. There are no ToR switches that support = 64k NDP table entries. Of course, I don't really mean to call Owen a liar, or foolish, or anything else. I do mean to point out that his facts are wrong and his argument not based in the world of reality. He is a Fundamentalist, and is part of the problem, not the solution. I find it interesting that you _KNOW_ that /64 LANs will cause you DoS problems and yet
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 12, 2011, at 11:14 AM, Jeff Wheeler wrote: Of course, I don't really mean to call Owen a liar, or foolish, or anything else. Please don't; even though I disagree with him and agree with you very strongly on this set of issues, Owen is a smart and straightforward guy, and is simply speaking from his (selective on this particular set of topics, IMHO) own individual viewpoint. ; and if the most popular fix becomes dependent on NDP inspection If that comes to pass, then the fix will be useless, unfortunately, just as dynamic ARP inspection (DAI) is useless today; it self-DoSes the box. Any form of 'inspection' will not scale for this problem, as it will be CPU-bound even on ASIC-based platforms. All this ICMPv6 weirdness and outright brokenness is the Achilles' heel of IPv6, and I see no ready solution in sight for the set of problems it engenders. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
RE: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
As Richard points out, there is *no* reason to configure /64s on point-to-point links, and there are obvious disadvantages. The RFC wavers are downright stupid to suggest otherwise. As for IXP LANs, I predict that one of two things will happen: either one or more major IXPs will be subject to NDP DoS and will decide to shrink their subnet size, allowing others to follow suit; or vendors will make NDP inspection work and be configurable enough to prevent most problems. Again, Cisco has already added a knob to some platforms which allows you to steer the failure mode. Interfaces will fail regardless of what you do; the Cisco knob just lets you decide to break NDP on only the interface(s) subject to attack instead of on the entire box. In any case, I don't judge static NDP entries on IXP LANs to be a practical long-term solution. There are obvious disadvantages to that. And I say making them /127s may not really make any difference. Say you make all of those /127s, at some point you *are* going to have a network someplace that is a /64 that has hosts on it and that one is just as subject to such an attack. If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. The end result is the same. You have managed to re-arrange the deck chairs. Have another squeeze at that water balloon. If you are a service provider where practically all of your links are point to points, sure. If your network is entirely made up of backbone routers with fairly static neighbors, your strategy can certainly work with a bit of extra effort and a vendor box that doesn't do entirely crazy things. Where that is done is primarily on a backbone section of the network and where I connect to public peering points. I add static entries for the specific peers I communicate with. Yes, it does take a little maintenance when a peer changes out some gear or moves to a different port on their gear but that doesn't happen all that often and is a compromise I am willing to make in exchange for some added protection. It also protects against someone who I am not peering with on that same switch fat-fingering an IP address during some maintenance and accidently configuring their gear with the same IP as someone I *am* peering with. I won't even see it if I have a static neighbor (the same thing is also done with v4 on public peering switches with static ARP entries, too). If you have customers (those pesky customers!) they may not be so comfortable having to open a ticket and feel like they are troubleshooting a problem you've caused them because you have configured a static NDP entry facing them. Right, if I had dozens of point-to-points with gear that is constantly changing at the other end, yeah. I agree. I might then consider that approach. But in this case I can only speak about my own stuff and what is the best solution for one specific application might not be the best solution for someone else. I am not trying to say that this solution is best for everyone, I am simply pointing out a solution that others might find useful depending on their application. I have been talking to smart people about this problem for nearly ten years, and I have never heard a practical solution that doesn't involve some kind of persistent sticky NDP which refuses to make discovery requests to the LAN for addresses which have never been seen from the LAN. I've also never seen a practical idea for preventing malicious hosts on the LAN from filling the table that doesn't involve NDP inspection at the access port, some kind of database (e.g. RADIUS/etc) or additional configuration in the router, or proposals that would simply change the failure mode (e.g. rate-limit knobs.) Yeah, it's a tough nut to crack. I do agree that 64-bit host addressing is just too big. The reason is that it even allows you to configure more IPs on a single subnet legitimately than the network gear can handle. The notion of we are going to give you a subnet with 8 bazillion possible addresses, but don't try to use more than half a million of them or you will melt your network gear seems quite idiotic, actually. So you have a huge address space that you actually can't use much of (relative to the size of the space) and it creates a stability risk. We didn't need much more host addressing, we needed more subnet addressing. I would have settled for 16 bits of host addressing and 112 bits of subnet addressing and I suppose nothing prevents me from doing that except none of the standard IPv6 automatic stuff would work anymore. You'll notice that there have been several discussions about this on NANOG and other mailing lists, most of which include some RFC wavers, some people saying the sky is falling, and some guys in-between who think their vendor's box will fail gracefully or that NDP learning not functioning
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 11, 2011, at 10:51 AM, George Bonser wrote: If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. Of course, it does - you may have many content farms/instances, and taking down point-to-point links can DoS your entire set of farms/instances, whereas an attack against a given endpoint access network doesn't necessarily mean that your other properties/networks/services are being attacked, as well. Limiting this vector to endpoint access networks also makes mitigation mechanisms far more practicable. There is no good reason to use /64s on point-to-point links. It is wasteful (please, no more about the supposed infinitude of IPv6 addresses; some of us reject this as being shortsighted and insufficiently visionary concerning eventual one-time-uses of IPv6 addresses at nanoscale) and turns your routers into sinkholes. It is a Very Bad Idea. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 10, 2011, at 8:00 PM, Dobbins, Roland wrote: On Mar 11, 2011, at 10:51 AM, George Bonser wrote: If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. Of course, it does - you may have many content farms/instances, and taking down point-to-point links can DoS your entire set of farms/instances, whereas an attack against a given endpoint access network doesn't necessarily mean that your other properties/networks/services are being attacked, as well. How is an attack against all your content farms in any way MORE difficult than an attack against enough point to point links to take everything out? If you've designed things properly, it takes more PtoP links to DOS the complete set than it does End point networks. Limiting this vector to endpoint access networks also makes mitigation mechanisms far more practicable. It's actually pretty easy to eliminate it 100% from the PtoP links even if they are /64s by simply not allowing traffic to the PtoP addresses other from selected sources (NOC/Admin Network, required peers, etc.). If you want to be truly anal about it, you can also block packets to non-existent addresses on the PtoP links. There is no good reason to use /64s on point-to-point links. It is wasteful (please, no more about the supposed infinitude of IPv6 addresses; some of us reject this as being shortsighted and insufficiently visionary concerning eventual one-time-uses of IPv6 addresses at nanoscale) and turns your routers into sinkholes. It is a Very Bad Idea. This isn't a one-time-use of IPv6 addresses and the one-time-uses of IPv6 addresses are what should be considered unscalable and absurdly wasteful. There's a lot to be said for the principle of least surprise and uniform /64s actually help with that quite a bit. Frankly, unless you have parallel links, there isn't a definite need to even number PtoP links for IPv6. Every thing you need to do with an interface specific address on a PtoP link can be done with link local. Owen
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 11, 2011, at 2:02 PM, Owen DeLong wrote: If you want to be truly anal about it, you can also block packets to non-existent addresses on the PtoP links. Sure, I advocate iACLs to block traffic to p2p links and loopbacks. Still, it's best not to turn routers into sinkholes in the first place. This isn't a one-time-use of IPv6 addresses and the one-time-uses of IPv6 addresses are what should be considered unscalable and absurdly wasteful. I don't know that I agree with this - I can see lots of value in one-time-use addresses/blocks, and have a metaphysical degree of certitude that they'll be used that way in some cases, irrespective of what I think. There's a lot to be said for the principle of least surprise and uniform /64s actually help with that quite a bit. Enforcing uniformity of wasteful and potentially harmful addressing practices in the name of consistency isn't necessarily a win, IMHO. ; Frankly, unless you have parallel links, there isn't a definite need to even number PtoP links for IPv6. Every thing you need to do with an interface specific address on a PtoP link can be done with link local. Which is why IP unnumbered caught on so well in IPv4-land, heh? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Mar 10, 2011, at 11:22 PM, Dobbins, Roland wrote: On Mar 11, 2011, at 2:02 PM, Owen DeLong wrote: If you want to be truly anal about it, you can also block packets to non-existent addresses on the PtoP links. Sure, I advocate iACLs to block traffic to p2p links and loopbacks. Still, it's best not to turn routers into sinkholes in the first place. This isn't a one-time-use of IPv6 addresses and the one-time-uses of IPv6 addresses are what should be considered unscalable and absurdly wasteful. I don't know that I agree with this - I can see lots of value in one-time-use addresses/blocks, and have a metaphysical degree of certitude that they'll be used that way in some cases, irrespective of what I think. If so, opefully from a tiny and limited range. fc::/7 sounds good to me. It has few other useful purposes in life. There's a lot to be said for the principle of least surprise and uniform /64s actually help with that quite a bit. Enforcing uniformity of wasteful and potentially harmful addressing practices in the name of consistency isn't necessarily a win, IMHO. We can agree to disagree. I don't think it's so wasteful and it's what the bits were put there to do. Perverting them to other uses and then complaining that the legitimate uses are getting in the way, OTOH, well... ; Frankly, unless you have parallel links, there isn't a definite need to even number PtoP links for IPv6. Every thing you need to do with an interface specific address on a PtoP link can be done with link local. Which is why IP unnumbered caught on so well in IPv4-land, heh? There's a HUGE difference between IP unnumbered and link-local. Frankly, absent parallel links, there was a lot to be said for IP unnumbered and I think that if people had better understood the implications of where and when it was a good vs. bad idea and tied it properly to loopbacks instead of $RANDOM_INTERFACE, it might have caught on better. Owen
