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

"Mukom Akong T." <mukom.tamon@gmail.com> Thu, 13 August 2015 18:43 UTC

Return-Path: <mukom.tamon@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 89F211B2E06; Thu, 13 Aug 2015 11:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 0k2mzV1D4n3J; Thu, 13 Aug 2015 11:43:49 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 3F8D31AC3E3; Thu, 13 Aug 2015 11:43:46 -0700 (PDT)
Received: by obbhe7 with SMTP id he7so44052550obb.0; Thu, 13 Aug 2015 11:43:45 -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=hqqKdc3huXn5Em+QSaMEqWxt3xBeib6h1W92UvuTQ/g=; b=sHFNdHy21SfdbpClMvOZZOX976f48nl1zsGauehX+ykD1pOzh5VPDfPlUs6S9IT4BF DXhmoGQNIkOxdpHzdC8OlHYcFPegdLuhLjVbsfrE0fzW3re08OCxJxgVaIWFvdtME0aB 4IiASsEjUdSAhw9Vq1Q090vMGh2zBdKuf1lFN310BbNKnWOGibvOwln1TggnpLd1lB5f yXzCbqj86eRu59qwb4wB/wLCDvG4ggwZOAJ5Zs0i42HYcs1LonhR+dCN+fOYEuixnbD5 0A9/wjRHs/YJ+gKlV9Sn+OtYgszmRSnuRTSVaO+XbwGdCF81RxSSW22Je/m1B5S061SD UrWA==
X-Received: by 10.182.120.100 with SMTP id lb4mr32241975obb.71.1439491425593; Thu, 13 Aug 2015 11:43:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.94.131 with HTTP; Thu, 13 Aug 2015 11:43:06 -0700 (PDT)
In-Reply-To: <CAO42Z2zm9Jfyo0KftOqV6hBcTU=uOkcB50vE9xD6149x5eOk8Q@mail.gmail.com>
References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> <559B5A2C.6090204@gmail.com> <CAO42Z2zm9Jfyo0KftOqV6hBcTU=uOkcB50vE9xD6149x5eOk8Q@mail.gmail.com>
From: "Mukom Akong T." <mukom.tamon@gmail.com>
Date: Thu, 13 Aug 2015 14:43:06 -0400
Message-ID: <CAHDzDLD8G3EKEu2+q97VxU4WbHHqe2OYXGUNGdMh3dtDGcBHPQ@mail.gmail.com>
To: IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="089e013a098c147edf051d35b77e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/t2yz7PeMywprRjYdoPi2qhRWMDY>
Cc: draft-ietf-v6ops-design-choices@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, 13 Aug 2015 18:43:56 -0000

Table at top of page 3 states "Works" for certain choices. I think it will
be effective to more specific about what 'Works' means in this context. As
this document is heavily L3 focused, perhaps defining 'Works' in terms of
"L3 routing and forwarding functions as expected without ....."


[snip]

  +---------+------------+-------------------+------------------------+
   |    PA   |  Tunneled  |    Works. Using   |  Works. Using private  |
   |         |            | private addresses |    addresses likely    |
   |         |            |   likely better   |     better option.     |
   |         |            |      option.      |                        |
   +---------+------------+-------------------+------------------------+

[snip]

Like Mike, I'd think some more clarifications need to be made as to why
private is a better option than PA.

- I'd rather have "works but PI is a better option"
- I'd be curious to know that what


On 9 July 2015 at 04:25, Mark Smith <markzzzsmith@gmail.com> wrote:

> 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 mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 

Mukom Akong T.

http://about.me/perfexcellence |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------