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

Mark Andrews <marka@isc.org> Mon, 02 June 2014 02:58 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 B7EF41A0127 for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 19:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 4kUtpkGjMzjR for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 19:58:42 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 648B91A011B for <v6ops@ietf.org>; Sun, 1 Jun 2014 19:58:42 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id A951F34940E; Mon, 2 Jun 2014 02:58:36 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 646E7160069; Mon, 2 Jun 2014 03:04:08 +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 2CFA6160068; Mon, 2 Jun 2014 03:04:08 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A659C1723F0A; Mon, 2 Jun 2014 12:58:33 +1000 (EST)
To: Ted Lemon <ted.lemon@nominum.com>
From: Mark Andrews <marka@isc.org>
References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.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> <CAKD1Yr1cGx7UfxZaEhm7oHA5PLvghVc52oPVkEQF90_7Vm__vw@mail.gmail.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bog us.com> <D743D805-0A93-4E6A-84D8-FEAC8D27F267@nominum.com>
In-reply-to: Your message of "Sun, 01 Jun 2014 22:30:28 -0400." <D743D805-0A93-4E6A-84D8-FEAC8D27F267@nominum.com>
Date: Mon, 02 Jun 2014 12:58:33 +1000
Message-Id: <20140602025833.A659C1723F0A@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/P7MoP6Wct8Qr9k6UxbMX3V7Fozg
Cc: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>, V6 Ops List <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: Mon, 02 Jun 2014 02:58:44 -0000

In message <D743D805-0A93-4E6A-84D8-FEAC8D27F267@nominum.com>, Ted Lemon writes
:
> On Jun 1, 2014, at 10:28 PM, joel jaeggli <joelja@bogus.com> wrote:
> > So don't asssume that every application needs to be aware of and test
> > for which path is working, not only is that needless complexity pushed
> > up into the stack. let your routers do their job and cease routing when
> > their upstream connectivity is lacking.
> 
> Right, but this doesn't actually work.

Setting the prefix's preferred lifetime to 0 in RAs when the uplink
goes and restoring it when the uplink works does work for non-broken
stacks.  Yes this is crude but so is advertising default.  Withdrawing
default is what routers should be doing when there isn't a working
default. 

There is also nothing to prevent a stack trying multiple source
addresses when it hasn't been explicitly bound to a source address
by the application.  The stack doesn't have to complete TCP handshakes
if it doesn't need to.

If all else fails the application layer is free to explictly try
different source addresses.  Hiding this detail in a library routine
is not hard.

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org