Re: [v6ops] Enterprise policies: :WAS Implementation Status of PREF64

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 30 September 2021 20:56 UTC

Return-Path: <pthubert@cisco.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 B51173A11F3 for <v6ops@ietfa.amsl.com>; Thu, 30 Sep 2021 13:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.595
X-Spam-Level:
X-Spam-Status: No, score=-9.595 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y/1dZI6s; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cunXS9sP
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 CSvfpsd7QP_b for <v6ops@ietfa.amsl.com>; Thu, 30 Sep 2021 13:55:59 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36743A11F2 for <v6ops@ietf.org>; Thu, 30 Sep 2021 13:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69767; q=dns/txt; s=iport; t=1633035358; x=1634244958; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7wIcyO8JpGc6LM5xvIYS86kYjVGqmUrSazeBeLySV4M=; b=Y/1dZI6szP40L+p8yX4kkPVE38odfR0SLP9du6y12XjZ949Wf/0nUxFD nE2ya39C8UuxtGSF0xExoB+TnKN7NkwqbOj+CZy6mMu7YEGIGMLf8EmdL tYK2izfcPyaYm8PUHca4+sBbvTyC/C+Xn04fBwA7tZgkXm9ZKL6bAoP4W I=;
IronPort-PHdr: A9a23:M0XQvRKqzvJrHDL4W9mcuXkyDhhOgF28FgIY7p0hhPRFdaHwt5jhPUmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBXhMIk4MaygonBsPWBUD/K/jlKSc9GZcKWFps5XruN09TFY73bEHTpXvn6zkUF13/OAN5K/6zFJTVipG81vu5/NvYZAAb7Ac=
IronPort-Data: A9a23:ZonWo64rHRzKABfTGKUNMAxRtPfFchMFZxGqfqrLsTDasY5as4F+vjQeW2CBa/uJYGegKdgjbd6y9UIBv8eBmoJhHAo5qH9hZn8b8sCt6fZ1gavT04J+FiBIJa5ex512huLocYZkExcwmj/3auK49SgnjfnSLlbBILes1h5ZFFcMpBgJ0XqPq8Zh6mJZqYDR7zGl4LsekOWHULOR4AOYB0pPg061RLyDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/0vD9BsrT9iiiLu+KAsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNBMi+7iB3R9zx14M1RtYG6RB01FqbNg+8aFRJfFkmSOIUXoeOZfSDv7Z37I0ruNiGEL+9VJEYpMItNpr57DGVJ8/NeIzcIRhyGjvi9hrO2Vucqgd4sROH1YoQHoVlhwC3XS/E8TvjrRLrH4/dU0TM3gM8IFvHbD/f1wxIHgA/oeRZDPBIcD4gz2b3ujXjkeDoeo1WQzZfbKlP7lGRZuIUB+vKPEjBSefhoow==
IronPort-HdrOrdr: A9a23:v9uQmq1kLMZ/yzAHR2YdQwqjBRByeYIsimQD101hICG9Lfb4qyn+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NaZLUjbUQ6TTL2KgrGSuAEIdxeOk9K1kJ0QD5SWa+eATWSS7/yKmjVQeuxIqLLsnczY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKHPz3LsimxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlul9yZbdwkK7aYp8GDDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4oow3TX+0OVjbZaKvq/VQMO0aeSAZER4YDxSiIbToBOArXqDzmISFXWqlLdOX0Vmg7fIBej8AveSIrCNWgH4w4rv/METvMfgHBQ4e2UmZg7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuJYO5gLZvt3+9Kq1wVh4SKbpXZ9VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06GlODTlIZssKY3jBKlDQhpnFoi/A3jzMF7tYwWpNE7+PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVbHMX6UI17gCKYbUki956Lf8fEw/qWnaZYIxJw9lNDIV05Zr3c7fwb0BciHzPRwg1jwqaWGLH3QI+RlltZEU5HHNc/W2By4OSYTepGb0oci6+XgKoKOBK4=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A8CQAxI1Zh/5ldJa1agmKBITAjBigHd1oTJDEChEWDSAOFOYgIA4ETjmcYileBLoElA08FCwEBAQ0BASoBDAoEAQGEfQIXgigCJTUIDgECBAEBARIBAQUBAQECAQYEgREThTsBBQIlDYZCAQEBAQMBARAICR0BASoCCAMBDwIBCBEEAQEhAQYDAgICJQsUCQgBAQQOBRkCBAOCTwGBflcDLwEOpkgBgToCih96gTGBAYIIAQEGBASBNgETQUaCORiCNQMGgTqDAIJ2VEkBAQKDaFmCLSccgUlEgRQBJwwQgWZKNz6CYwEBAgGBGg0OCgY+BwmCYjeCLolmAQIBKj4XHw4DEBcLEhsDCA4CIToFGwoMCQYjAggKAwQVEAEEFwgQBgEKAgSRch0ZA4MOiHM5jRKRB4EaCoMvikOUIAUsg2eLaoZFkHc0jyeTEZNCJwQEFIRtAgQCBAUCDgEBBoFiATk5DYETcBU7KgGCPlEZD4M6hESGKQUWgQQBDoI9hRSFSnQCCysCBgEKAQEDCY1IgkUBAQ
X-IronPort-AV: E=Sophos;i="5.85,336,1624320000"; d="scan'208,217";a="914640849"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Sep 2021 20:55:56 +0000
Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 18UKtuNa010116 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 30 Sep 2021 20:55:56 GMT
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 30 Sep 2021 15:55:56 -0500
Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 30 Sep 2021 15:55:56 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 30 Sep 2021 16:55:55 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BtWkIrHGaeIx6XUON6CMQ54TOL58+n1ZS2Toyo7JzLoqNFExefKQ+TQr3bhpwnOMMpOc/4kLqL559rC4FMUxadMmCWTP+SD4QoC0EtAR3Q4iq9+E6hPSlnwoOhythIB7282QfHzs6kTDnzvjktesQaWltiRhSfU8IxUug8M5UoQmmzzcNC9Sx+B3+wzcbXGZFI4f4nImt74Qm+C4r/FyquvVZDfaxXp03Nt79YadQDL3EWTBIciecZSgqy9FllLeg3th+Hj7Mlu3CoeQNpTqJs8FNSppZfny0EOiciqsS9WFtAHbVKwTI0y6ffGZtG0ME5nD+PtD4PE2QxP6W5zAcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7wIcyO8JpGc6LM5xvIYS86kYjVGqmUrSazeBeLySV4M=; b=ax/ETbrDF/OSOuxAd1n5fGgV/R9HpmXbR3kYimM1SI/yv5d99nbXwEDG/V9SF1schReINGG/9BAxRO3iYzkJ+MHvP/HhPZ1hsYaqYPYSmGwGotRcK9Gt2EfYSJiVFEXq+jON6aUA3d/TiaIRnDkoSMMXnbLmjSpEY3Jbh5BmYkCQw4HAP6GWo4q8AkXazA+jJoWrY3MP7HUTvG3uNsJUGE7VFs1DW+wccAp4lPjBx7zK59JEIngeUBbgRyQPQ47WlPfnFcwT5oWwD/+sqGeu17Gen53hCVIRSaXiHvp0FTafAbcVuIJvRO6CRLXDWKTeKKMlGRmRXI/zAF2vEtgY9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7wIcyO8JpGc6LM5xvIYS86kYjVGqmUrSazeBeLySV4M=; b=cunXS9sPhhfmOt8WGRj+auiBc4gcSSTqx8AtBxiNap0z1trCTz5f3TQCPDfwopzd1vOEcoy62gWp54++mpXtews/eTz0MsFJ9Qgm1OXOyt/qNittxibrk5Zp/wDz6mGwK+EQNPMquvc62kANHYs+s5JnCSU1GU6260w0lCFmhmw=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1888.namprd11.prod.outlook.com (2603:10b6:300:10e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Thu, 30 Sep 2021 20:55:54 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1493:cc59:eb78:7302]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1493:cc59:eb78:7302%7]) with mapi id 15.20.4566.015; Thu, 30 Sep 2021 20:55:54 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Owen DeLong <owen=40delong.com@dmarc.ietf.org>
CC: Owen DeLong <owen@delong.com>, v6ops list <v6ops@ietf.org>
Thread-Topic: [v6ops] Enterprise policies: :WAS Implementation Status of PREF64
Thread-Index: Ade2F2i+DqEMOmUbSsmK+MQXRJC8GQADbr4AAAYaxbo=
Date: Thu, 30 Sep 2021 20:55:53 +0000
Message-ID: <843153CC-DC05-4594-A22F-83E7A866C2A2@cisco.com>
References: <CO1PR11MB48819C4DC3C8C17C975E9EC2D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com> <5778D865-D4B1-48DD-8B68-51710735437C@delong.com>
In-Reply-To: <5778D865-D4B1-48DD-8B68-51710735437C@delong.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: delong.com; dkim=none (message not signed) header.d=none;delong.com; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 827255e8-0c67-4200-e46a-08d98454b18b
x-ms-traffictypediagnostic: MWHPR11MB1888:
x-microsoft-antispam-prvs: <MWHPR11MB1888E39718BB6A458ED4C363D8AA9@MWHPR11MB1888.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Jhr7epOXg6fEljSm82PyT5KJACxvjo6RStvmRZvPJf+pJgzF5eLXe78NhUbAzAT4g0lGyjUEd4/oVpIDQrtdbeVVcJ+uVoSmVyUYA48SrjQ7s3kq9FWxDRVh5sg5L7sNQNdLBtnRj05pORIifOzqdc8msEuAiLPEhCa2+IQCHBPw5h00HY+vj+TTCj3YuVV1Hj3xLBjM0J0N4N5aLSUSgkKLWriB4cstO7alcoJ9VNoVyVYNqyY0WYi8XTrIA5wHhrcgajnLCljt4YmhDqk5ulBc8HKOsWg2+7H4ajgIYOZdhvo7ntU7B7y0YYCIEaYInvyrKqJOOiadZsYVtV/N3QL2KS1lXUlgFprjnnNaCtwTT86kjhon+C2ZjJCjAYyf4He22Iu5zhre01qFN00Pf29Pne8l5W3XWFovaummwTRwfhiiChOvpUye5RBnNbSUNC3EFLxFF9JmkeQqwmepse2RVs6bT5WQLN2gNsAw3X4JGhl+qqKH9PRcsds6HXXsWmTMfe44uipnnX8JoDqntT/jya7HwrEWD9k/f5HnHQ6sJ1NKacc0EdVduBHjLE+KpscxBaYeOUuVG6K1O3YENVt0oWNXpja6dIzgnvaftbXW8+jvT3hq8SG9hquKwBxfbXj4UYDuBm/XCAXKp9lRT/MMLQXCDuJtf6G+5A4yC/S/E4WbUON+NHD1kJDsx6iML9R9sdsD4/n3jMovvVn5VVQZm8XSgm1K6wL5DVHnGl1NsBjg1cGXeLsMwipqXxXklp5DNbaWqIPqhrF7JRe/Wr0IN8F7hdBo0dp1VRr2s0TcnOM00G6HJjfBZpHTm7Y8UlpVvQTOgleLSOYGCMSlZ9yPQCumviZCfFjvhfXDGyc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(6486002)(508600001)(316002)(38100700002)(33656002)(5660300002)(6506007)(8936002)(6512007)(2616005)(30864003)(4326008)(76116006)(186003)(66574015)(54906003)(122000001)(53546011)(166002)(83380400001)(66946007)(38070700005)(66446008)(36756003)(64756008)(66476007)(86362001)(66556008)(966005)(71200400001)(8676002)(2906002)(91956017)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 03oMqv6QDibR9TIjploJv/0xxcfQyg6oWGmgFpwxguT2AhEmXbLaLLoS6orq9DylMc3VvZCSSX/jXo45IL1j9L1PVWL9Lkgib8Tm/Ux8R6C8jK+I0oGfK2QEw43q4b3G0xvcGUyn+ox8AEchjxY71FxXY4EA1cGcpY5jK/6iCOaX6FhhKF3dZhU7PgobAkS2dyOhc4yeiEaepl10HRlN4y76F0hlFVkVd9bi2HZ8ZNOCWeE/lJKlRr1QSXvOczLZYufybrwJHruWxvXrmJ8Rx22MEEuRkpRLcHR9PUh4y+vp6xZtH6t1VKkbw16c1hfiKXTjxY2Emwq+8uTmDCApbKMddto5k+p7j2KGoD/wyxGjV4vNZpD5/lO3WsdS3AZE+3Uf3z58aH0m9JV8EpoArYJtIUFTW7dFi2v0GkT6P1Z1x41X7cIXSjexBZYe2/v383vWekYV+JUf0cF7HkKoyNAIlG+Z3Sc2RXQOST8zNupgZfPoLWhay9MbcoKf2i1lBGIP+2NGX1Tiu2ozXnDvXxzbuU7GPhH5lU6ucaa66STxfkA48wzhMz68uklpxWdOd38T/UI5HuWXsDAK/Cd/gXVKW2Zs/j0IC0u/f8zQPurCJAGMmT6kYCfg5y/mhCRY/3xA70xotBJ6Ej7HSzFtx4O54VV3qj87bPnd0e+z7QT4XQRFzAjI9dP7eeyuCVXZHMz0K3VyI1zQyR/+4wGKDCk7cEVRoGtK2DRTyMKVJ9c/EzZ55QreMbjWd8mZDMK6TtdWPPSjnWjDeCwg+fIrzzW8UtBDbfDXsJtON9fvTk8o5OPG4BC9H0+Lr2U3fIZshoVYWc+Dz6T0MGvAISRj8eELSNgRwEe1GqpTKVfXyY74FtRSnLN3birxnvf6bct2dkMqRp5kF0iHpAz3uRnMWpHAPjzEn+ZLS2S9UBcT3hWTdloD5mLVpPSKU4wAefagcQJ9LM4v6N1BSRGyX9FHnNVvt1eHw3SczhnwMwvexOyOv8Jfbt1rgzB4Tb/bkIoHaKnCkVFRJhaJBO3zGijEYMr3mlwxlXBJ/GIDN4OYIahAOD8sH/7aRTjFGR2ET9FGuHsooVfrUeRlUDElAYt/EXumLjTcJS1X0C5zdJcvKtyz+4SAF1ECfdO6Er83Dt/gPF+dkVKtJDSQ8QrsCPkUcU1ELwFZ/TAyNTdmDkDzwhEZ2wTvYVVgvQ2+5a66qJF0anA3Wg2DKEEzoRnLOGbAOc/86LUe2989qDLXuPYvpkE+Ay4T7G7OHkfP7yRw/bFjQRbw+YotCcbTVjz3d7Pvt1rjCLhaGTMvOXmGiWOzW0jLMPtKafWjtss9M1bXOBE2jCSdfkOJt3d71KIUR8t3Hbpnq7azOfrJSpzeRFptN4CdAqfg99gaWW5chXqAqYwP
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_843153CCDC054594A22F83E7A866C2A2ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 827255e8-0c67-4200-e46a-08d98454b18b
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2021 20:55:53.7812 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FZgMqJwZlwr6b90xKO1CeQlXPBF6UaCxC7KcCpNeO0g22Wpnri1SIPu5hBNQ2I8/5p/EEBZ8EBd8m5UiMRSX1w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1888
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Boold2XtosCzYGmJofJfzDxdXOk>
Subject: Re: [v6ops] Enterprise policies: :WAS Implementation Status of PREF64
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: Thu, 30 Sep 2021 20:56:05 -0000

