RE: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Mon, 26 July 2021 08:05 UTC

Return-Path: <giuseppe.fioccola@huawei.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 861C13A2023; Mon, 26 Jul 2021 01:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 O7usaLtSb0fR; Mon, 26 Jul 2021 01:05:44 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C873A203A; Mon, 26 Jul 2021 01:05:43 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GYC1F5tGsz6DHPf; Mon, 26 Jul 2021 15:56:33 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 26 Jul 2021 10:05:40 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2176.012; Mon, 26 Jul 2021 10:05:40 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Mark Smith <markzzzsmith@gmail.com>
CC: Mike Simpson <mikie.simpson@gmail.com>, Yoshifumi Nishida <nsd.ietf@gmail.com>, 6MAN <6man@ietf.org>, Christopher Wood <caw@heapingbits.net>, "draft-ietf-6man-ipv6-alt-mark.all@ietf.org" <draft-ietf-6man-ipv6-alt-mark.all@ietf.org>
Subject: RE: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
Thread-Topic: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
Thread-Index: AQHXf5VoEeiWhDaRmEKOhylCD9QmaqtQNEwAgADX9YCAA95roA==
Date: Mon, 26 Jul 2021 08:05:40 +0000
Message-ID: <8af02c499d19404281d81b496729b9c1@huawei.com>
References: <ea7246fe81b140fba42e6d202c2afc8b@huawei.com> <B2749D3A-FF51-47ED-9D25-D973BF9A4309@gmail.com> <5cd00f25326146619c699160d671a4f2@huawei.com> <CAO42Z2zUcK_k=VO4b+wxJWDWxA=TR5w9W7oAufMZ9Ufiks6-Tw@mail.gmail.com>
In-Reply-To: <CAO42Z2zUcK_k=VO4b+wxJWDWxA=TR5w9W7oAufMZ9Ufiks6-Tw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.218.47]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SiLfJvKQVEXixKDSG0tbA-Ubr48>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Jul 2021 08:05:58 -0000

Hi Mark,
I agree. In an RFC the conservative approach must be recommended.
Regards,

Giuseppe

-----Original Message-----
From: Mark Smith <markzzzsmith@gmail.com> 
Sent: Saturday, July 24, 2021 1:00 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: Mike Simpson <mikie.simpson@gmail.com>; Yoshifumi Nishida <nsd.ietf@gmail.com>; 6MAN <6man@ietf.org>; Christopher Wood <caw@heapingbits.net>; draft-ietf-6man-ipv6-alt-mark.all@ietf.org
Subject: Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

On Fri, 23 Jul 2021, 18:20 Giuseppe Fioccola, <giuseppe.fioccola@huawei.com>
wrote:

> Hi Mike,
>
> To avoid misunderstanding, the precondition of controlled domain may 
> be kept as MUST. We can further specify that authentication MUST be 
> used if, for specific scenarios, it is applied outside a controlled domain.
>

Realise that a "MUST be limited to a controlled domain" in an RFC is nothing more than an aspiration. It's theory rather than reality.

Packets are encouraged to try to exit "controlled" domains attached to the Internet due to the domain's default route, and then can leave the controlled domain ("leak") due failure of the controlling boundary because of implementation bugs, operator configuration error or partial node failure.

Authentication must be a MUST for anything that is designed for a controlled domain if the controlled domain may be attached to the Internet, which is a possibility for any of them if they use IPv6.

Packets getting to where they shouldn't would be one of the motivations of Postel's "Be conservative with what you send".


Regards,
Mark.



>
> Regards,
>
>
>
> Giuseppe
>
>
>
>
>
> *From:* Mike Simpson <mikie.simpson@gmail.com>
> *Sent:* Friday, July 23, 2021 9:36 AM
> *To:* Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
> *Cc:* Erik Kline <ek.ietf@gmail.com>; Yoshifumi Nishida < 
> nsd.ietf@gmail.com>; 6man@ietf.org; Christopher Wood 
> <caw@heapingbits.net>; draft-ietf-6man-ipv6-alt-mark.all@ietf.org
> *Subject:* Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
>
>
>
> Why not just keep it at MUST so that you don’t pollute the internets.
>
>
>
> We will end up having to filter for it anyway as always but it seems 
> foolhardy and unpleasant to intentionally weaken the language.
>
>
>
> Your new hotness belongs in your controlled domain. If you are going 
> to try and force it onto networks you don’t control then it’s not 
> going to work and you will end up having to tunnel it anyways.
>
>
>
> Why is this so hard to understand?
>
>
>
> On 22 Jul 2021, at 15:09, Giuseppe Fioccola 
> <giuseppe.fioccola@huawei.com>
> wrote:
>
> 
>
> Hi Erik,
>
> Thanks for the input.
>
> I tend to agree that the condition “MUST” can be changed to “SHOULD”. 
> I can address your comments in the -08 version.
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
> *From:* Erik Kline <ek.ietf@gmail.com>
> *Sent:* Wednesday, July 21, 2021 11:15 PM
> *To:* Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
> *Cc:* Stewart Bryant <stewart.bryant@gmail.com>; Christopher Wood < 
> caw@heapingbits.net>; Yoshifumi Nishida <nsd.ietf@gmail.com>; 
> 6man@ietf.org; draft-ietf-6man-ipv6-alt-mark.all@ietf.org
> *Subject:* Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
>
>
>
> Giuseppe,
>
>
>
> I think in S2.1 "MUST NOT" be used outside a "controlled domain" is 
> perhaps a bit too strong.  Similarly in S6, "MUST be applied 
> in...controlled domains" might be moderated down to "SHOULD only be 
> applied...".
>
>
>
> I'll note that it is possible for an AH option to be used to ensure 
> the DstOpt variant is unmodified en route, and these two in 
> conjunction can be used wherever desired to send such packets outside 
> the given domain (subject, of course, to all the middlebox 
> interference any such packet would inevitably receive -- but that's a separate issue).
>
>
>
> On Tue, Jun 22, 2021 at 11:27 AM Giuseppe Fioccola < 
> giuseppe.fioccola@huawei.com> wrote:
>
> Dear Stewart, Christopher, Yoshi, All, Please note that I just 
> submitted a new version of the draft. It has been thoroughly reviewed 
> to address the comments received during the Last Call