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

[Ray Hunter <[e-mail]>]

Inline.

Brian E Carpenter wrote:
> 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.
>
>    
Sure.
>> 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.
>
>    
The point is that the end node doesn't know which IPv6 source address to 
use for which application and when, because there's no signaling today.

The idea in the draft to distribute an RFC3484 type policy from routers 
to end nodes should theoretically work in this case.

However, the PA prefix could still be up (in RA) and still be valid in 
IA_PD, and the local ISP interface UP, but packet forwarding via the ISP 
link is down, meaning a very slow or incomplete takeover as the end node 
has no indication of upstream failure.

One option would be to ensure that on ISP link failure, the site egress 
router could ensure that all leases and addresses from the PA prefix are 
flushed from the whole site. But there's no flushing mechanism today, 
only timer expiry. Or that a policy update can be pushed to all end 
nodes: not easy.

It's also tricky to deploy in practice right now as end nodes are mobile 
between sites (your Thinkpad moves) and not all end nodes are managed by 
IT (it's your Thinkpad, not mine). So I suspect it'll be tough to write 
a universal RFC3484 policy to cover all end nodes and all cases. Or it 
might become hundreds of lines long. And it probably won't work for 
guests, contractors, or BYOD because of trust issues.

Today you can force these failovers pretty quickly using object tracking 
to simply avoid using the NATted interface at the site router, without 
involving the end nodes at all.

That's why I'm attracted to the "learn by trying" approach: to avoid 
direct policy interactions of routers and end nodes several hops away. 
So intermediate routers could inform end nodes about the characteristics 
of the available end-to-end paths. But end nodes provide the ultimate 
policy of which path to select per application. They also test the end 
to end path before using it, to avoid unhappy eyeballs.
>> 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.
>
>    
This is admittedly a corner case and little to do with the IETF 
standards. This is multi-interface firewall where the policies are 
linked to physical interface. Theoretically speaking "gluing" on a PBR 
function would work. But practically speaking, the PBR function has to 
be integrated within the same box as the firewall function, not bolted 
on the outside as an additional router. It's going to be large amounts 
of money to replace / change.

>     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
>>>
>>>        
>>