Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?]

Octavio Alvarez <alvarezp@alvarezp.ods.org> Sat, 14 November 2015 02:47 UTC

Return-Path: <alvarezp@alvarezp.ods.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 E7E2B1B3798 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 18:47:45 -0800 (PST)
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 1EHSPestO13j for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 18:47:41 -0800 (PST)
Received: from sobre.alvarezp.com (sobre.alvarezp.com [173.230.155.94]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF81B378F for <v6ops@ietf.org>; Fri, 13 Nov 2015 18:47:41 -0800 (PST)
Received: from [IPv6:2806:220:2:4:541f:a6cb:1383:3b51] (unknown [IPv6:2806:220:2:4:541f:a6cb:1383:3b51]) by sobre.alvarezp.com (Postfix) with ESMTPSA id 385CE614E; Fri, 13 Nov 2015 21:47:40 -0500 (EST)
To: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
References: <20151106.063106.74659839.sthaug@nethelp.no> <CAO42Z2x3O8A1XKqN3PTcvM=xpF8W_WNSL1rVhHQ4ZY5HbVG=OQ@mail.gmail.com> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <CAKr6gn1KokTGJ0cg70OR=q8Uv-1mr7TmjcYJwLVgsK_3i6tcpw@mail.gmail.com> <56453026.3090607@gmail.com> <CAKD1Yr1nb1svwHDE3Z7a1xF00CRw-kOrN6+Xgd6fVjqrN=gb+g@mail.gmail.com> <20151113080508.GB89490@Space.Net> <CAKD1Yr2paTyq7L8-dU9vhtxhDd17LvKPoQt4YY2DDxB-_5ZRbA@mail.gmail.com> <20151113112141.GN89490@Space.Net> <m1ZxDn5-0000EpC@stereo.hq.phicoh.net> <564633AB.9000509@gmail.com> <m1ZxJsW-0000GnC@stereo.hq.phicoh.net>
From: Octavio Alvarez <alvarezp@alvarezp.ods.org>
Message-ID: <5646A0CB.4020406@alvarezp.ods.org>
Date: Fri, 13 Nov 2015 18:47:39 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <m1ZxJsW-0000GnC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/tGeFMdLBogqRMtfPnW2BmawrbqA>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?]
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 14 Nov 2015 02:47:46 -0000

On 13/11/15 11:19, Philip Homburg wrote:
>>> I don't think a host should try to figure out which paths work and which
>>> don't.
>>>
>>> Maybe somebody can come up with a simple algorithm that generalises
>>> happy-eyeballs and that is compatible with today's host operating systems.
>>> But I doubt it. 
>>
>> We tried. It's called shim6. Firewalls break it.
> 
> I'd call shim6 a protocol and not an algorithm. Happy eyeballs is quite 
> compatible with firewalls, NAT, etc. No problem there. I'm sure happy
> eyeballs-like approaches can be tried for the multiple-prefix case.
> 
> The problem I ran into is that by the time my happy eyeballs implementation
> did everything I wanted it do, it was way to complex. Adding support for
> many source prefixes would just be too much.
> 
> Now, maybe somebody can come up with an approach that doesn't have that
> problem. Don't know.
> 
> Mean while, I have something that works with every operating system today.
> It may not be perfect. So I'm not terribly motivated to add more host
> complexity to solve those edge cases.

Can you elaborate on your approach?

Thanks.