Hello Owen



Le 30 sept. 2021 à 20:05, Owen DeLong <owen=40delong.com@dmarc.ietf.org> a écrit :



On Sep 30, 2021, at 10:22 , Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> wrote:

Hello Owen

We cannot stay too vague here. Maybe there are things where we can progress. Can we elaborate on which policies you have in mind?

I’m not the enterprises that have the policies, and you’re not going to like some of them, but examples of things clients have told me:

1. There shall be no address assignment on the LAN except by our DHCP server.
2. The switch shall not pass any packet into the network with a source address that does not correspond to the DHCP address(es)
issued to the host on that port and correlated with its authenticated MAC address in the 802.1x authentication process.
3. Any host on the network must only use addresses which we can correlate with a particular user through the DHCP and 802.1x logs.
4. Hosts cannot just choose addresses, they must be assigned by the DHCP server.

etc.

There are a number of policies that can still be enforced even with AAC, like the number of addresses per device. Some of us hate that it happens, but in some environments there’s an infrastructure cost to each address (like an auth flow, a TCAM entry, whatever) so there are cases where it is bounded by policy, want it or not, and already today. Say that number is 1, and say that ND pushes that information to the DHCP server to feed the existing tools, does that solve your use case? Or is it like the policy interested in defining a specific (semantic) IID for each node?

