Re: [v6ops] draft-buraglio-v6ops-ula discussion

Nick Buraglio <buraglio@es.net> Mon, 01 August 2022 16:16 UTC

Return-Path: <buraglio@es.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4A5C157B35 for <v6ops@ietfa.amsl.com>; Mon, 1 Aug 2022 09:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, 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=es.net
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 2iFUMNt06C1G for <v6ops@ietfa.amsl.com>; Mon, 1 Aug 2022 09:16:33 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 174D6C15790C for <v6ops@ietf.org>; Mon, 1 Aug 2022 09:16:33 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id v16-20020a17090abb9000b001f25244c65dso15799439pjr.2 for <v6ops@ietf.org>; Mon, 01 Aug 2022 09:16:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=shsopkmN2Oi3AN87oTcQyyXr547wKrI5Yt5YG6umsBM=; b=G6Mr2v/cnnh6lqeLZ2l5KCd3b9ZJcsRIuUakrRqrSp4UhP1YGQvISL1H+h66ocQGNJ fBm/bTpY9ptUrWbdA9TzphwYbQ2pWSd8SMY3SSUlRUORCi8+T/oB0NNwrLZJepypRkLq wjGHcx+Ym5W3vkU0vV/DM2jCZcoI9KFZgIweBAn708vDkvllpgTs1ACbcuA6iddafrWb jeH+1QZHtS2a98ZdkfWuR0H5h7wXzmW0Tp73iarkFSAZZ2RmCBQ3gtuTHD4Pi85sPsPe AF2RHwo8L3T4ACXtg0oiIGyTrOQhx6Go3qLl+nE411w9d6BQXNGdxHLSRHmn4SUy809T pw0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=shsopkmN2Oi3AN87oTcQyyXr547wKrI5Yt5YG6umsBM=; b=Kwm3z38lBnAAdfngkwsspVCwqC8GsWNqTZCPsBQlVFZ0DTopZaSLZ0mbAWneL1/3lZ YdSZ8O4gn+H/UsEIGfmJ5ApZH8cDbwYgODgJIWpLMrkKdibIy1oIiw51kIj5kp6rnaVC pCPHIttnm07PA7TxX1VQc92M8fsAkj9qrG5ZUm3Lq99WQyc8zGfONUP+UPrXZ+nDyQXd /O374wUkg2/qG3FEzFCZDxajIz2LxzGbUVq28WktpSOl/HWJFBDMTcLsAOCQdKR94zVd myjBgG1tTy5Bs7Dqe/e4haxM3odu4ckGgCMtw2pDJLWPvX/D5t2kjYwjpUg33rARxqgZ WIbA==
X-Gm-Message-State: ACgBeo2NqtMHAHDASP9N/yLYa7c1C8TqdeqpGhKHM1ajunbBLoIhWzwo nz6tOvQApFPIutbMolxHxLMx+KVn7tSQID0Ya/NjtkOpXKuwsQM0IMooOcCVxI/EhlQU4YDiN5V VPYzO6g50B1NO15W7/qQNWbKHz3OqEW8pDG/JUBw4ZC93f8qIrCbS/ahunK3XhpGImYT7CDmfFD w=
X-Google-Smtp-Source: AA6agR57yWUCVfBTsezl3zHVdiEQ0lJ8j8bXlU8ngJbAfl+wdVVgc0o+lhGSH5yMzc7/HadJhL49z8ThFKeU50sQVGI=
X-Received: by 2002:a17:902:e748:b0:16e:f6c2:3735 with SMTP id p8-20020a170902e74800b0016ef6c23735mr3278669plf.106.1659370592112; Mon, 01 Aug 2022 09:16:32 -0700 (PDT)
MIME-Version: 1.0
References: <CABKBHweedb9Cmefy3M+jBkX3P_ML++a2N7SpSKVcZ0gL2U5K8w@mail.gmail.com> <CAE=N4xf-O4MQAQkJLDF7S42RwhTRpk1GncosEnAFjCSsn0Yd5g@mail.gmail.com> <23efcafb7c6544dd84b4e49d47d90796@huawei.com> <CADzU5g5H2reNvrHB+_sdyCr1pS1vMnu1ZSG+=XAhwAoOGvzGSA@mail.gmail.com> <72a5b0486c384345b968cfd70c6052f6@huawei.com>
In-Reply-To: <72a5b0486c384345b968cfd70c6052f6@huawei.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Mon, 01 Aug 2022 11:16:21 -0500
Message-ID: <CAM5+tA96b7V6ui90WOopL4es_vWLtCkjaCivn=H6M18CSPjjdw@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Cc: Clark Gaylord <cgaylord@vt.edu>, v6ops list <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lZuX842lEjmRpRn4IA6itDcOUv0>
Subject: Re: [v6ops] draft-buraglio-v6ops-ula discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 01 Aug 2022 16:16:36 -0000

While true, I would encourage us to not turn this into yet another
referendum on NAT. For the scope of this draft, it's important to note
that its sole purpose is to document the default behavior of ULA,
which in turn highlights the shortcomings in the case of using ULA in
that manner. One of the intended goals is to highlight that ULA is not
a replacement for RFC1918 as many, many of us get that assertion and
question in the first 5 minutes of IPv6 conversations.

On Mon, Aug 1, 2022 at 11:06 AM Vasilenko Eduard
<vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
>
> Connection to 2 Carriers is not possible now in any other way except ULA+NPT.
>
>
>
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Clark Gaylord
> Sent: Monday, August 1, 2022 6:29 PM
> To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
> Cc: v6ops list <v6ops@ietf.org>
> Subject: Re: [v6ops] draft-buraglio-v6ops-ula discussion
>
>
>
> For most use cases private legacy replacement is global addressing. Wide scale ULA will only encourage NAT66 and similar abominations. The point of IPv6 is to restore the end-to-end principle to the network (and the way we *think*) not perpetuate bad ideas.
>
>
>
> We should absolutely encourage proper use cases for ULA but the VM farm, for example, typically *isn't* it. (Someone recently pointed out the control plane of their mpls fabric -- that's probably a good example.)
>
>
>
> Enterprise network admins got sold a bill of goods by vendors who wanted to keep them ignorant telling them that "NAT = security".
>
>
>
> --ckg
>
>
>
> On Mon, Aug 1, 2022, 11:18 Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
>
> +1.
>
>
>
> 1.
>
> DualStack is for a long time in the Enterprise.
>
> ULA priority below IPv4 makes it useless.
>
> People would be looking for a Private IPv4 replacement.
>
> The absence of the replacement would considerably delay IPv6 adoption in the Enterprise.
>
>
>
> 2.
>
> Not many expect such ULA priority. People are massively misleaded.
>
>
>
> Eduard
>
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ed Horley
> Sent: Monday, August 1, 2022 6:02 PM
> To: Fred Baker <fredbaker.ietf@gmail.com>
> Cc: v6ops list <v6ops@ietf.org>
> Subject: Re: [v6ops] draft-buraglio-v6ops-ula discussion
>
>
>
> I support adoption of the draft
>
>
>
> On Mon, Aug 1, 2022 at 08:01 Fred Baker <fredbaker.ietf@gmail.com> wrote:
>
> At IETF 114, Nick discussed draft-buraglio-v6ops-ula, which is ongoing in another thread. He asked for the WG to adopt the draft; should we?
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> --
>
> ed@hexabuild.io - 925-876-6604
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops