Re: BGPttH. Neustar can do it, why can't we?

[Mike Jones <mike () mikejones in>]

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