mailing list archives
Re: BGPttH. Neustar can do it, why can't we?
From: Mike Jones <mike () mikejones in>
Date: Mon, 6 Aug 2012 17:51:02 +0100
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
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
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.
Re: BGPttH. Neustar can do it, why can't we? Leo Bicknell (Aug 06)