Re: rfc4941bis: On the use of multiple addresses

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 31 January 2020 06:05 UTC

Return-Path: <pthubert@cisco.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 8955912008A for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2020 22:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.497
X-Spam-Level:
X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=U3aMBz1F; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xt1NfitY
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 r3KKLsFhIWJS for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2020 22:05:57 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC4612006D for <6man@ietf.org>; Thu, 30 Jan 2020 22:05:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13557; q=dns/txt; s=iport; t=1580450757; x=1581660357; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gzkXsT/ane7xXLburyHFuxCIU7qRunByzNZYP0gvZ7Y=; b=U3aMBz1F+WsM6UBYx1FqQ1rJ8niQJxCYOg69NCJWGoQS7Ri7mEwxeQYE ROk+OfSPWUjpcgZAskiagt7fsvJmv/A0fS1uj4lbcHmy0l0yqL6gRf8Pw uABOjBobI2KRHiDlwrx5LPc4sum+EugbnrW/Ny3WBcpN//B8CrSSJhKNa I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AomAoCxTnX8MbNwYg48edisgwvdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKDQC2wjNe/4gNJK1lHgELHIFwC4F?= =?us-ascii?q?UJCwFbFggBAsqhBSDRgOKdYI6k1KEYoJSA1QJAQEBDAEBGAEKCgIBAYNAgQA?= =?us-ascii?q?CF4IXJDcGDgIDDQEBBAEBAQIBBQRthTcMhV8CAQMBARARHQEBLAsBDwIBCD8?= =?us-ascii?q?DAgICJQsUEQIEDgUigwQBgX1NAy4BAgyhMwKBOYhidYEygn8BAQWCRIJEGII?= =?us-ascii?q?MAwaBOIwgGoFBP4ERJwwUgh4uPoJkAQECgTtTgmMygiyNYQeCboVgiXaPNQq?= =?us-ascii?q?CO5Y9G5sFqXYCBAIEBQIOAQEFgWgjgVhwFTsqAYJBUBgNjh0JAxeDUIUUhT9?= =?us-ascii?q?0AoEniluCQgEB?=
X-IronPort-AV: E=Sophos;i="5.70,384,1574121600"; d="scan'208,217";a="713297154"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2020 06:05:56 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00V65uH3030948 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jan 2020 06:05:56 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 00:05:55 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 01:05:54 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 Jan 2020 00:05:54 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dIDGzP4TKW2xeH9ocrwKnTkIySjYCddx5xCNpxPHkN6FYboZk+CMrwYGRT33cmHmpZgMVr/B6+YDVpynTHaE0uMh1xE/5WeFMfPdU7qvS76R/AHXblWWX1LJz7nukuaXaqnT8gWIdMtI5R31q+zVHDZ2OdGQZxVPz/0IUzf2hCxRtLJidp4WwHPuCywmBmgp5O4Ze7FtDqNAsO1fA2ypXc9jEiTbDzXQROWEZz3HPieRcz43tanKf6UUSISdtINOSNLD8/txJ0mqttM2mY6qeo9p71ccD5CSQyo6HX1ey6dghUy95h0e45yciREeo0zMxhxFrnAZV/sca9mgLmnBlg==
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-SenderADCheck; bh=gzkXsT/ane7xXLburyHFuxCIU7qRunByzNZYP0gvZ7Y=; b=YwrgMbGLlYHnEkYN8BMEtl/qmAe40IjYBcRUN8ULVJWPXZ8eu3GrpW3cYH3WKMZXWkasuTZv5dhgtgB+jVEnec309mnhgiqjXXRcynQhgnVWcCijdFdk3NULVJvXEb6SQvw4zne5+Aclb4qUjnTHHwtpHXtr4idwRGlto26gDrylK7lOrO1x+B4uXcO5A4aFGHOZzTTY2haz6v67q5tlzDX6Ra3icEaHr80+1LSvwTT7LKQt6yjahjzZmJC4tY4NTZ25ltHlfBf6pkUCTy6KOwgdpBpy0hx7CCS5oTN1xJsUrOxFRsdtDX79F+4R7aajd9NRqIOtn+yEIZtQBTNqBA==
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=gzkXsT/ane7xXLburyHFuxCIU7qRunByzNZYP0gvZ7Y=; b=Xt1NfitYCisay5uz5mveeQOGHj7OQo1DUkV7aay7LpwcCLFW4iYoOU9XeGb+WUs5BkSXG1hHr8C7YaL7w+8l0/iMWyKjLOE8iw+wataCwZMyPM+1L6TK2AqHiLEsrfOX4KUpmlGgTDiU3nh8eDF3AaRoY8+SwJeJNeI6czt1trs=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4175.namprd11.prod.outlook.com (10.255.181.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Fri, 31 Jan 2020 06:05:53 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 06:05:53 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
CC: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>
Subject: Re: rfc4941bis: On the use of multiple addresses
Thread-Topic: rfc4941bis: On the use of multiple addresses
Thread-Index: AQHV18BicfZTGkG8AEi+RBv0lxkeXKgD6FuAgABhIZ0=
Date: Fri, 31 Jan 2020 06:05:53 +0000
Message-ID: <4C2E5A52-3D97-4445-B5E1-69703D402E49@cisco.com>
References: <4c7c16fd-ddef-eec0-d34e-29e91df6ce25@si6networks.com>, <CAKD1Yr1-xNPPs9obsGnn28fU15NQ85NuXwTppCkF60twdKGMgw@mail.gmail.com>
In-Reply-To: <CAKD1Yr1-xNPPs9obsGnn28fU15NQ85NuXwTppCkF60twdKGMgw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:f53e:6bc5:e32:609f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0d0204f0-8462-43be-6f25-08d7a613a12e
x-ms-traffictypediagnostic: MN2PR11MB4175:
x-microsoft-antispam-prvs: <MN2PR11MB41755551657C59B33D86B932D8070@MN2PR11MB4175.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 029976C540
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(396003)(346002)(136003)(366004)(199004)(189003)(81166006)(8936002)(5660300002)(6506007)(53546011)(186003)(81156014)(8676002)(2906002)(316002)(6512007)(6486002)(86362001)(54906003)(4326008)(2616005)(66556008)(66476007)(66946007)(91956017)(76116006)(33656002)(966005)(66446008)(64756008)(66574012)(71200400001)(478600001)(36756003)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4175; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ksRySmj8qENfQ1wR/1x8WqgsxFKEM/RcddEjP6BPbacpWtV+Eef0y3rhr/7Y8WiNGycAAkTyYO2BUqsYUZLEisln1QyOpa3LEetsXqGwGTfvj/P8WqUBUNMV9xEo2kEMMxFSbC8IBiqNDayvp97gz7DW8LIT6JWd+giv3z10ha5Wf+EEnXGzO5akIMhJJnNpDHRpInAz/EKkvY7n5I9hSMn0gvqgsdcjSwL6V/wYYoPkFomPslkhV28aIN6blFZ4fZ4Nv8kisUjgHp2KQNzBy5Q34W/Nqy9SF0g8WYdYrJYTJdFOlJENBCMxNKafyBFta5PyJlJOK9oIhZe3ckzHPtLCNwhcepgFwwDutI9LX55/uYvaMxwGS/IJir1RaLAYvW+4pnUgs73Riy1L4chwOo0Hhrm+5Y/Vxb5HPiBX58vrEmmp7QAo0nZ4cLA7aXlP5UvH8HkgYWQ46hy/njkb/ek3S1AU5qLKpnE1SM4EDcuXX0prwpur83Jk2sh+LK5hA+7TDaZ43Np/f6237NzpoSt9JhvpXh7i80dMhzxJMcKcL1ytoDNLV5P+y10W3Ze9
x-ms-exchange-antispam-messagedata: vG8ew3IWx+Dh0tgg9CAm7BsxVw2Z/26O0XiqMQJnnbeAyJJrdVOOF6+4Fkr9DvL8c7a2kB3JhBwOI2xe/HFFSxfQfs4PDAcCSrQyb1F9IixIngRKc8CxrKIxrmPk913pmBWAzFoCW4AFbMY+t/rhsCaTaMaRTkaz888JvVCz83Lb1tysJWxS+Wcn892iaWxU5rlii98SijOmUKXwdG4oKQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_4C2E5A523D974445B5E169703D402E49ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d0204f0-8462-43be-6f25-08d7a613a12e
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 06:05:53.3709 (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: IuSDaw98xWNt7JHoqrpAzUz6MEmHA8pLYGl/bzuAZkAQhZNEhtI9HRNAQFvhBu5pLCpvbduTBnWn4474j5r5Fg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4175
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ki-dSJOyL4fCCxOrPde6436cFn4>
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: Fri, 31 Jan 2020 06:05:59 -0000

This is playing ostrich again.

 Limiting the amount of addresses is an obvious implication of SAVI in a managed network. When we did RFC 8505 the Sec-Dir review insisted to have text  to protect against DOS attacks. The SAVI draft did not go through that full cycle and is not complete to that regard. So I think the original text was a lot better.

And the size of the cache is mostly irrelevant to the ND churn these days. When addresses are dropping for the lack of rmemory there’s really an issue.  What’s relevant is the amount of new addresses joining the network, the number of nodes in the network that need to resolve it, and what nodes do when they sleep cycle or roam.

We measured (on the wire) several hundred multicast per second in average over 90 minutes during a keynote with a large audience. /64 per host is indeed tempting in such environment. But it boils down to IPv4 with 8 bytes addresses. We can do better.

Regards,

Pascal

Le 31 janv. 2020 à 01:18, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> a écrit :


I don't think the two RFC citations are appropriate. RFC 6583 is about the size of subnets, not about the number of hosts per subnet. RFC 7039 is about the SAVI framework, and I don't think there's anything in there about limiting the number of bindings. I also can't find anything in that document that talks about "enforcing port security that may enforce a limit on the maximum number of configured addresses per host". SAVI is a security mechanism to prevent spoofing, not a mechanism to limit the number of addresses.

draft-ietf-mboned-ieee802-mcast-problems is relevant in the sense that more addresses on the link create more neighbour discovery traffic. So how about rewording to the following?

=====
Network deployments are currently recommended to provide multiple IPv6 addresses from each prefix to general-purpose hosts. In some scenarios, use of a large number of IPv6 addresses may have negative implications on network devices that permanently maintain forwarding entries for all neighbour caches (e.g., [RFC7039]). Additionally, concurrent active use of multiple IPv6 addresses will increase neighbour discovery traffic if neighbour caches in network devices are not large enough to store all addresses on the link. This can impact performance and energy efficiency on networks on which multicast is expensive (e.g. [draft-ietf-mboned-ieee802-mcast-problems]).
=====

On Fri, Jan 31, 2020 at 7:54 AM Fernando Gont <fgont@si6networks.com<mailto:fgont@si6networks.com>> wrote:
Folks,

Based on the recent discussion regarding the possible impact of the use
of multiple addresses, I suggest we include the following text in
Section 4 of rfc4941bis:

"Network deployments are currently recommended to provide multiple IPv6
addresses from each prefix to general-purpose hosts. However, in some
scenarios, use of a large number of IPv6 addresses may have negative
implications on some network devices (e.g. [RFC6583]), exacerbate other
operational problems (e.g. [draft-ietf-mboned-ieee802-mcast-problems])
and/or may lead to traffic employing these addresses being dropped by
devices that enforcing port security that may enforce a limit on the
maximum number of configured addresses per host (e.g. [RFC7039]). A
discussion on possible approaches to allow for unconstrained use of IPv6
addresses can be found in [RFC7934]"

Thoughts?

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<mailto:fgont@si6networks.com>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------