Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt
Mark Smith <markzzzsmith@gmail.com> Thu, 09 July 2015 08:25 UTC
Return-Path: <markzzzsmith@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 C417F1ACC89; Thu, 9 Jul 2015 01:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
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 mgW-IG7pbkK8; Thu, 9 Jul 2015 01:25:34 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (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 A4DBD1ACAD4; Thu, 9 Jul 2015 01:25:34 -0700 (PDT)
Received: by ieru20 with SMTP id u20so28648803ier.0; Thu, 09 Jul 2015 01:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b41fVN5M/2/QFXo+XKBpfSBf/qrn1ZxuRwpaG14gvfU=; b=sSTj7eslQHE7X9M22g0AbDNaWevvxzUpb9kzH52oXhqjhnMv7GB6smINrErdwdCJ8z ZYsxbo6BgLphJSxoLBJrIXMG9TcJSKkJCuSEPbgHkQLhRrqxBfjd9at2xXIa+RxgQTLR wOcg4J05ysNfZIh3r5a6TR65YGPcjFZ+oe7ztTKp3gEV5KM9Pf4aGODinv0qsBVaylSR JFI3JPcIyOJE6MY4akRpQAsu/dJxYQrRDiPROBGuqP0kOQCCwPPHB8oMbNSMVzWqhVOK fp503r7EXS3M20jZdIJv2dqFjgf29iMyGhye+VGx081/a+0h4OHW3Q0GuT331nSBYXRh hVXw==
X-Received: by 10.107.136.153 with SMTP id s25mr25735295ioi.65.1436430334099; Thu, 09 Jul 2015 01:25:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.205.5 with HTTP; Thu, 9 Jul 2015 01:25:04 -0700 (PDT)
In-Reply-To: <559B5A2C.6090204@gmail.com>
References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> <559B5A2C.6090204@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 09 Jul 2015 18:25:04 +1000
Message-ID: <CAO42Z2zm9Jfyo0KftOqV6hBcTU=uOkcB50vE9xD6149x5eOk8Q@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/JlL3t0XVzHKecIaJ2s59KplWCeU>
Cc: draft-ietf-v6ops-design-choices@ietf.org, 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: Thu, 09 Jul 2015 08:25:35 -0000
On 7 July 2015 at 14:48, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > 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. I agree. Unless you're using link-locals only in your network (and that isn't really possible for the edge networks), there is always an address selection process going on between the always present link-locals and the other address or addresses that are available. Perhaps it isn't that common knowledge that link-local addresses are quite valid to be used by/for applications, as per RFC4007, and are normally preferred over all other address types if they're available to the application, excepting the loopback prefix, because link-locals have the second smallest scope (and the smallest scope is preferred). In other words, most IPv6 networks are multi-prefix even if their operators think they aren't because they "only" have a single GUA. This is probably worth more visibly highlighting or emphasising in this draft, because it seems to be something that is commonly forgotten or not completely realised. > 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. > I've thought that if it is unacceptable for devices inside your network to have global addresses, then your security requirements are probably so stringent that NPTv6 devices, packet filters and stateful firewalls would be too simple to achieve and implement them. Instead, you'd use application layer proxies for specific applications you permit, that act on behalf of and completely or near completely hide the identity of the devices inside your network, and prevent any possible reachability to those devices, inherent in ULA addressing, unless the application layer proxy itself is compromised. If using per-application application layer proxies is considered too onerous or costly, then I think the security measures you'd have in place (e.g., host firewalls, network perimeter firewalls/packet filters) would mean there is less risk to deploying global addresses internally compared to the benefits of having them. <snip> Regards, Mark.
- [v6ops] I-D Action: draft-ietf-v6ops-design-choic… internet-drafts
- Re: [v6ops] I-D Action: draft-ietf-v6ops-design-c… Philip Matthews
- Re: [v6ops] I-D Action: draft-ietf-v6ops-design-c… Brian E Carpenter
- Re: [v6ops] I-D Action: draft-ietf-v6ops-design-c… Ackermann, Michael
- Re: [v6ops] I-D Action: draft-ietf-v6ops-design-c… Mark Smith
- Re: [v6ops] I-D Action: draft-ietf-v6ops-design-c… Mukom Akong T.
- Re: [v6ops] I-D Action: draft-ietf-v6ops-design-c… Philip Matthews