RE: rfc4941bis: Invalid addresses used by ongoing sessions

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 11 February 2020 07:54 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 7EB6F1200FD for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 23:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=i2gfXWVG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zpbMcpx1
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 xwaCRpCTKo9R for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 23:54:09 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFB1120044 for <6man@ietf.org>; Mon, 10 Feb 2020 23:54:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6294; q=dns/txt; s=iport; t=1581407648; x=1582617248; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hiOb9IkMmxCA4JkXnMSG66uFM/sQtXHTuPMTHAk8A+E=; b=i2gfXWVGLy68HngEp6b+wkwGzoHWkYh0eoxWUheojQRtMgIUMQQfZh/I xupuN45w2ozfL1FaBisLAbmBBOfboE0CgNhMVDZh6CMtIqYFfyQ82clzP DoguD/3R/AA/o4hM4R9IGeZydEYQfg/BS/bPbS8NqyqXAx8NXwiWZkzD+ 8=;
X-IPAS-Result: =?us-ascii?q?A0CRDACwXEJe/5ldJa1mHQEBAQkBEQUFAYF7gVRQBWxYI?= =?us-ascii?q?AQLKgqEC4NGA4sCToIRmBKBQoEQA1QJAQEBDAEBGAsKAgEBhEACF4IvJDgTA?= =?us-ascii?q?gMBAQEDAgMBAQEBBAEBAQIBBQRthTcMhWYBAQEEAQEQEREMAQEsDAsEAgEID?= =?us-ascii?q?gMEAQEBAgImAgICJQsVCAgCBAESCBMHgwWCSgMuAQIBC542AoE5iGJ1gTKCf?= =?us-ascii?q?wEBBYUFGIIMAwaBDiqFHwyGeBqBQT+BWIIeLj6CZAEBA4FIHIMOMoIsjWaCd?= =?us-ascii?q?Y87j2AKgjqHTI8bkVKJPY5kiGySOQIEAgQFAg4BAQWBaSKBWHAVO4JsUBgNj?= =?us-ascii?q?h2Dc4UUhT4BdAKBJ4p8LIEHAYEPAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AGztE9Rbfj8JXgAouFG6Wd8f/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtLwSI8Ge/5jMTBB?= =?us-ascii?q?jzcBFtKLSpSKjVicn/l/io/IHeaBlJgzz7Zq5uKBKxrkPascxEyYBjMa02jB?= =?us-ascii?q?DOpzNEfOlNjWVvORqfkg396cG54JMGkWxItugk9tJcXKmyZKk+QbFCRDQhKH?= =?us-ascii?q?wupcA=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.70,428,1574121600"; d="scan'208";a="411585990"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Feb 2020 07:54:06 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 01B7s5oM016480 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2020 07:54:05 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Feb 2020 01:54:05 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Feb 2020 01:54:04 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 11 Feb 2020 01:54:04 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pygk3kyomDhPqmQiSt2OWuzFfeWKZn5gAIyTrzrmcHaCKwaPDqEDg9t1DZ9NZZ9JxF4PEkqZaCWfQjCIn4NduvPdaLuhpVp4VGlx0FkqDX19MZuCNG2ZUjzcttxsSSa/MvKGjrc2e8ZdRoy/B04tPiklK5MkL0ET6JPy6g28jUxHD8zUP5aSxoGUq4u8/yXhl5FlGATDBLNyKeQNbecDBIBYIOR56OpfmrE07SUx/FzzQYGncLtMEFCNaU0joRhMitmkG6E2709UkNIvL/wJuZKmKnvleU5mG/HXl+erElm4BT+SRpLyxYgFd4dVuVceaJJRXftx3mDTJyYFlys9KQ==
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=hiOb9IkMmxCA4JkXnMSG66uFM/sQtXHTuPMTHAk8A+E=; b=iRCUub4US3EttXokrq8dFWkrNxxSAGITKFKmPzqAsQfHhysjgft3YhQKd30Aqrxf5d27W3Nkmg7SWzC14Bjzq8syRpk8Gamux6wac1JmGZyDW5c4316Zg8Ti03wYxbP96ZbUYfoNAX2xPXcpfUNsJv7+V/ET/pWnxB93wKD1erjBxXGY+K0yq2NZi1Fhf+56SIzvydaIQcw4E0P3lFX4IRIfd12V26Imxq/Wr960RMeLyoe4vgV53TjMLdIoNKEpJmXXTa0Gc411tOeFca1Q2CUv9pI3v4F16NTYJ3fwDDf2+pibPJwWqu7+9I97Xi+0mI31BKe5g8ndQ4JzqPVOFw==
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=hiOb9IkMmxCA4JkXnMSG66uFM/sQtXHTuPMTHAk8A+E=; b=zpbMcpx1WLI1u9MPcq9SM6XzxfQiY52JxClx+dPV52h913JGHlpI+Ou01VQ3hP93eMNmZbjtQbwYXTid+0d/CNwCzT1RWARtEijnCed023up2+aHTAB5qtgfYyYWU8i+IkD69J23JB8kSTByZW0exIHCGi2qItWY8jv4wuXp6oI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3631.namprd11.prod.outlook.com (20.178.251.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.29; Tue, 11 Feb 2020 07:54:03 +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.2707.030; Tue, 11 Feb 2020 07:54:03 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: rfc4941bis: Invalid addresses used by ongoing sessions
Thread-Topic: rfc4941bis: Invalid addresses used by ongoing sessions
Thread-Index: AQHV4C1O01Vv4WJubkGLOQxbfxK/pagUmoBwgAAR+YCAAPHqMA==
Date: Tue, 11 Feb 2020 07:53:57 +0000
Deferred-Delivery: Tue, 11 Feb 2020 07:53:33 +0000
Message-ID: <MN2PR11MB3565EBF17C8A0FB579A4519CD8180@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <c6ba9a00-cb44-2022-5009-34211966518c@si6networks.com> <MN2PR11MB3565437F70601F5CE815DFC5D8190@MN2PR11MB3565.namprd11.prod.outlook.com> <9da7f50a-ef8b-9d4d-2e5d-134aa815659d@si6networks.com>
In-Reply-To: <9da7f50a-ef8b-9d4d-2e5d-134aa815659d@si6networks.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: [2.15.172.153]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6545945e-504a-4ff6-284d-08d7aec79011
x-ms-traffictypediagnostic: MN2PR11MB3631:
x-microsoft-antispam-prvs: <MN2PR11MB363177C54EC28996768B4D85D8180@MN2PR11MB3631.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(346002)(366004)(39860400002)(189003)(199004)(71200400001)(26005)(76116006)(66574012)(7696005)(6666004)(966005)(81156014)(8936002)(186003)(2906002)(66476007)(64756008)(66446008)(66946007)(66556008)(316002)(55016002)(5660300002)(110136005)(86362001)(81166006)(9686003)(53546011)(6506007)(33656002)(8676002)(52536014)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3631; 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: Ga0SnbiAdWrRYhxvRLHCXoiIhvWisRWmc6OirhedTgPxB+fRkfx1Aw/2YYg7Fb0msUhCipksE2pYSYAvYSK/YKBFri1WyWoF8ur5eZh5oklMsABBRKPRiIYtjvxneRV1ObkIdxJSfD5DksLuyRtPO/0v3kL5pGXmw3loQvKAJVeCLBQBEq8V+CUQ11K9BJ6l2T3mf7lwhLzOrDzW74iYmiqbdMR56d94e+l/Mc6lN3HlgkfbnFUY/dAHEf0DGfQCaIhr/h3g1q1nPvpbIcemEDtXQ4LnAtIqvrPKzCzBMT9cTrOCmTLsR5iQDxHhOQtdM8nyU4Z4PTe0fWgdqMLE9eg110MYMTapmid2GbpZ0TTimP045iJTO+D01hctvHdOg+3LwGzav5WULA2nFQ6YPmNMHH/yJ9Q8lRUlrhILp8B6DJ/pPichCEkoIt37BeRGt1KoJXLpUbRFz3j5cp8Eph5d3Nzr67HEx3gr6H/WFMdx3VUOwoncENuELGra90r/lXnj0zZnC4Zx4YTP7of27w==
x-ms-exchange-antispam-messagedata: 5Rt8fAsTDmfi2Q78cvCDrmWpIz3STvZiO7wS2Io7Yx3ANtirYbFS68n5bZpC+dgJ0sD2KA5ko6X4z0W8Ail9hcNCq53BS0m46CDWMLfIdvxysgd5ws+lLpyMSSOsdllbMYVJqOwt1CBbbm+ctdSC5A==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6545945e-504a-4ff6-284d-08d7aec79011
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2020 07:54:03.3953 (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: 1xWbGriJjaa74Q3HL9c93Oh/16GdQnnWPjVvLy9g8DzXPENXbjDwfQU76oRzkC3PRJvCt85S2TeAVO4Qom7QWw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3631
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kuZhUj1UfcoVyPCaBP7CYDPWyiU>
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: Tue, 11 Feb 2020 07:54:11 -0000

Hello Fernando;

There is a basic problem in the network probing if an address is still used by a host. Starting day 2, the host using default setting should start using a new address and conserve the older addresses in case there's an active connection. If the network probes the address to figure if it's still there, it actually revives it, meaning that in terms of LRU the old address becomes fresher for all participants, including the stack. 

This is just one of the side effects of not telling the network what's happening. The solution has to be holistic -include all parties, app,  net and stack - and cannot be based on snooping. 

I'd rather leave the text as is (2). It's wishful thinking but at least it's there. I'd prefer to move it to a problem statement or see a  solution draft.

Cheers;

Pascal

> -----Original Message-----
> From: Fernando Gont <fgont@si6networks.com>
> Sent: lundi 10 février 2020 18:21
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; 6man@ietf.org
> Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
> 
> Hello, Pascal,
> 
> Thanks for the input!
> 
> Now, back to the original question: Which of the options #1-#3 do you think we
> should pursue?
> 
> Thanks!
> 
> Cheers,
> Fernando
> 
> 
> 
> 
> On 10/2/20 13:20, Pascal Thubert (pthubert) wrote:
> > Hello Fernando
> >
> > The existence of the address impacts the application and the network. If the
> stack decides unilaterally to remove an address, it is impacting both the
> application and the network. The future work could include an API so that the
> application and the stack tell each other when an address is no more used or
> usable. It could also indicate a protocol for the stack to tell the network that an
> address is released so the network can make room in the NCE (in advance) and
> reduce the chances of overload.
> >
> > All the best
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Fernando Gont
> >> Sent: lundi 10 février 2020 10:14
> >> To: 6man@ietf.org
> >> Subject: rfc4941bis: Invalid addresses used by ongoing sessions
> >>
> >> Folks,
> >>
> >> As currently specified, temporary addresses are removed when they
> >> become invalid (i.e., the Valid Lifetime expires).
> >>
> >> Section 6 ("6.  Future Work") of the draft
> >> (https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-06.txt) still
> >> keeps the following text from RFC4941.
> >>
> >> 6.  Future Work
> >>
> >>    An implementation might want to keep track of which addresses are
> >>    being used by upper layers so as to be able to remove a deprecated
> >>    temporary address from internal data structures once no upper layer
> >>    protocols are using it (but not before).  This is in contrast to
> >>    current approaches where addresses are removed from an interface when
> >>    they become invalid [RFC4862], independent of whether or not upper
> >>    layer protocols are still using them.  For TCP connections, such
> >>    information is available in control blocks.  For UDP-based
> >>    applications, it may be the case that only the applications have
> >>    knowledge about what addresses are actually in use.  Consequently, an
> >>    implementation generally will need to use heuristics in deciding when
> >>    an address is no longer in use.
> >>
> >>
> >> I wonder if this text should be:
> >>
> >> 1) moved more into the body of the document and made a "MAY" (which
> >> for TCP is very straightforward),
> >>
> >> 2) Be left "as is", or,
> >>
> >> 3) Removed from the document
> >>
> >>
> >> The implications of #1 above is that it can't prevent long-lived
> >> connections that employ temporary addresses from being torn down, at
> >> the expense of possibly increasing the number of concurrent IPv6 addresses.
> >>
> >> Thoughts?
> >>
> >> Thanks!
> >>
> >> Cheers,
> >> --
> >> Fernando Gont
> >> SI6 Networks
> >> e-mail: fgont@si6networks.com
> >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >>
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> 
> 
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>