Re: [v6ops] [GROW] Deaggregation by large organizations

Mark Andrews <marka@isc.org> Fri, 17 October 2014 01:06 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD81A9089; Thu, 16 Oct 2014 18:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Level:
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 j5SHoW9sZU2t; Thu, 16 Oct 2014 18:06:02 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E71C1A908B; Thu, 16 Oct 2014 18:06:00 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id E8DBC349415; Fri, 17 Oct 2014 01:05:54 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 141BB160058; Fri, 17 Oct 2014 01:09:00 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A6111160056; Fri, 17 Oct 2014 01:08:59 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9682921A4D54; Fri, 17 Oct 2014 12:05:52 +1100 (EST)
To: Matthew Petach <mpetach@netflight.com>
From: Mark Andrews <marka@isc.org>
References: <F5C06CAF-0AD2-4225-8EE7-FC72CE9913F0@muada.com> <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <A7F6BEA0-BCDD-4197-B6CB-7EB8797ACA9C@delong.com> <20141016233533.1B73521A106C@rock.dv.isc.org> <CAEmG1=r7UdeStcqFjiQRO_Vt1hfR_T4oyTW5FD-eD1ATEXpc6A@mail.gmail.com>
In-reply-to: Your message of "Thu, 16 Oct 2014 17:59:07 -0700." <CAEmG1=r7UdeStcqFjiQRO_Vt1hfR_T4oyTW5FD-eD1ATEXpc6A@mail.gmail.com>
Date: Fri, 17 Oct 2014 12:05:52 +1100
Message-Id: <20141017010552.9682921A4D54@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RR6wLZoPzFVn_2ff5iInvyZ7ABE
Cc: v6ops@ietf.org, grow@ietf.org
Subject: Re: [v6ops] [GROW] Deaggregation by large organizations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 17 Oct 2014 01:06:04 -0000

In message <CAEmG1=r7UdeStcqFjiQRO_Vt1hfR_T4oyTW5FD-eD1ATEXpc6A@mail.gmail.com>, Matthew Petach writes:
> --089e013a14fa48fd43050593df5a
> Content-Type: text/plain; charset=UTF-8
> 
> On Thu, Oct 16, 2014 at 4:35 PM, Mark Andrews <marka@isc.org> wrote:
> 
> >
> > In message <A7F6BEA0-BCDD-4197-B6CB-7EB8797ACA9C@delong.com>, Owen DeLong
> > writes:
> > >
> > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <iljitsch@muada.com>
> > wrote:
> > >
> > > > Let me address a few points that were brought up by different people.
> > > >
> > > > Renumbering:
> > > >
> > > > We had great plans for making renumbering easy in the early days of
> > IPv6. Remember A6 records and bit
> > > labels in the DNS? But none of that went anywhere. The problem isn't so
> > much that we can't push a prefi
> > > x down the network or update the DNS (although both of these still have
> > challenges associated with them
> > > ), but that addresses tend to get hardcoded all over the place, starting
> > with firewalls all the way up
> > > to homegrown applications. I don't think renumbering addresses this
> > issue, although it could help steer
> > >  some smaller organizations away from PI.
> > >
> > > They never went anywhere because they focused on solving the easy part
> > of the renumbering problem while
> > >  utterly and completely ignoring the hard part.
> > >
> > > Easy part: Changing your stuff.
> > > Hard part: Updating all of the prefix lists, filters, firewall rules,
> > VPN configurations, and other con
> > > figuration elements in systems not under your control that contain your
> > prefixes (partner VPNs, peer ro
> > > uters, etc.).
> >
> > Owen this a collective response to the list.
> >
> > Not all that hard at all.  Just send signed update requests.  I did
> > that with email over a decade ago.  You just have to have something
> > listening for them that verifies the signature and updates the
> > system.
> >
> > Write a draft "Remote Firewall Update Request Protocol" and submit
> > it.
> >
> > The alternative is stop worrying about the remote address and use
> > security at the application layer.
> >
> > Or complain to your vendor that you can't use a hostname in the
> > configuration file element.  In many cases it doesn't require
> > anything more than looking up a address in the DNS before the
> > operation.  Yes, I need to fix the masters clause in named to support
> > this.  We already do something similar for NOTIFY messages so it
> > is possible to do this.
> >
> > For masters clauses there is a bootstrap problem to deal with but
> > it is not impossible.  Just sending periodic NOTIFY messages will
> > work.  Named has had support to do this for 1 1/2 decades now to
> > allow for a a stealth master behind a dial on demand link.  It would
> > send a notify periodically.  That would bring up the line.  The
> > slave would refresh and transfer if required.  When that was complete
> > the idle timer on link would drop it.
> >
> > This just used standard signalling designed by the IETF in a different
> > way.
> >
> > Stop expecting someone else to *find* and fix these issues for you.
> > You know what the issues are.  Ask your vendors to fix them.  If
> > they need to co-ordinate they should know where to go to do it.
> >
> 
> Or, y'know, we could just get PI space,
> multihome via BGP, and save ourselves
> all that headache...
> 
> ...just sayin'...
> 
> Matt

And when we can support 40 billion routes, PI becomes a viable
solution.  Yes, this is the level that PI needs to be able to scale
to for it to be a actual solution.  Yes, mutiple routes for every
single person on the planet.

Until then we need to work towards making renumbering work so PI
isn't needed.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org