Re: multihoming, was IPv10

Mark Andrews <marka@isc.org> Fri, 30 December 2016 01:57 UTC

Return-Path: <marka@isc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE34A128B37 for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 17:57:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPu-oHbfwdl9 for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 17:57:25 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FC0127077 for <ietf@ietf.org>; Thu, 29 Dec 2016 17:57:24 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 846801FCAC5; Fri, 30 Dec 2016 01:57:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3761B16004F; Fri, 30 Dec 2016 01:57:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1D06D16006B; Fri, 30 Dec 2016 01:57:15 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id If57XqWQW-KS; Fri, 30 Dec 2016 01:57:15 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B1B2D16004F; Fri, 30 Dec 2016 01:57:14 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EF91C5E15F13; Fri, 30 Dec 2016 12:57:09 +1100 (EST)
To: John Levine <johnl@taugh.com>
From: Mark Andrews <marka@isc.org>
References: <20161229162721.34651.qmail@ary.lan>
Subject: Re: multihoming, was IPv10
In-reply-to: Your message of "29 Dec 2016 16:27:21 -0000." <20161229162721.34651.qmail@ary.lan>
Date: Fri, 30 Dec 2016 12:57:09 +1100
Message-Id: <20161230015709.EF91C5E15F13@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZTLQZsO_h_INQOgMtktIS8LD4A0>
Cc: john-ietf@jck.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2016 01:57:25 -0000

In message <20161229162721.34651.qmail@ary.lan>, "John Levine" writes:
> > ...  However, my impression is that we
> >are seeing increasing ISP concentration (except, maybe, close to
> >the edges of the network, where it makes little difference) and
> >less of that traditional type of multihoming.
> 
> There's tons of multihoming.  Every medium sized or larger business
> wants multiple upstreams for reliability.  They typically get a chunk
> of PA IPv4 addresses from each upstream.
> 
> This is a big reason why providers don't implement BCP38.  A customer
> has one block of addresses from provider A and another from provider
> B.  In general each provider only knows about its own address block,
> but the traffic comes from both blocks, and the customers get rather
> annoyed if a provider doesn't accept their traffic.  ("If you don't
> want our $20K/month, we're sure we can find someone else who does.")
> Trying to keep track of what customer has what block of someone else's
> address space is hopeless, so they just turn off the filters for the
> multihomed customers.

BCP38 should be automatable at the edge even with multihoming.  We
do have the technology to provide each customer with a CERT that
says they have been assigned this block of addresses.  This CERT
can be presented to the other providers along with a signed request
to say please accept this range of addresses over this interface.
This doesn't have to be done using BGP.  Machines can process these
without a human being involved.  It just requires willingness to
do this.

Embrace the technology.

> This is of course a place where v6 wins, since the customer can
> get their own block of PI space, but then there's all those other
> v6 deployment problems.
> 
> R's,
> John
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org