Re: [6lo] draft-ietf-6lo-fragment-recovery: What to do if hop limit is reached

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 06 November 2019 19:45 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2194120104 for <6lo@ietfa.amsl.com>; Wed, 6 Nov 2019 11:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=LK0MxfgG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=baJoeC88
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 i95FzDmqpv3U for <6lo@ietfa.amsl.com>; Wed, 6 Nov 2019 11:44:59 -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 35FE61200C7 for <6lo@ietf.org>; Wed, 6 Nov 2019 11:44:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9041; q=dns/txt; s=iport; t=1573069499; x=1574279099; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gACyAZEJ2tIwI8dR5/ivfLSCg8klY0ACdQAODpbAhmQ=; b=LK0MxfgGJcHGk1rZGQoNJaJ4wQaQWRPFheTJ61HY0nl5RrEFguWOTymj qjPU6iliJ68Vdfw6HSVINypvB4yx9XqR48c79/xd/DCaWE0RH0Ohw3ljy gvg/PkNslv0WDiUDEjT7FOD9VKuFfRzzcNCH0BniIW+JtQX/gL/XwYqFt w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AxykxYhAqg+hHLr6pZi/PUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjBQBlIsNd/4ENJK1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBfoFLUAVsWCAECyoKhB+DRgOLAIJekxyEYoJSA1QJAQE?= =?us-ascii?q?BDAEBGAEKCgIBAYNAgQACF4N3JDgTAgMBAwIDAgEBBAEBAQIBBQRthTcMhVI?= =?us-ascii?q?BAQECAQEBEBEdAQEsCwEECwIBCA4xAwICAiULFBECBA4FIoMAAYF5TQMOIAE?= =?us-ascii?q?CAQunEgKBOIhgdYEygn4BAQWBNAGBFII/GIIXAwaBNoUahnoYgUA/gREnH4F?= =?us-ascii?q?OUC4+gmIBAYEwC1OCYzKCLJAFhT+YQAqCJJU8FAeZbKgnAgQCBAUCDgEBBYF?= =?us-ascii?q?pIoFYcBU7KgGCQVARFIMGDBeDUIUUhT90gSiOI4EwAYEOAQE?=
X-IronPort-AV: E=Sophos;i="5.68,275,1569283200"; d="scan'208,217";a="374132963"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Nov 2019 19:44:54 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xA6Jis4v030934 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Nov 2019 19:44:54 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Nov 2019 13:44:53 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Nov 2019 13:44:50 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 6 Nov 2019 13:44:50 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m3uIPeib6B1vY1XQgQH58wfG1cqHY2jGUxuXNKdA7SMk76zytLK5182cLoCR0KyU4VzlVRG28mDAn3a/JJcdmepcc6GVwYkMbO9uvF/RmWPMgiU7N4E/F872f851c9iLU/fbxtKjhirTcPkKxteELrrVT5SJOKOrac9Xu+rfd0/vbUyhEaF1qgIv7KRHEYDu/wXyxNHjIuCRkhzQag1QcYc3FSjkmpQmxD3d51g/w27hO0HAeRg/SukfmeTVhFZXFt9NYgqm8bkcp8z+uSQeGCOvoRMp6V68h7oZCMB2pV7c2osctufeo/b3gOlF3tgLfeaArIFvIx4RJk476BDEqg==
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=gACyAZEJ2tIwI8dR5/ivfLSCg8klY0ACdQAODpbAhmQ=; b=Zo1pKnPoOiPQLdfQBlL2NdxrY31FUYxB16OwQ4q2mE53NFSA27bbm2I2DUoi9wF0kjSD+/OgacYrnifzil1WXxYpH2X/digWiUGcaXyYWFINZoZkMbNckSOBm4tX1bzPsT7nh0Cl/+NSt3dQgyzLr7P38QZ72xCFpfeKGyb+HRKMRiVUudeOa/M6wlfu3zSKp63OLT3FIb/8qWUf9thyrfxFtzem4MHYEjUUlESRVJtmeWjHHcXvuO38KARqKyklPX9gO/onJLvTb/lMYzIq5DdrT1kqea0/NkL28lmqbSP9O0i5YQCkf9nABvfqKvxBoNzcFgeOuNinKUeh8cQNPg==
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=gACyAZEJ2tIwI8dR5/ivfLSCg8klY0ACdQAODpbAhmQ=; b=baJoeC88Ksj/yG4SHRiILZRcgwkRkObVJM5SCt572GE/4dHgw6ugOZ4A8n3CPhHD1cIQ14WtzmuTa2k/EG+/1D+8Ia/UcA3ak5YCWdwaSCsY0a7HE6r+CSguHa/5e+HDoe/HmZ/JpKKqIJIaUvpjdBSNv/XqfalkTuZ/dVtiN0E=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3646.namprd11.prod.outlook.com (20.178.253.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Wed, 6 Nov 2019 19:44:49 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920%6]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 19:44:49 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Martine Lenders <m.lenders@fu-berlin.de>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] draft-ietf-6lo-fragment-recovery: What to do if hop limit is reached
Thread-Index: AQHVk8durppuNaJT1UOvL+OO+yKc0qd+Y+utgAAHjICAACJGcg==
Date: Wed, 6 Nov 2019 19:44:49 +0000
Message-ID: <E54FAAFC-75D3-44A2-A68E-BA2151E85161@cisco.com>
References: <CALHmdRw2G32snHE_-Ov6sS3i5JvgzcsTTT9iqapPFkUZS5n97A@mail.gmail.com> <1F7C5F4E-DD8A-44C2-A7DB-1D651A762150@cisco.com>, <CALHmdRyHdKa4o4FDJweZW414PLTfE-ZiQZHSSvW8j1f1s2Afdg@mail.gmail.com>
In-Reply-To: <CALHmdRyHdKa4o4FDJweZW414PLTfE-ZiQZHSSvW8j1f1s2Afdg@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: [93.158.31.251]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7134961c-f677-4ace-bbdd-08d762f1c917
x-ms-traffictypediagnostic: MN2PR11MB3646:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB364639DB5BF2C127FA5219A8D8790@MN2PR11MB3646.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(396003)(376002)(199004)(189003)(51444003)(36756003)(2906002)(6436002)(64756008)(66556008)(6116002)(316002)(256004)(99286004)(71190400001)(966005)(14444005)(4326008)(25786009)(33656002)(6916009)(66446008)(3846002)(486006)(11346002)(7736002)(446003)(14454004)(86362001)(236005)(66574012)(5660300002)(54896002)(2616005)(476003)(6246003)(76116006)(66476007)(478600001)(76176011)(102836004)(91956017)(66946007)(186003)(26005)(81166006)(81156014)(8936002)(8676002)(6506007)(6512007)(66066001)(229853002)(71200400001)(606006)(6486002)(6306002)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3646; 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: 8wMz0D6o1Tmw4zX2hG0zpfNltfUOX/rVM0z1jxGFoPYdhlJSyCd8tJMeEXsJbZ2SV6FT0Lof9FCiHJeiP0iZQ09CbD2P90IicZfQ7tiINNdY1NgrhbNalsQuLIzJFwb5bqxMo5DfldIUYGYYX5/gR50VnNuAhImaBEYPCVTzIgjJ1NphSq4KEpbIiipqjvsYv6A66/vSpM8jKnEl5kU6/p5Q7NBhFe37hcqOb4VRALh7DGJs/WBR6DL617UObdlFh+hTgCvBZ96xxrJjmmDyPOcLuEOrFqvoKgqRiE6xiUnaoajvEr3BSY5o+KyA2RB4JqA18HmAFaADYNFk7AZvSH49jCW2K8ym3Qk0+aODlNoaHfIN+yaIHH8CrCIDvhQPNZfmNeEcQP2IALtmLMpC2jSF5arFF/WgSMx3I6V5ynMCRg8GJj3nYg0VdCsGZJEmuiZKIIqhrXr9BwJxR+7zvpXfOV/HfiZVEWh8ltrzEhE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E54FAAFC75D344A2A68EBA2151E85161ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7134961c-f677-4ace-bbdd-08d762f1c917
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 19:44:49.3932 (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: /EVveMKoxxSionqrbSIXFcvUjyRTGOUDlvu83qgYpbPs1NpBwaixoc8pnwkwEcQKwbG/QnBNrwkW9dwqQecwrA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3646
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/xVatMB3fFYuaN0mYnKC_GA-UVTs>
Subject: Re: [6lo] draft-ietf-6lo-fragment-recovery: What to do if hop limit is reached
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 19:45:02 -0000

So you are sending the ICMP error with inside the uncompressed packet? Maybe it’s ok for hop count but what if the error is due to malformed/ unsupported form of compression? The sender may not recognize what it sent in the attempt of decompression that is returned. When you detect the error did you already loose track of the compressed packet? I thought you’d keep it to forward it because most times there’s no need to change the iphc piece.


Regards,

Pascal

Le 6 nov. 2019 à 18:42, Martine Lenders <m.lenders@fu-berlin.de> a écrit :


Hi Pascal,

Am Mi., 6. Nov. 2019 um 18:16 Uhr schrieb Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>:
Hello Martine

You did great ! Yes I think that
You should send back the beginning of the original fragment at least up to the HL in an icon error and then an  abort...

This is the generic problem with errors in 6LoWPAN HC networks . Should the ICMO contain the compressed or uncompressed?
To sort out the error which maybe with the compression I believe we must send back the compressed form in ICMP errors .

That is contrary to what I did and also seems to me way more complicated than they need to because:
a) IPHC (which isn't currently "aware" of ICMPv6 as it is not compressed) needs to parse through every intermediate non-compressed header at *every* hop (as the compression changes at every hop).
b) If you have a classic IPv6 interface running in tandem (e.g. the border router, but we also have use cases were people just have an Ethernet cable on a 6LN as well for diagnostics) you have to implement two kinds of ICMPv6 error messages: compressed and uncompressed.

So having them to have compressed (MUST) would add a lot of overhead.

Best regards,
Martine



Regards,

Pascal

> Le 5 nov. 2019 à 11:54, Martine Lenders <m.lenders@fu-berlin.de<mailto:m.lenders@fu-berlin.de>> a écrit :
>
> 
> Hello,
>
> I'm aware this is a corner case that usually should not happen in a properly configured WPAN, but what is an implementation of selective fragment recovery supposed to do, if hop-limit 0 is reached? With minimal forwarding I just reassembled it and handed it to IPv6 so it can send a ICMPv6 Time exceeded error message.. Should selective fragment recovery send an abort ACK in that case as well? Or just the abort ACK?
>
> Best regards,
> Martine
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org<mailto:6lo@ietf.org>
> https://www.ietf.org/mailman/listinfo/6lo