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

Ray Hunter <v6ops@globis.net> Thu, 17 November 2011 09:46 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FE821F9B25 for <v6ops@ietfa.amsl.com>; Thu, 17 Nov 2011 01:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2pm35LLCMzw for <v6ops@ietfa.amsl.com>; Thu, 17 Nov 2011 01:46:03 -0800 (PST)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 70AF021F9B20 for <v6ops@ietf.org>; Thu, 17 Nov 2011 01:46:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 560918700E7; Thu, 17 Nov 2011 10:45:59 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDRkI2LVKdKJ; Thu, 17 Nov 2011 10:45:53 +0100 (CET)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 72E648700E6; Thu, 17 Nov 2011 10:45:53 +0100 (CET)
Message-ID: <4EC4D7D1.8050601@globis.net>
Date: Thu, 17 Nov 2011 10:45:53 +0100
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> <4EC469E7.9010602@gmail.com> <20111117055040.E34FC179DAF9@drugs.dv.isc.org>
In-Reply-To: <20111117055040.E34FC179DAF9@drugs.dv.isc.org>
Content-Type: multipart/alternative; boundary="------------000301000901050506030004"
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2011 09:46:03 -0000

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.

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.

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.

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.

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
>