Re: [IPv6] IPv6 doesn't have a business case (Re: IPv6+NAT is just bigger IPv4+NAT, and even less of a reason to adopt IPv6 (Re: NPT66 POC [WAS: Re: Best Source / Destination address pair [WAS: Best Address type (assuming God's view)]]))

Mark Smith <markzzzsmith@gmail.com> Mon, 18 September 2023 20:45 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333B8C1519BC for <ipv6@ietfa.amsl.com>; Mon, 18 Sep 2023 13:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GswOLONoU0kh for <ipv6@ietfa.amsl.com>; Mon, 18 Sep 2023 13:45:57 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8B9C1519B8 for <ipv6@ietf.org>; Mon, 18 Sep 2023 13:45:56 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-530ab2d9e89so3590577a12.2 for <ipv6@ietf.org>; Mon, 18 Sep 2023 13:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695069955; x=1695674755; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Mx5QHbSDaZQPaRUE2zBGxCrujVLDCiwLHLZTytTYdyM=; b=QJLpEVhK6GFCUXDsZYTnDtDPhs7t2uSXg4ZLhDQdamRrPOhiV9xAC9P20QgllsJ9rp 6JRyN6qENAmu7KrngLtHlLutM2f9IpGPhbBterNCt4SP3bpLLKiqo86UwX5rJ4ji0t3N 3Yc3x6wje50aosjtpZsdUa0gndwlP93CY7RRR/v4x6MShQG993NgBBOFoTS90MXZHSnc mSO77bXcZFLBuCsIjB7tk192VItyuBFa1yho1ZMfSIH0rcWQ5q2NvA749C+j9xZTNIZ3 jTi5zqTOD/ZRk08RsOJIgzDNdvPRb0I47mln+35SqJJJIg2t2pTFczmFGmk+5/XHw4FN 4lkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695069955; x=1695674755; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Mx5QHbSDaZQPaRUE2zBGxCrujVLDCiwLHLZTytTYdyM=; b=RFv1USobOUz7I4lveJtpCoceYGKqqb12CSlAyrC+5m87uYcsDGsIAbircMEfTVUhgh PNMk39v48nPr472y/suh/BLQNET9K7svcYXm7H1a3vwoM7rHqJFDBM9GGT64EgyZAeuC dLl+dMMy8SZbG89j68qXggWBB5EYHR9GYahEAmA82zWGfx1qSvWms/ft8bF3Z3oCIRTC qXPoLduA9Ns6/a9iZizD67WjcklUWOToyBaM9j2QB+VlUX0aU4xdwrnKIK+PGrqzWVkG mJxwYC//eNDsicyCQ2dPAQENSWr+sjTGfiOkJKL6IZeLyj8RsT7iOpi4nbfKThHo8Lkd DoRw==
X-Gm-Message-State: AOJu0YzE8RbjUxyXOM+XM41lQ4AP3JgWNgst2ClKPovubl9I9d3zlh4B s0QZhfpN5vUJlfDtbkRVHdl6wG2le5rLx6uD0h/HczDJ
X-Google-Smtp-Source: AGHT+IF1EFov40X7sbv2Xz+jGmKjukb6qkDlQ5V04hY8L8bfbyTkPbXDLrwsVXc4UfNFINho4wHYMQG/4pO9AYWn+Pg=
X-Received: by 2002:a05:6402:1501:b0:528:90d7:a19 with SMTP id f1-20020a056402150100b0052890d70a19mr9363255edw.11.1695069954582; Mon, 18 Sep 2023 13:45:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAN-Dau0H-U_b3rGqK9FC9Z=7rTZb0voprdTyeheq5_5iwQ6R7Q@mail.gmail.com> <8F9C9ED0-272C-4524-B26D-143CDB8476CC@employees.org>
In-Reply-To: <8F9C9ED0-272C-4524-B26D-143CDB8476CC@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 19 Sep 2023 06:45:43 +1000
Message-ID: <CAO42Z2x1JCHNbA8jGzX95zhthLG1oEkjJr0qKLgKMTGLSWEnfw@mail.gmail.com>
To: Ole Trøan <otroan=40employees.org@dmarc.ietf.org>
Cc: David Farmer <farmer=40umn.edu@dmarc.ietf.org>, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008330310605a83a54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dQQos8wM20p3r7pdXb_DdFeLr9M>
Subject: Re: [IPv6] IPv6 doesn't have a business case (Re: IPv6+NAT is just bigger IPv4+NAT, and even less of a reason to adopt IPv6 (Re: NPT66 POC [WAS: Re: Best Source / Destination address pair [WAS: Best Address type (assuming God's view)]]))
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Sep 2023 20:45:58 -0000

On Mon, 18 Sept 2023, 23:53 Ole Trøan, <otroan=
40employees.org@dmarc.ietf.org> wrote:

