Re: [v6ops] Re-evaluating RFC7934

Lorenzo Colitti <lorenzo@google.com> Tue, 28 September 2021 14:47 UTC

Return-Path: <lorenzo@google.com>
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 93D3F3A303A for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 07:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.097
X-Spam-Level:
X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 RZwxlkIwsApx for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 07:47:30 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 1BD453A3038 for <v6ops@ietf.org>; Tue, 28 Sep 2021 07:47:30 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id t8so58611521wrq.4 for <v6ops@ietf.org>; Tue, 28 Sep 2021 07:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4z2Lslc8JejYARMM0zuuF5yrmYg7ySRMWKKEURHy2TQ=; b=DUWFOqImzXaVMNiBZt0BgxCcOrRD/1bhSbQ+zhBpEJt6UhYaCeHtNRcjK92dUxKxKt Nm6TBgjnyxTmYRiWBFN4j6HWsz5M+bYsOOhEiPwhJ8koPoh24YoJ3ZISCcazSpwKKFiV 5w0IislLK+ur0Cs5gLODZ6iNG/E2PbtIe+d232vMtY8Fe54dgjKPd1A+cMUWuFAS6kcx i/Z+L8pMDNoLYX/mHpZkd5I1Z/NR7PpJGfctgDSzQSQTfFHeIJPLyvA5JTYQIKUmh3UI H4q/GpILajDmnMwkIDnauMNjyxgQcs5Jwyg2uTtv61I5rszcCT+YvdTSykp/fPp0SU6N KBoQ==
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:from:date :message-id:subject:to:cc; bh=4z2Lslc8JejYARMM0zuuF5yrmYg7ySRMWKKEURHy2TQ=; b=QkRGT9CJpEJ+oSMCEKUb3gkSskXvDR49mZVVY6crUb9D6tLzKo86lHDn7gU4QuQtQp 1Q2J4OW2TrWeXi4Jcu4hgQLfW2fIG4Dc4fTFvoul6O1k6Uj1VFfbEtpPNLD01ZUDnZLU 0yNCo4vwkdK2kTAWui5T/VEOSfWSXY2L8KCVy1ZQE5mxQNo+wFdwdgKHY2xzEfXr81Ob 0AjWR36rDYrlx0QYAxtsCHZXWVP/VlXb0eqqUBa1tS71CxlT0f8rnUZK/zeSBjkD3Mbd q8fwzC8BAxN5ijk3XdAzyGGk/Q51i1VbsVhb0oFipDNijyOFBBbWdK+zp6wtfUz/tbrF GsEQ==
X-Gm-Message-State: AOAM530PeIOEQj69u6gfSn/vW0IyIucSIk6Uz7M/LZDzBIJsEQQ+GzVz suEsSwTiHkw5FKvx2G63OlDQb+UGpoVFrDfLIa5S+JTcBZoEog==
X-Google-Smtp-Source: ABdhPJxo7uXj2BFZYE9WQFJEjhNVJukFvCgOzf94Y0gcue9CHzpDYmjm/E5Vw/+rqLLlPV2Bh5dOpz2BQpld6iRzwiQ=
X-Received: by 2002:a05:6000:8d:: with SMTP id m13mr488664wrx.109.1632840446490; Tue, 28 Sep 2021 07:47:26 -0700 (PDT)
MIME-Version: 1.0
References: <4527b90f-ed82-287c-29a9-8eb7f9079959@foobar.org> <CAKD1Yr1WKeWkorTxxvNAd=i+CBaY-akg0vC3zYRKWK3QN3W64A@mail.gmail.com> <9579b9bf-3e28-645d-cb33-cdea61036cc8@foobar.org>
In-Reply-To: <9579b9bf-3e28-645d-cb33-cdea61036cc8@foobar.org>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 28 Sep 2021 23:47:11 +0900
Message-ID: <CAKD1Yr2C-v47-9X_77da5CoZYW_0hmRNcPZkR8PMGuMC-EuchQ@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Cc: V6 Ops List <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ca1b8b05cd0f4a2e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_e-s8cLbfYYIleqEm-l37bPbwjQ>
Subject: Re: [v6ops] Re-evaluating RFC7934
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 28 Sep 2021 14:47:36 -0000

On Tue, Sep 28, 2021 at 10:14 PM Nick Hilliard <nick@foobar.org> wrote:

> Lorenzo Colitti wrote on 28/09/2021 13:25:
> > If the administrator has decided that the host should not use multiple
> > IP addresses, then IA_TA obviously can't be used.
>
> So when someone is at work connecting to the company network, who needs
> to comply with whose policies?  Does the company abide by the employee's
> / user's policies, or the other way around?
>

I'm not sure what policy has to do with this. If the network administrator
only wants hosts to use one IP address, then they shouldn't enable IA_TA
and IA_NA at the same time, because if they do then they could give devices
more than one IP address and will be violating their own policy.

As for the more general question, I think what actually happens depends on
the implementation on both sides. If a corporate network's policy is that
communication should only use IPv6, then Windows 98 won't work. If a
corporate network's policy is that communication should only use cleartext,
and the network blocks HTTPS, then most of today's OSes and apps will not
work or refuse to use the network. If a corporate network's policy is that
communication should only use cleartext, but the network doesn't block
HTTPS, then user devices will likely use HTTPS anyway and the user will not
be able to comply with the policy unless they choose not to connect. In all
those cases I don't think the user/employee can do much to change the
outcome (or necessarily be aware of what is happening).

Or take a more general case: if I rock up to a hosting/cloud provider or
> broadband access provider and instruct them that they're a great bunch
> of people, no really, but that they're obliged to comply with my network
> access policies for the set of products that they supply and I want to
> buy, how does that work out?
>

Not sure what that has to do with this discussion, but... maybe you file a
feature request and they decide whether to prioritize it depending on
factors such as whether other customers are asking for it, how important a
customer you are, whether it fits with their product roadmap and strategic
goals, etc. etc.?