RE: rfc4941bis: On the use of multiple addresses

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 31 January 2020 15:45 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 E3A01120103 for <ipv6@ietfa.amsl.com>; Fri, 31 Jan 2020 07:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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=Z1rLo5IJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IGkkVEE6
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 G98ptdGI0qxh for <ipv6@ietfa.amsl.com>; Fri, 31 Jan 2020 07:45:51 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBDD1200FD for <6man@ietf.org>; Fri, 31 Jan 2020 07:45:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30060; q=dns/txt; s=iport; t=1580485550; x=1581695150; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VpJWciu4YoIY+8A06Nlw7oBUgk+xQquWTvCgeTBMvEI=; b=Z1rLo5IJpxYcKRZkvhe0ySLL7FKM4kFn8VIJVBUs2VzejzDS03rnQLNo WOZRvdTRwvVBV1FCZAT2MaioY4B9mSezqbXu4NhiDSae0S5SK6A0HNFlq n/1/3rLZzCaEgDoDSlPQYW89P0Hq4V3drAgcj2mSkXLDRN6DmyFKrowNc g=;
IronPort-PHdr: =?us-ascii?q?9a23=3ArYX4hhMGPR2xGTOoT4cl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSFAAKSzRe/5JdJa1lHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUvJCwFbA9JIAQLFxOEFINGA4p0gl+YD4FCgRADVAkBAQEMAQEYAQo?= =?us-ascii?q?KAgEBg0CBAAIXghkkOBMCAw0BAQQBAQECAQUEbYU3DIVmAQEBAQMBARARChM?= =?us-ascii?q?BASwLAQ8CAQgRBAEBIQcDAgICJQsUCQgCBAENBQgagwWBfU0DLgECDKJBAoE?= =?us-ascii?q?5iGJ1gTKCfwEBBYUOGIIMAwaBOIlXgkkagUE/gRFHgU5QLj6CZAEBAgGBOg4?= =?us-ascii?q?aKwmCWjKCLI1hB4JuhWCJeI82CoI7h0WFR4lOmwWOYIhnkjECBAIEBQIOAQE?= =?us-ascii?q?FgWkigVhwFTuCbFAYDY4dCQMXg1CFFIU/dAKBJ4pegkIBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,386,1574121600"; d="scan'208,217";a="712056668"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2020 15:45:49 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 00VFjnWf009011 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jan 2020 15:45:49 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 09:45:49 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 09:45:48 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 Jan 2020 09:45:48 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oJqGutZ5MzI5UsjYEoZlbzctD0b+AV4lid0W9Xq2eDolsZQ8X0MCK3odVHnFPFj0iSYaWfiDLInOdUANTQJc1I0uw3nY+z4q2r1+5GqTdIiQ0xSATEjcs+/QFW0qGFaCHjPzjzfCXNAiuOe6eVLMzLHMocBd011zbwQ3ku7JjVli0zi29tWccLyjUKoCbCKFG2sva/ZetZ0tnPeDXK0tSk5YSt/cBcXostmm/O/szdYm+/BGMz8sX6VLutOkGOQSp3zMJ6d6S9CsDAPwQgBcHYaQyzWZnyEE/KTYTzQATX6yMf6sgwZMZxBtm67AdVB5S0SqyihTRFyzS6DUm4o0Jg==
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=VpJWciu4YoIY+8A06Nlw7oBUgk+xQquWTvCgeTBMvEI=; b=nQzhCHvVLGcnkx/Ajd6xCJxm5AmSANA+Sm/j+/VvvBQuqNHqZfUMcT7jbk6jxHri5nUK3erLwMhkh6yo64y25o0YLYQQTSWWYASJZsQaVsOhcJbtoiPJB6hXusdEZOcPYgUxGIaELklUPht94XGIXhYrZkD90fHES3rk4LSH5gBWkJHeSp4xvP3RG80gOKWKKvz0+Qtme9iS0Z80CfwMNk7YcscrsMyLzzuxve/R1cR4gc6pCCjejsGaeHoN48uKaYAF98l2o8Ou3ouZQ8YOvqqmDAAD7NgxX34DXB2LeL7CTCVpYxPFcZOqpek5IkF48lV68drm2osQ6AB2JY0ipg==
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=VpJWciu4YoIY+8A06Nlw7oBUgk+xQquWTvCgeTBMvEI=; b=IGkkVEE6hIQ/zWo6TLCYuaDDXv8RmX2JDTp0w2hFLIETyGH4J3wWusPTvCCwF5gRtHkLk58414uEKUtbs5TZr3u/Y2qDtu84zrbXJIXX2BZMHH87YL1nKTMc8wz8y6uN6mPDQ3pSTkfee0eFo2KnPv5imsxpzwxB+pecZPC0/DI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3775.namprd11.prod.outlook.com (20.178.253.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Fri, 31 Jan 2020 15:45:47 +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 15:45:47 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, 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+RBv0lxkeXKgD6FuAgABhIZ2AAJ/wYA==
Date: Fri, 31 Jan 2020 15:45:31 +0000
Deferred-Delivery: Fri, 31 Jan 2020 15:45:00 +0000
Message-ID: <MN2PR11MB356557B63CD56C5BC86653BDD8070@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <4c7c16fd-ddef-eec0-d34e-29e91df6ce25@si6networks.com>, <CAKD1Yr1-xNPPs9obsGnn28fU15NQ85NuXwTppCkF60twdKGMgw@mail.gmail.com> <4C2E5A52-3D97-4445-B5E1-69703D402E49@cisco.com>
In-Reply-To: <4C2E5A52-3D97-4445-B5E1-69703D402E49@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:41e7:7725:e525:b2e8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e1dacfd2-ecef-4b2a-b37d-08d7a664a426
x-ms-traffictypediagnostic: MN2PR11MB3775:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB3775BC0258969E81BB1576BDD8070@MN2PR11MB3775.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 029976C540
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(366004)(39860400002)(136003)(189003)(199004)(7696005)(55016002)(110136005)(9686003)(66946007)(54906003)(66574012)(2906002)(76116006)(8676002)(52536014)(5660300002)(66476007)(66556008)(64756008)(66446008)(81166006)(53546011)(6506007)(81156014)(8936002)(186003)(316002)(966005)(86362001)(33656002)(71200400001)(6666004)(478600001)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3775; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: nLFNeC74R52jJ4DXTUB7Gky+ovXlIrbSDo/zUTV5u208XkjfWyz3xynW2Tj2YFqJ+zGiUAOvl+R+LGh6pafNUY38pZ0EXUbQWz5SA5mFaBOG8gzGMSEMFY1ckl9NOee2fPDEl5isGzDqow007jtvZTSkncthKqoM+lU9qtTFLHhn95JtOQo8ZybhAVvPqPNjI+4kcoRjuhvVX1fdsKs0MkqSQF+BmJU3JUugWPTHQK4Frtj/2p8QjphNhfA3MrRNAE0bVIiQZ2Bx3x0hUd8WupWFNleLhhcj2yNhV09kevZnJr/BvQe+o4mIyU90YprlBGttWKc/aSFhNZPRdSsTZ293yhT5U2Oifxz8M+E8bffnrI9Bh2ER5HgRsBvcw1W7zcbZ92RLCsWOYFBrWrfWSVuryvWNxrZPupVyGSrvgxiG+I6MDIJQkY+MsPFIEHn1WuYSIffPIvwAzEnfVwcIjHBHB0OCe0UqWNzviby1uxqvpScg15z2gPb13o0zIoxDZtMt42mTHF4koneHNPfYFQ==
x-ms-exchange-antispam-messagedata: SljQbpUG64kQfE4W9QVExu7HtpB008mlO9HGaSGZRfMsnKdoUj31jTRklaQgcpqkpMndwd3WyVyQCddAfUFdG43pyvNvX0N8w9r8F7MQAyYEbA655ppTMXqKFIw4wSvefPPRhVze24M57XTnBB6+J8Oe2uyHwOoT3mKuBx5uH5yvcxhHZa+eS11Jgt55limgeOvvI8HWY343vK91W3myug==
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356557B63CD56C5BC86653BDD8070MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e1dacfd2-ecef-4b2a-b37d-08d7a664a426
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 15:45:47.5395 (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: rmX6reSDSRymod/+gYg8uWovpV/L3vYJSmJ+Ki9ig++kyObXj70Hg3EKbKJh7yQOdISisZ1w3tVTBuojmieCPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3775
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/94m1uybkkSkNlBUNzeXgcp-xTrk>
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 15:45:54 -0000

My words below can be misinterpreted, and I apologize. I’m sure that SAVI went through due review process.

I’m just disappointed that the Security Considerations do not mention the need for the SAVI node to protect itself against DoS attacks, which is what SEC_DIR asked us to do with RFC 8505, and what we did when implementing it.

Quoting RFC 8505

The registration mechanism may be used by a rogue node to attack the
   6LR or 6LBR with a denial-of-service attack against the registry.  It
   may also happen that the registry of a 6LR or 6LBR is saturated and
   cannot take any more registrations; this scenario effectively denies
   the requesting node the capability to use a new address.  In order to
   alleviate those concerns, (1) Section 5.2<https://tools.ietf.org/html/rfc8505#section-5.2> provides a sequence counter
   that keeps incrementing to detect and clean up stale registration
   information and that contributes to defeat replay attacks and
   (2) Section 5.7<https://tools.ietf.org/html/rfc8505#section-5.7> provides a number of recommendations that ensure that
   a stale registration is removed as soon as possible from the 6LR
   and 6LBR.


Sorry for that,

Pascal


From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 31 janvier 2020 07:06
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Cc: Fernando Gont <fgont@si6networks.com>om>; 6man@ietf.org
Subject: Re: rfc4941bis: On the use of multiple addresses

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<mailto: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<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------