Most of the clients I’ve encountered that are truly resistant fall more towards the latter.

Do I read that they forge the IID for the node by policy?


However, there have been some cases where the former might be a workable solution if hosts could be reliably prevented from using addresses not associated with the authenticated {user, host} that made it through the 802.1x process and any other NAC in question.


Sure. We do that in FHS. The trouble is that snooping is not reliable enough, mostly in the case of SLAAC. This is why stateful AAC is the only viable way in enterprise and for the lack of it the policy becomes DHCP only.


Notes:

I’m not calling people names, they are my customers. I’m trying (very hard) to make their life simpler, and I’m not trying to influence their policies. It is their job to decide what the best tool is for their case.  I see a hammer and a plier in the 25-years old  toolbox, and I can see many shapes of screws invented since for modern networks. You can manage something with both tools but that’s far from ideal, and not an incentive to go v6.

The name calling comment was more oriented towards some of the other participants in this thread.

I’m not saying that I’m happy with the lack of DHCPv6 in Android. I think DHCP was the natural starting point in the evolution towards IPv6 in enterprise and I buy the argument that it is probably an impediment to the adoption of IPv6 in that space. I just think that ultimately it should phase out and be replaced by Ole’s universal RA and Stateful ND. Because that can bring more control and visibility –  screwdrivers in the tool box.