>
>
> On 18 Sep 2023, at 14:50, David Farmer <farmer=40umn.edu@dmarc.ietf.org>
> wrote:
>
> 
> That is why I called out all three, NPTv6, NAT66, and NAPT66, as I think
> there are legitimate use cases for all of them. The use cases for NPTv6 are
> restricted by the need for a common prefix length on the inside and the
> outside. However, that doesn’t mean it’s not useful in many cases, it’s
> just not useful all cases.
>
> NAT66 is useful in the cases where NPTv6 can’t be used, that is a larger
> prefix on the inside. And NAPT66 is useful when you want obscure the usage
> of individual users, by mixing multiple users together, probably a large
> number of users, to create additional privacy.
>
> So in my opinion, there are different use cases for each of them. However,
> address conservation isn’t a valid use case for any of them, as it is
> unnecessary in IPv6. But that doesn’t mean there aren’t other valid reasons
> to use, NPTv6, NAT66, or NATP66.
>
>
> Agree with all that you say.
> In addition, an important feature of NAPT66 is permission-less extension
> of the network.
>

NAPT doesn't allow permissionless providing of services to other nodes on
the network.

NAPT forces an client-server application communications model at the
network layer. Nodes behind/inside the NAPT device cannot be permissionless
servers or peers.

If you care about Internet decentralisation, you don't encode a
client-server communications model at the network layer.

You ensure that possession of an address means a node can be an application
client, server or peer, which ever suits the application.




> O.
>
>
> Thanks.
>
> On Mon, Sep 18, 2023 at 02:25 Vasilenko Eduard <vasilenko.eduard=
> 40huawei.com@dmarc.ietf.org> wrote:
>
>> NPT is not very practical because mandate to have the same prefix inside
>> and outside.
>>
>> That is not possible in principle on the Mobile side (DHCP-PD is blocked).
>>
>> Ed/
>>
>> *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Nick Buraglio
>> *Sent:* Thursday, September 14, 2023 9:01 PM
>> *To:* David Farmer <farmer=40umn.edu@dmarc.ietf.org>
>> *Cc:* 6man WG <ipv6@ietf.org>
>> *Subject:* Re: [IPv6] IPv6 doesn't have a business case (Re: IPv6+NAT is
>> just bigger IPv4+NAT, and even less of a reason to adopt IPv6 (Re: NPT66
>> POC [WAS: Re: Best Source / Destination address pair [WAS: Best Address
>> type (assuming God's view)]]))
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 14, 2023 at 12:50 PM David Farmer <farmer=
>> 40umn.edu@dmarc.ietf.org> wrote:
>>
>>
>>
>>
>>
>> On Thu, Sep 14, 2023 at 00:51 Mark Smith <markzzzsmith@gmail.com> wrote:
>>
>>
>> What would NAPT66 give them that they don't already have with NAPT44?
>>
>>
>>
>> You’re ignoring the very reason you said enterprises do anything, money.
>> IPv6 with NAPT66 gives them virtually free and unlimited outside addresses.
>> IPv4 with NAPT44 costs >$35 per outside address, or frequently $1 monthly
>> per outside address.
>>
>>
>>
>> Furthermore, IPv6 with NAPT66 gives them a virtual guarantee of only one
>> layer of NAT that they can control. With IPv4, NAT444 is becoming much more
>> commonplace, and the first layer of NAT loses control.
>>
>>
>>
>> The costs of obtaining IPv4 addresses are beginning to create a
>> relatively easy business case to do IPv6, even for users of NAPT44. And if
>> an enterprise has a large amount of IPv4, it can make some money through
>> the IPv4 market instead of only saving money.  These are features of the
>> IPv4 market, not bugs.
>>
>>
>>
>> However, without NPTv6, NAT66, or NAPT66, they have to radically change
>> their network deployment model in order to deploy IPv6. Personally, I’m
>> quite happy to build my networks with native public IPv6 addresses, that
>> is, without NAT. But I don’t think you can put the NAT genie back in the
>> bottle. And I’m not willing to condemn those who want NPTv6, NAT66, or even
>> NAPT66.
>>
>>
>>
>> Not acknowledging NAT worked so well with IPv4 years ago.  I would prefer
>> a standard definition for NPTv6, NAT66, and  NAPT66 for compatibility
>> reasons, the real reason we have standards in the first place, instead of
>> all the slight variations for the lack of a standard definition of NAT44
>> and NAPT44.
>>
>>
>>
>> I have heard countless times that end-to-end is considered a notable and
>> significant negative to many security teams. They're SO used to NAPT being
>> present and that they consider it a part of their security defense in depth
>> strategy. It doesn't matter if that is technically correct or not.  If
>> history is any indicator, enterprises will do what they are going to do
>> regardless of what standards say. Again, that's why I have advocated to
>> "control the conversation" by at least framing things in sane ways lest we
>> end up with more of a mess that we're already in. I agree with David, and I
>> would also add that I think we're hyper-focusing on the "NAT at the edge
>> and hide addresses" attribute, mostly because it is undesirable from the
>> perspectives of many.
>>
>> NPTv6 does actually have some compelling other use cases which enable
>> diversity in security platforms like UTMs which are potentially positioned
>> in geographically diverse locations but need to allow for redundancy of
>> addressing while not breaking symmetry of flows. It is in this model that
>> it can be GUA to GUA, and this is a definite valid, supportable, and
>> definitely production deployed architecture.
>>
>> We shouldn't throw out the baby with the bath water or overly focus on
>> the one part we don't like. Tools can always be "misused", especially when
>> the use cases are not well defined - in the absence of a framework, people
>> make their own (see: "control the conversation").
>>
>>
>>
>> nb
>>
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>