> Using multiple ISPs is still something that is a bit tricky. A lot of > people have gotten used to the Dual-WAN Firewall appliance boxes that > accept connections from two ISPs and handle the failover, depending on > NAT to maintain the functionality of the Internal network. > > Larger organizations can arrange to have IPv6 transit and announce a > single prefix over BGP. Most providers won't want to see this setup > for an SMB so they're out of luck. > Actually, ANY size organization can do this. Most providers won't want to set this up over native DSL, CMTS, or PON cheap circuits. There are options there. Do BGP over tunnels using your native circuits as L2 transport, for one. (This is working quite well for me and hasn't been all that hard to implement).
> One thing that has changed, though, is Metro Ethernet offerings have > gotten a lot better. I would say the most painless way to go would be > to use one ISP for L3, and two ME providers to give diverse L2 paths > to that L3 ISP. It means dealing with more companies, and moving > failover to L2, but it's pretty rare that the cause of a connection > problem is at the ISP these days (it's more often a bad connection > between you and the ISP), so just having redundancy at L2 might be > enough. > I'm not convinced that's the best approach. If I were doing that, I'd use the two metro-E connections to reach different providers and run BGP. It's just not that hard. Especially if your BGP is accept default, advertise _myroute_. > Sadly, that model doesn't really exist in the US right now, and it > might take quite a bit of work convincing providers to coordinate to > make it all work. > Another argument in favor of the L2/L3 topologies matching. (There are also reliability and simplicity arguments to favor doing so). > The other option, which was the intent of IPv6 when being designed > (but that was 10 years ago or so) was that every PC would have a > separate address from each ISP. In this situation you could depend on > ULA (local addressing) for access to all internal services so that if > one of the global prefixes goes away it doesn't impact internal > operation, but it does require a device to kind of coordinate that- > such a device doesn't exist yet, and there are some issues with > getting PCs to handle address selection correctly. I suspect if this > does happen (and it could, it's not a horrible model) it will take a > few more years before it's "easy". It's too bad they axed the site > local scope for this kind of environment. > Please stop promulgating the fiction that IPv6 addressing from your provider depends on reachability to your provider to continue functioning on your internal network. It simply isn't true unless you are getting those addresses via DHCPv6 or SLAAC. If you have a topology, SLAAC is a non-starter and it would have to be DHCPv6-PD or static. If you have static, there's no need whatsoever for ULA. No sane business would go for having their IPv6 addresses delivered to them via DHCPv6-PD. > For now, I would recommend just going with a single IPv6 provider > since I have yet to encounter IPv6-only content that is mission > critical. That will at least give you access to the IPv6 internet > now, but give the IPv6 market time to come around to meet the needs of > SMB and wanting redundancy in IPv6 access. > This is a very solvable problem to day, but, it does require a tiny amount of training/learning to implement the solution. > I'm not aware of any appliance that does a good job at IPv6, yet... > Depends on your definition of Appliance. If you would consider an SRX-100 an appliance, it works reasonably well. It cost less than several of the other appliances in my house. > If it were me I would build up a Linux box as a IPv6 firewall, router, > etc. It's really too bad that there isn't such an appliance yet. You > could just use a Cisco ISR (like an 1841) as your IPv6 on a stick > router, but the problem is that you really want to keep in mind that > once you give out global addresses to hosts they're not behind your > NAT firewall for IPv6. So you'll want to implement some sort of > stateful firewall for IPv6, or enable host-based IPv6 firewalls. > Linux box is a fine alternative, ip6tables works well, but, Linux box vs. SRX-100, the cost difference isn't that large. > We've decided to disable SLAAC (State-Less Address Auto-Configuration) > on almost all our IPv6 networks and use DHCPv6 exclusively. This Ouch... Sounds painful. > allows us to only respond with DHCPv6 to the hosts we want to get an > IPv6 address instead of enabling it network-wide and crossing your > fingers. The disadvantage here is that DHCPv6 client support is still > limited (OS X has none for example). The argument is that IPv6 isn't > mission critical yet, so we're waiting to see if vendors will come > around and include DHCPv6 client support in the future. > It also means that you are even more subject to the issues of rogue RA and RA Spoofing. > Another thing you want to do is block rogue RA. RA-Guard is the > feature name, but nobody has a working implementation yet. If you > have switches that can do port-based access-lists with IPv6 you can > create ingress filters to block out incoming RA on a per-port basis > which is what we have done. > You must have a really hostile user base. I agree RA-Guard is a good idea and it does work on some switches. Where it is most glaringly lacking is in Wireless configurations, meaning that having a real RA is actually a limited measure of protection vs. having no RA. > Owen
