Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 07 July 2015 04:48 UTC

Return-Path: <brian.e.carpenter@gmail.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 C558C1A89BB; Mon, 6 Jul 2015 21:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 IRa-BfD7c0Vn; Mon, 6 Jul 2015 21:48:50 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788DE1A89B9; Mon, 6 Jul 2015 21:48:47 -0700 (PDT)
Received: by pactm7 with SMTP id tm7so106534009pac.2; Mon, 06 Jul 2015 21:48:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aB0HCb/7WXV9tMuZ4Sneerwf/n5RIkKBjOQuhVhuXYQ=; b=QUrQN2Xoy49QJ7QKWsSqoVfPJ7r8RJhRbQKFTKzSkTvWXy3MSVc4x3JhLucY8KVKDn qH6DEIgLH/zlhVUDkGGhMKyMrYM56ctRSX3Y3/8GwbPuCkTwJGGDsH/PLl0pVAYx3EC2 Pa2DsnIhEeMQjCodUwcuuIOl9e/plPaOiSfq7c2Ecc7VcXxUxgiu/+KZ1HvOG4Mo6k0A hXB7etARR/qJKJfCzH38eOt4JrnepqekRyb2KJMuBp2CSFyXSepZacw8XXAQt4TYvQYe RpUws/oNzcyzE/UQOoShECkZjK3kkyCmrFoE9caJA9WLI4W8u9MmD+uDw1Jjg2zYyXyy ltdA==
X-Received: by 10.68.112.195 with SMTP id is3mr4869956pbb.92.1436244527140; Mon, 06 Jul 2015 21:48:47 -0700 (PDT)
Received: from ?IPv6:2406:e007:42f0:1:28cc:dc4c:9703:6781? ([2406:e007:42f0:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id vz2sm16293877pbc.71.2015.07.06.21.48.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 21:48:45 -0700 (PDT)
Message-ID: <559B5A2C.6090204@gmail.com>
Date: Tue, 07 Jul 2015 16:48:44 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: draft-ietf-v6ops-design-choices@ietf.org
References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com>
In-Reply-To: <20150706212506.2640.97532.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/BSQS5BRKuqiw-wTK4DxjJ3MCIWc>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt
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: Tue, 07 Jul 2015 04:48:51 -0000

Hi,

I don't understand why you mention RFC 1918 in a document about
IPv6 deployment.

In the table in 2.1.1, I object strongly to the comment against
private (i.e. ULA) addresses
"Will probably require some sort of NAT on links to the Internet."

That isn't the architecture. The architecture is that nodes have multiple
addresses, and only use ULAs for internal traffic, and use PA or PI addresses
for Internet traffic. We shouldn't be documenting any other usage of
ULAs. We shouldn't be making statements like this:

"For an enterprise, the use of private address space is	
reasonable, but the enterprise will need to use NAT44 and/or	
NPT[RFC6296] on links to the Internet."

We clearly can't pretend that NAT44 isn't widely used, but IMHO it should
be completely out of scope in this document, and NPTv6 is an experimental
RFC that we should never recommend. ULAs should *only* be used in parallel
with PA or PI. That isn't an afterthought; that is the basic intention behind
ULAs.

Stepping back slightly in the text:
"In this case, the use of PI space is the best	
option, as it gives the most flexibility in the future.  However,	
some organizations may be unable or unwilling to obtain PI space - in	
this case PA space is the next-best choice."

What size of enterprise are you addressing? Whatever the current RIR policy
is, it remains irresponsible to hand out PI prefixes like candy. Please tune
this language to make it clear that it applies to hundreds or thousands of
large customers, probably not to small/medium enterprises, and definitely
not to millions of SOHO customers, who will inevitably get PA.

Stepping back to the first sentence of the Introduction:

"This document discusses certain choices that arise when designing a
IPv6-only or dual-stack network."

This really needs to specify the classes of customer it is addressing.
You split some of the later material into "ISP" and "Enterprise"
but that (and customers that are not covered) needs to be made clear
at the beginning, and even in the Abstract.

Nit:

"2.4.3.  RIP	
		
   A protocol option described in the table in this section is RIP	
   [RFC2080]."

Don't you mean "*not* described in the table"? And its name is RIPng.

Regards
   Brian