On 6 August 2012 16:11, Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Mon, Aug 06, 2012 at 10:05:30AM -0500, Chris Boyd wrote:
Speaking as someone who does a lot of work supporting small business IT, I suspect the number is much lower. As a group, these customers tend to be extremely cost averse. Paying for a secondary access circuit may become important as cloud applications become more critical for the market segment, but existing smart NAT boxes that detect primary upstream failure and switch over to a secondary ISP will work for many cases. Yes, it's ugly, but it gets them reconnected to the off-site email server and the payment card gateway.
I don't even think the dual-uplink NAT box is that ugly of a solution. Sure it's outbound only, but for a lot of applications that's fine.
However, it causes me to ask a differnet question, how will this work in IPv6? Does anyone make a dual-uplink IPv6 aware device? Ideally it would use DHCP-PD to get prefixes from two upstream providers and would make both available on the local LAN. Conceptually it would then be easy to policy route traffic to the correct provider. But of course the problem comes down to the host, it now needs to know how to switch between source addresses in some meaningful way, and the router needs to be able to signal it.
Multiple prefixes is very simple to do without needing a dual uplink router, just get 2 "normal" routers and have them both advertise their own prefixes, the problem is the policy routing that you mentioned a dual WAN router would do. A client that sees prefix A from router A and prefix B from router B should IMO prefer router A for traffic from prefix A and router B for traffic from prefix B. Current implementations seem to abstract away the addressing and the routing in to completely separate things resulting in it picking a default router then using that for all traffic, this isn't too much of a problem if neither of your upstreams do any source address filtering but I would much rather OS vendors change their implementations than tell ISPs to stop filtering their customers.
As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might be a relatively clean solution. Are there other deployable, or nearly deployable solutions?
If you have a router that sends out RAs with lifetime 0 when the prefix goes away then this should be deployable for "poor mans failover" (the same category I put IPv4 NAT in), however there are some bugs with client implementations and some clients might refuse to use that prefix/router again until they have rebooted which could be an issue for infrequently rebooted clients if the other connection later goes down. A lifetime of 1 instead of 0 should in theory work around this behaviour but I haven't seen any implementations that do this and haven't tested myself. It's a shame that this IPv6 stuff doesn't work properly out of the box, I fear that there will be a lot of hackery due to early limitations that will stick around - for example if NAT becomes readily available before clients can properly handle multiple prefixes from multiple routers (and DHCP-PD chaining, and the various other "we're working on it" things), then even once clients start being able to do it properly I suspect people will still stick to their beloved NAT because that's what they are used to. - Mike