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

Mark Smith <> Thu, 09 July 2015 08:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C417F1ACC89; Thu, 9 Jul 2015 01:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mgW-IG7pbkK8; Thu, 9 Jul 2015 01:25:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (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;; 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 with SMTP id s25mr25735295ioi.65.1436430334099; Thu, 09 Jul 2015 01:25:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Jul 2015 01:25:04 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Mark Smith <>
Date: Thu, 09 Jul 2015 18:25:04 +1000
Message-ID: <>
To: Brian E Carpenter <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc:, IPv6 Operations <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jul 2015 08:25:35 -0000

On 7 July 2015 at 14:48, Brian E Carpenter <> 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.