Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt

[Brian E Carpenter <[e-mail]>]

Ray,

On 2011-11-17 22:45, Ray Hunter wrote:
> Agreed. Most multinationals I know are already LIRs. They can run BGP to
> the major sites with multiple ISPs and their own PI /32. That's the easy
> bit.
> 
> But it isn't just about a few large sites and 2 ISP's. There's also the
> rest of the private corporate network covering 50+ countries + multiple
> (smaller) ISPs to consider.

Exactly. The small number of biiig multinationals is not an issue.

> 
> IMHO I have seen three use cases so far in production today in IPv4 that
> are not really covered in IPv6. To be frank, these current solutions
> seem mainly to be driven by commercial considerations rather than
> technical ones. So if a commercial solution could be found, there
> wouldn't be much resistance to change. Most problems are due to the
> return route, not the outbound one.
> 
> 1. Home workers, remote branch offices, and SME's that need higher
> availability than a single consumer ISP link, but don't have the
> capability/desire/cash/ISP to run a multihomed BGP AS. Today they can
> use a simple outbound-only load-balancing box, or a specialist VPN box
> that provides 2 GRE/IPSec tunnels via 2 ISPs. The GRE/IPSec solution
> will obviously work in the future, but the load balancer won't.

Multipath TCP would handle the load balancing issue (but not of course
for non-TCP traffic). Shim6 would handle failover for all types of flow.
But both of these need both ends to play, which makes deployment sticky.

> 
> 2. Local Internet break out. Remote corporate site is still connected to
> the corporate network for business/production critical apps, but
> Internet traffic is gatewayed directly into the Public Internet at the
> local site for Internet centric apps like foobarnow.com. Today the local
> site Internet firewall/router can use NAT44 outbound: guaranteeing a
> return route direct to the local site. Most, but not all, Internet
> centric apps are web based, but that would mean installing a proxy on
> every site for IPv6. I see no solution so far for apps that are
> "NAT44-able" but "non-proxy-able" with IPv6. Negotiating ISP routing of
> a single /48 in country X from the PI /32 is unlikely to work in all
> cases. I guess these sites could just use PA space addresses, but then
> you have limited service availability, and potential renumbering issues.

Why? If the local PA link goes down, you'd revert to a slower path
using an address under the PI prefix.

In my experience when I was such a corporate user, I got renumbered whenever
I reconnected my ThinkPad. It was never an issue.

> 
> 3. Internet offload. Remote corporate site has a main link and an
> Internet connection. Local site router is connected to both and uses
> Policy Based Routing (PBR) to route down the appropriate link. A GRE
> tunnel carries the bulk traffic over the Internet to the regional
> corporate data centre, where it emerges from the tunnel and passes
> through the usual security controls onto the Public Internet. Return
> route to the GRE tunnel is guaranteed via NAT. Otherwise you'd need to
> run PBR on the DC firewall as the Internet tunnel and private corporate
> network are connected to different security zones on the firewall. PBR
> on firewalls doesn't exist so far AFAIK.

Firewalls aren't routers, but they can have routers glued onto them.

   Brian

> 
> In most cases there's multiple hops (and possibly security devices)
> between the end nodes and the point where the alternative paths split.
> 
> 
> Mark Andrews wrote:
>> <snip>
>>
>> I would expect multi-nationals to be able to work around these sort
>> of restrictions already.  My primary focus is to make it work for
>> the home / small office.  Bigger customers can usually make this
>> work today without automation.  Homes and small offices can't because
>> them man power cost is too high to deal with the volume.
>>
>> That said I would welcome a solution that scales up to handle any
>> business that isn't a ISP.
>>
>> Mark
>>    
> 
>