I’m not 100% convinced of this, but I”m open to being won over. Part of it is that I am very resistant to complicating RA and SLAAC because there are devices that are resource and memory constrained that don’t need to fit into these policy-constrained networks and don’t need all the code to handle every option ever invented plus those that weren’t invented at the time the device was deployed. This constraint doesn’t apply to android, but squeezing v6 into an AT328P or even an ESP12F, for example, is hard enough as it is, without making RA gain all the complexities of DHCPv6.

Our main disagreement. Look at where stateful ND comes from. 6LoWPAN. Because SLAAC was too complicated (cache management) and too resource consuming (broadcast and asynchronous operations that keep the end device awake at night).

The first standard to adopt RFC 9010 is Wi-Sun. For the LFNs, those devices that are so tiny that they sleep more than cats and live on a coin battery for years. Those devices implement RFC 8505. That’s the only ND that was feasible for them.

 Bottom line is that Stateful ND is in fact much simpler to implement than SLAAC. Your power meter at home may actually implement it and you don’t know. They are deployed by millions in North America.

The reason for not adding the screwdriver in the tool box is not complexity, it’s ignorance (what’s that strange tool for?).



The nice thing about having SLAAC and DHCPv6 available is that SLAAC (as is) is a really good option for most networks and most devices and it’s extremely lightweight and relatively easy to implement, while DHCPv6 through the M+O flags in RA can provide a more robust more managed configuration environment for more full-featured hosts that can support it readily.

