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

Jon Mitchell <jrmitche@puck.nether.net> Wed, 04 November 2015 07:46 UTC

Return-Path: <jrmitche@puck.nether.net>
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 571CF1B2A07 for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 23:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level:
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 6jiuJiKd0ZTC for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 23:46:16 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id D962F1B2A14 for <v6ops@ietf.org>; Tue, 3 Nov 2015 23:46:15 -0800 (PST)
Received: by puck.nether.net (Postfix, from userid 507) id 844FB540A30; Wed, 4 Nov 2015 02:46:15 -0500 (EST)
Date: Wed, 04 Nov 2015 02:46:15 -0500
From: Jon Mitchell <jrmitche@puck.nether.net>
To: "Howard, Lee" <lee.howard@twcable.com>
Message-ID: <20151104074615.GA32522@puck.nether.net>
References: <8AE0F17B87264D4CAC7DE0AA6C406F45C231921A@nkgeml506-mbx.china.huawei.com> <5637D854.2090203@bogus.com> <5637E84B.5090001@gmail.com> <5637EB69.1080608@umn.edu> <03358859-8078-489E-835D-3B4D324381BE@delong.com> <20151103204237.GJ70452@Space.Net> <CAO42Z2xen4gCfkJphZYKfjff5ZsEn_jOf5V16OtYOYNw2VKVAA@mail.gmail.com> <CAKD1Yr3Qn48eQ1Q4VovCsr_S2+RADRZKzi9qBDoh8G2w6Be+=g@mail.gmail.com> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <D25FB58B.C9B04%Lee.Howard@twcable.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D25FB58B.C9B04%Lee.Howard@twcable.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/8v2venloOSLIPmuKs6hTV-1HYjc>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] 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: Wed, 04 Nov 2015 07:46:17 -0000

On 04/11/15 04:36 +0000, Howard, Lee wrote:
> Here¹s the consensus as I currently see it:
> 
> 1. There is consensus that NAT66 (particularly NAPT) is bad, for exactly
> the same reasons given in various NAT44/CGN documents (RFC2993 and
> RFC3027, as given in the draft).
> 2. There is consensus that NPT66 is bad, for some of the reasons give in
> various NAT44/CGN documents. It might be slightly less bad than NAT66,
> since it has slightly fewer of the problems given in those documents.
> 3. There is rough consensus on the use of ULAs outside of translation
> scenarios, such as in walled garden use cases, and/or in combination with
> PA space.

> #3 is covered in the draft in some detail. Those who disagree with this
> consensus need to explain why.

Great summary - just wanted to add as an operator my agreement with #3,
I also feel after a thorough re-reading of the draft that it does not
endorse ULA+NAT solutions directly and I'm supportive of having a
document that covers this space.

> To everyone commenting on this draft, please refer to the document in your
> comments. ³This text[Š] should be changed to [Š] because [Š]² is very
> helpful. Argument by repetition or decibel is not helpful.

I think the below wording changes might be helpful although I don't
think they will specifically address any concern raised in this thread,
it may help with some of the perceived bias of the draft.

-Jon

Intro - 
replace: "normally are not used on the public Internet"
with: "they are not to be globally routed on the public Internet".

Section 3.2 - rename section title, these addresses are not Globally
Unique - maybe "Low Probability of Non-Uniqueness"

Section 4.2 -
first bullet - replace: "the standard way, this will not be a big problem."
with: "using the standard algorithm, this is extremely improbable."

third bullet - replace entirely with: "Prefix generation: Randomly
generated according to the algorithms defined in [RFC4193].  If there
are some specific reasons that call for manual predictable assignments,
that manipulation should be kept strictly in the Subnet ID and not the
Global ID, as described in Section 3.1 of [RFC4193] to avoid collision."

Section 4.3 -
replace: "and the enterprise wants to provide site-local IPv6 connectivity,
a ULA is the best choice for site-local IPv6 connectivity."
with: "a ULA may be considered for providing local IPv6 connectivity
needs."

Section 5.1 -
2nd paragraph, replace: "But it is not necessary to combine ULAs with
any kind of NAT."
with: "However it is not recommended to combine ULAs (or any other IPv6
address) with any kind of NAT."
Also, scratch last two sentences of paragraph.

Section 5.2 -
2nd paragraph, replace: "and configure ACLs on relevant border routers
to block them out of the scope."
with: "and configure ACLs and appropriate route filters on relevant
border routers to block them from leaving the domain."