Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

Nick Hilliard <nick@foobar.org> Tue, 24 June 2014 18:49 UTC

Return-Path: <nick@foobar.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 850CE1B2BE8 for <v6ops@ietfa.amsl.com>; Tue, 24 Jun 2014 11:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AuxDoMccU_eZ for <v6ops@ietfa.amsl.com>; Tue, 24 Jun 2014 11:49:56 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 68C6F1A039C for <v6ops@ietf.org>; Tue, 24 Jun 2014 11:49:53 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OInkml091173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 19:49:47 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org
Message-ID: <53A9C84A.8020304@foobar.org>
Date: Tue, 24 Jun 2014 19:49:46 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>
References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <m1WqqZ4-0000DqC@stereo.hq.phicoh.net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <m1WqrFK-0000BHC@stereo.hq.phicoh.net> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <CAKD1Yr0pvet1oOip-Y2Xi_h2mSZfW1R5HtfiAGbDEns0dY-d2A@mail.gmail.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <CAKD1Yr2NH4Kca4EvhjN2XnDbt8F2eS56ipxu3npH9yOh1bmQaA@mail.gmail.com> <F12F173B-9FF2-4EF8-B11E-33AEDA24961F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> <BA6D229B-0645-42CB-BC29-DB467EB697A7@nominum.com>
In-Reply-To: <BA6D229B-0645-42CB-BC29-DB467EB697A7@nominum.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/50QAjiASAV4D4le6ps-veMaxDxU
Cc: v6ops@ietf.org
Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]
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: Tue, 24 Jun 2014 18:49:58 -0000

On 24/06/2014 18:38, Ted Lemon wrote:
> This isn't really true.   If your routing is set up right and source
> address selection is configured correctly, you can do multihoming.

I'm trying to read between the lines here and am going to assume that
you're talking about end hosts with multiple addresses being contactable
over different links from other networks where next-hop interface selection
based on destination addresses (which is defined for ipv4) is used.

> It's not clear that every device supports it, and it's not particularly
> easy to make it work at the moment, but it is _certainly_ possible to
> make it work.

Most people need protocols which just work rather than protocols which
we're assured that it's possible that they can be made to work, assuming
that there is device support and that the routing is set up correctly.  And
that address selection is configured correctly.  And that you're doing
one-legged cartwheels on nights where there is both a full moon and
planetary alignment and you're waving dead chickens in the air.  I've spend
enough of my career dealing with that level of brokenness and it's not
worth it by any widely-accepted metric: financial / technical / etc.

> The same is not true of IPv4, and it's unlikely we (the
> IETF) will do the work to fix that, because nobody (that I know of)
> cares.

indeed because it's not necessary.  People who need reliable multihoming
for either ipv4 or ipv6 will acquire an address assignment or allocation
and will use that.  It just works, and the people who do it don't much mind
the small amount of global blood-letting it causes.

Nick