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

Ted Lemon <ted.lemon@nominum.com> Tue, 27 May 2014 14:00 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 29A531A014C for <v6ops@ietfa.amsl.com>; Tue, 27 May 2014 07:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 KC_YLx87HQNO for <v6ops@ietfa.amsl.com>; Tue, 27 May 2014 07:00:02 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198181A011D for <v6ops@ietf.org>; Tue, 27 May 2014 07:00:02 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 113911B8078 for <v6ops@ietf.org>; Tue, 27 May 2014 06:59:59 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E8D4F19005C; Tue, 27 May 2014 06:59:58 -0700 (PDT)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 06:59:53 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <5384937A.90409@foobar.org>
Date: Tue, 27 May 2014 09:59:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <1CFC65A0-22E6-4D2B-BA01-D5F4C0E17BAC@nominum.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <m261ks7xww.wl%randy@psg.com> <53840070.90801@gmail.com> <m2y4xn7wep.wl%randy@psg.com> <53840723.8010606@gmail.com> <CAKD1Yr1O_poMR200sjU=ttRvGaeQRkC1ZfXC0Ok4uQxdq3K=NQ@mail.gmail.com> <m2mwe37tbn.wl%randy@psg.com> <CAKD1Yr2t3-vxuG=iDi4biBNFpJwuzuHgfpB74i_uydWWRV7qZg@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <m2fvjv7q4h.wl%randy@psg.com> <m1WpDcc-0000BMC@stereo.hq.phicoh.net> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.1878.2)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZLkUhHUaD9uRLUSqiBpD2I9tLIs
Cc: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>, v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] 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, 27 May 2014 14:00:07 -0000

On May 27, 2014, at 9:30 AM, Nick Hilliard <nick@foobar.org> wrote:
> or use NAT.  I'm not saying this in order to throw fuel on an existing
> fire, but simply because this is the reality for many organisations in the
> ipv4 world, and I see little reason why it will change for ipv6.  The IETF
> can make recommendations about whether it thinks this is a good idea or
> not, but it is not productive to pretend that the elephant isn't in the room.

Right, the point is that if we provide advice on how to set up ULA networks so that future transitions of this sort do not require NAT, that's worth doing.   Actually, for the enterprise scenario, I think the advice should just be "get a GUA, use it like a ULA" because that excludes the possibility of a future clash when two behemoths merge.   But it makes source address selection harder.   And there was a document a while back about informal ULA registries, IIRC, which could also represent a good mitigation strategy if it were to happen (but I think that's outside our scope of work).