That was the binary truth of Y2K when networks where of either of 2 colors. This does not apply to IoT or cloud networks.


The problem (which is almost uniquely android) here is that we have a vendor of full-featured hosts that doesn’t want to play nice i the sandbox and wants to act like a resource-constrained node that can’t do DHCPv6  _AND_ put these devices in general purpose networks with users on the devices facing full featured UIs without these additional configuration constraints, information, etc.

Said otherwise: An enterprise that decided for DHCP must keep IPv4 alive for Android users. This means that they cannot go IPv6 only. And I’ve read on the NANOG woes thread that dual stack is the worst possible outcome for OPEX.  Conclusion?




Note that it’s not DHCP or stateful ND. The node must register an address that was obtained from DHCP in stateful ND, like it must do DAD for it today. Just that you do not waste one second in the process, and do not broadcast over the whole enterprise Wi-Fi domain. The cool thing is  that the host can also unregister it when it ceases to use the address and free network resources.

As I said, I’m not opposed to this being an additional tool administrators can choose from, but I thin it is somewhat orthogonal to whether or not IA_NA is a requirement for enterprise deployment that just can’t be obviated, at least not today. The only drawback that concerns me with it is the added complexity to SLALAC for resource constrained hosts.

I see that from the other end. Real constrained devices cannot do SLAAC. But they can do DHCP.  And they prefer stateful ND, that’s a lot more bang for the buck (e..g., RFC9010 or RFC 8929).


Stateful AAC provides full visibility and protection, a lot more than what we have today, even with DHCP. E.g.,  DHCP can only be snooped by the on path switches, the other just learn indirect information from ND multicast. There is little to no control over the DHCP state and possibly a lot of stale state, think about the impact to MAC rotation for instance. There is no notion of having more than one address with different roles, privacy requirements, and life cycles. DHCP does not help distinguish mobility vs. duplication / attack. It does not pub/sub the binding to external services like proxy, routing, or LISP.

All valid criticisms and I’d personally like to see those features added to DHCP.

Not me.

I’d rather have a modern ND that can do pub sub of what it sees to all interested protocols with a simple and agnostic interface to the host.  See it as a Kafka.

RFC 8505 gives you address assignment, DAD, and BCE in one round trip and no multicast. It is stimulated by the host which can go back to sleep with the knowledge that it’s address will not be stolen or impersonated. Bang for the buck.

I m not saying that the current stacks should not implement DHCP. I’m saying that it should move to the back end out of sight as it is replaced by a more valuable interface.


Think about the things we can do with stateful ND AAC:

- provide full visibility to the network administrator
- secure the address ownership with RFC 8928
- rotate MAC and IP for privacy with no stale state and/or silent node
- synchronize a state in the L3switch/AP/router for ND proxy (RFC 8929) and routing (RFC 9010, RIFT<https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift>, eVPN<https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling>)

All of these come at a cost of complexity in the ND process which I’m not convinced is a benefit.

The biggest operational complexity is probably to deal with broadcast, which places a high constraint on how a subnet can be assembled.

Not everyone is a CCIE, and I’ve seen people in industrial plants suffering trial and failures deploying simple IPv4 and discovering the impact of broadcast over 100 nodes per broadcast domain. The sort of failure that you observe when the network injects jitter in control loop operations. Ugly. They now have explicit rule of thumb and network designs to prevent that.

They should never have had to worry about that. It’s entirely our fault.

It’s all due to the reactive behavior of ARP. ND is worse because it’s not only lookup, it’s also DAD, times N addresses. Not really an incentive to let SLAAC on in the enterprise is it?

With stateful ND we deploy subnets with thousands of nodes on linkspeeds expressed in Kbps, and there’s no CCIE involved in the deployment. They are live. Now.


SLAAC/DHCP separation was intentional in order to provide both a low-cost light-weight auto configuration protocol that could be used by resource constrained hosts that were not on policy-sensitive networks _AND_ a full-featured dynamic host configuration capability that was heavier and better suited to such policy-sensitive environments.

Unfortunately, M-bit enforcement is a gaping hole here since it depends on voluntary compliance by host developers, thus can’t be depended on for enforcement.


It can be enforced at the first hop (snooping) switch. But having to snoop and destroy protocol elements in a middle box is the clear indication that the protocol is not doing its job.

There should be an explicit contract between the host and the network that this host can use this address in association with this MAC, that the network will guarantee the ownership for a duration that is part of the negotiation. Seems complicated but really is not.

 I’m aware of customers with policy similar to what you suggested. But the ones I know do not care what the IID is. I believe that their policy would be satisfied if we do 1x and AAC for one address and then push the address to DHCP from the router on behalf of the host.

Further, we have a device manufacturer that is unrepentantly determined to produce general purpose devices that (currently) need to he able to be used on policy-sensitive networks and only support the required policy regime and configuration options in IPv4. They have refused to implement the necessary capabilities in IPv6.

The situation with Android is related but not exactly the subject of my question. Please assume that I regret this situation and that you do not need to convince me.

 I wish to understand if we can envision to push DHCP out of sight of the end device in your use cases, not now but if / when stateful ND gets in mainstream stacks.

If so we may have a path to resolve the situation. Convincing people to take that path is another story…

Keep safe;

Pascal


Owen


Keep safe;

Pascal

From: Owen DeLong <owen=40delong.com@dmarc.ietf.org<mailto:owen=40delong.com@dmarc.ietf.org>>
Sent: jeudi 30 septembre 2021 17:59
To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Cc: Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>; v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>>
Subject: Re: [v6ops] Implementation Status of PREF64




On Sep 30, 2021, at 03:14 , Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> wrote:

I have the same perception of that thread and the IPv6 woes one on NANOG as you do. For one thing we cannot extract DHCPv6 brutally as a rotten tooth.
We need to understand what it’s used for and provide a better replacement that will slowly take over. SLAAC cannot be that. The problem of SLAAC is not the AAC piece, it’s the SL. SL lacks observability, and that’s what prevent it from being a replacement to the database that the operators and network managers need, e.g., for forensics.

It’s both, actually. The AAC side interferes with certain aspects of policy enforcement that are important in some environments.


I think there’s a golden path where DHCP is pushed deeper in the infra so that at first it is no more visible to the end device but still available to the operations that require it, and then we move on to the point where it becomes fully redundant and ceases to exist, by the user’s own decision, on his own agenda.

This is the problem, right here… There are networks where the administrators do NOT WANT this to be up to the user. They want control over certain policy aspects on their network. You are free to call them whatever names you want, but their networks are part of the target audience for IPv6 and they aren’t going to deploy it unless they have at least equivalent policy enforcement tools to what they have in IPv4 and they’re going to have to be implemented in a way that provides at least some familiarity or clear roadmap of the transition.

Today, that’s IA_NA combined with other enforcement mechanisms such as NAC providing dynamic switch port ACLs. Yes, 802.1x is an L2 protocol, but contrary to earlier statements, the NAC server can pull data from multiple sources and push an ACL onto the switch port that will limit the client(s) attached to that port to the addresses and capabilities permitted by the NAC policy configured (including limiting the L3 addresses that can be forwarded to the one(s) assigned by the DHCPv6 server, if desired).

If you’ve got a better idea for enterprise-level policy enforcement than IA_NA and IA_PD (where permitted), by all means, present it.

If not, then yeah, support for IA_NA is essential to forward progress in the enterprise.

Owen

_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops