[v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 26 October 2020 10:03 UTC

Return-Path: <vasilenko.eduard@huawei.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 E919E3A1A56 for <v6ops@ietfa.amsl.com>; Mon, 26 Oct 2020 03:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 Xj88hBbbVvPi for <v6ops@ietfa.amsl.com>; Mon, 26 Oct 2020 03:03:30 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917A93A1A58 for <v6ops@ietf.org>; Mon, 26 Oct 2020 03:03:30 -0700 (PDT)
Received: from lhreml736-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8FEDBD5F909FB0AEF4B4 for <v6ops@ietf.org>; Mon, 26 Oct 2020 10:03:27 +0000 (GMT)
Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml736-chm.china.huawei.com (10.201.108.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 10:03:27 +0000
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 13:03:26 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 26 Oct 2020 13:03:26 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: IPv6 Operations <v6ops@ietf.org>
Thread-Topic: draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance
Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlw==
Date: Mon, 26 Oct 2020 10:03:26 +0000
Message-ID: <54abce3e4abc449fa896a6ae318a6128@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.192.169]
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ioVBAGX29gXGiC9zTLIanDUOG-E>
Subject: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance
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: Mon, 26 Oct 2020 10:03:35 -0000

Hi Fernando,
Sorry. I have spotted it just now.
It does not make sense to mention 802.1x as the reason for renumbering problem.
802.1x operates strictly on L2. Switch port is blocked for any other traffic at that time.
If authentication would fail then port could be put into "guest" VLAN.
But important point to mention that 802.1x supplicant has finished its job - it could not activate authentication again. It needs same event like link up/down or admin push. Enterprises do not manage clients in such a dynamic way.
The decision to move host from "guest" to some other VLAN is not related to 802.1x, not at all. It could be probably configuration push to switch (NetConf?).
If such bad practice would happen then it would break connectivity for IPv4 too - DHCP would not have any information that VLAN has been changes.
Hence, it does not matter what mechanism has been used initially to put host into "guest" VLAN. It could be something other than 802.1x.
It is important that some automation tool could break IP connectivity shifting hosts between VLANs.
It is not possible to develop the resolution on IPv4, but it is possible to invent additional protection on IPv6.
The reason is still valid - precautions make sense to have. But it has nothing to do with 802.1x. It is general VLAN shuffling.
Eduard
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of IETF Secretariat
> Sent: 22 октября 2020 г. 17:29
> To: owen@delong.com; draft-ietf-v6ops-slaac-renum@ietf.org;
> v6ops@ietf.org; warren@kumari.net; v6ops-chairs@ietf.org; Owen DeLong
> <owen@delong.com>
> Subject: [v6ops] Datatracker State Update Notice: <draft-ietf-v6ops-slaac-
> renum-04.txt>
> 
> IESG state changed:
> 
> New State: IESG Evaluation::Revised I-D Needed
> 
> (The previous state was IESG Evaluation)
> 
> 
> Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-
> renum/
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops