On 6 August 2012 16:11, Leo Bicknell <bickn...@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
