[Roll] Terminating IP in IP at the 6LR

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 29 August 2019 16:10 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9012097B for <roll@ietfa.amsl.com>; Thu, 29 Aug 2019 09:10:31 -0700 (PDT)
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=bTbtpYcx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OtYlRFwT
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 XUFRjVk3JAOJ for <roll@ietfa.amsl.com>; Thu, 29 Aug 2019 09:10:30 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB73120979 for <roll@ietf.org>; Thu, 29 Aug 2019 09:10:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4233; q=dns/txt; s=iport; t=1567095030; x=1568304630; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=eWDpKn+tYYh6oJqd3ieG2hZ27zmipOQbuhneVaHOT7Q=; b=bTbtpYcxjTcwYLpYbi0k0K64OtCeGfRwu2Ne9ZRd0tQLbLe3sEjMcvyN A2VYX5pP/Ihi/AuJEZ39k8Tt+XALvZlaKpNd0EslLV7ZMfJVY6lNWnV+x DsdJHChLufqzJHrMEC7UDdgDeUcW/aWWp50OP1M7QYigPqQcW3JyqIJdg c=;
IronPort-PHdr: 9a23:7Rh1fhD/W9nRuB1PKZ2ZUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHwQAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CRBwBk+Gdd/4MNJK1mHAEBAQQBAQcEAQGBZ4FFUAOBQyAECyqHaAOKcU2CD5dqglIDVAkBAQEMAQEtAgEBgUuBdAF/AoJZIzgTAgMIAQEEAQEBAgEGBG2FLgyFSgEBFy4BATgLBgEZBAEBAWAdCQEEEwgahGsDHQECoCcCgTiIYYIlgnwBAQWFDBiCFgmBNIt3GIFAP4ERRoIehRQegzuCJoxHiHqWSwkCgh6LdYh5mF2mJgIEAgQFAg4BAQWBZyGBWHAVgyeCQoNyilNygSmOTgEB
X-IronPort-AV: E=Sophos;i="5.64,444,1559520000"; d="scan'208";a="535611432"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 16:10:29 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x7TGATS0025831 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 29 Aug 2019 16:10:29 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 11:10:28 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 12:10:27 -0400
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 11:10:27 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FKBmHzNJ2ti66+9DHYM75XvcaYuBbdQT5wGALp3WsQsrMfDuds5kGCzrus5PlF6mQFSL6yfGfXHr5iEqPU5di6NRB5bE5pxorSlAVqG+cfXs5syOrtNlDgca9AXNl2Y/yQ6TvkSdf07H7DSaDCJVPCcIZL9xWUAQIdD5wU2nD1A28PEqcUqxZReqEfzt03Ktvi81GYu7NhFQJ/01ry5+Jw5F54RrTaPnopngT391sl1E3CTo6gxdGGJabUX1kRXiZdZ2PnwPuMkZGp5K4uT1AygcUkOYINuEK5vKT3jLHBQzF1dS1srsbXA3e7Jt6t66TCRU+HScbTc0Q0EnRseoLg==
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=Vfl6rWPaXBnYySG87Yu4ogX+ltzqT9H1cSeKqf6oXoU=; b=AXDDw7uXLa3Pr2teIEb61MVP5TpHSng37kOK3dWB2RSGCgkvuE0Pd6zo1O6a0bk72CkvCA1fBaTxl9wYPul/TtQ/a/AQMR5i/LdLPa15R4hYwOkadK1gUhV7+SEWrjxRx58IcxhI29OxCxLxrl6U7lU4rbw1oUi1TIquTp/C4cP774uhYrAsBVCUL+7usoXXCsqEgSbQS0yZjpvfoRdBKymJj1M2gLny6xH3Qi0KPIRGxroXZu/ZRF9d64vprEL1tOBiO8m3OEhottPFgOtk6RaRAbZHmFyICpKmTrRERqPx5cpkF9ZL+zxTeCcIGulRuZWlMvbxvm0JFArHsQV/Cw==
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=Vfl6rWPaXBnYySG87Yu4ogX+ltzqT9H1cSeKqf6oXoU=; b=OtYlRFwTToalwiYmmseDmaru+qoPjgaQ1RzocvYL9xacmHjGTyD5SVyA21BO/iqKn+NVskknodin5Tz9GH7aJ6yW9XtPVhd5UswtryXKIPINY3oHYFN1jxvyxFGnLhXQLvUi4IboyEKt6Gkr69m2LpzvHw07ZG5Rzt1cXhi9Ktw=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3824.namprd11.prod.outlook.com (20.178.254.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.19; Thu, 29 Aug 2019 16:10:26 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 16:10:26 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: Terminating IP in IP at the 6LR
Thread-Index: AdVehAsg/WVZd5TGTJ+FXlMdHYDzxg==
Date: Thu, 29 Aug 2019 16:10:00 +0000
Deferred-Delivery: Thu, 29 Aug 2019 16:09:52 +0000
Message-ID: <MN2PR11MB35652A2373C92CB1C57975EAD8A20@MN2PR11MB3565.namprd11.prod.outlook.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:8170:98a7:7988:d19d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1efc3927-7d1f-4cbf-a2e8-08d72c9b678b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3824;
x-ms-traffictypediagnostic: MN2PR11MB3824:
x-microsoft-antispam-prvs: <MN2PR11MB3824836F06F12CC82C569EC9D8A20@MN2PR11MB3824.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0144B30E41
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(13464003)(189003)(199004)(46003)(71200400001)(71190400001)(256004)(14444005)(9686003)(99286004)(25786009)(66574012)(102836004)(74316002)(305945005)(6116002)(6666004)(86362001)(66946007)(478600001)(53936002)(55016002)(6436002)(486006)(316002)(5660300002)(66446008)(8676002)(66476007)(7736002)(64756008)(76116006)(14454004)(476003)(81156014)(6506007)(6916009)(81166006)(53546011)(7696005)(8936002)(186003)(2906002)(66556008)(52536014)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3824; 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-message-info: 6TdNHQbKrBnzAgKh7rjzN2kdn61zTBgLplrzWtHhZoFl11m7mamYWTmTQfW1rqX80Zj3FqFcOEvF0zsyAEN9wzFsNOavvt/5oNWD84ehpBXf+rDG1eG1yI8D1rOr6QyQ8Mukv/Eyk6j5fpVrdtNEgEnn1Tiu+eG79XgKAYwz2tlCwkAvuSUvuRQ5/9LybB+LkD5dXa0XyrtQ7/bUeLxw/LW+hzdFe03Rxa0EtiIcbVWDfKitU2ZGd0tCDa+oJGtSTslA9KnvMJcw5cfLjfeISh/4XFjHVY3yOUW67Bso7ndUI0IinDSGITYnL0OFrqY2C1GKRT3/TXI6lWhnxbgL6E/lboiDQQVDNwOiExpJi96S6SQO5FDPCz0RY01Jkzof+LSlHsglKE/XQk62JZugx2bNdaz6W334PQy/mTHaT/Y=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1efc3927-7d1f-4cbf-a2e8-08d72c9b678b
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 16:10:26.3312 (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: hNp3ZUzPaT5ZLBD0FETVUltgSovtNme3mgnNUvITVYmhmItRWT+d/Mcs0n/0oHGI6hU9zCESWRf7Qk/gwrjz5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3824
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/DWO5dpW5DKZHetubd8bYfncItGE>
Subject: [Roll] Terminating IP in IP at the 6LR
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2019 16:10:32 -0000

Makes sense Michael:

 we cannot expect that by default the RUL is able to terminate IP in IP. So unless configured otherwise we must terminate at the 6LR. Which is only known in non storing. So we need non storing signaling for 'E' routes. OK...
about updating usefrplinfo, unsure. If you think so you have the pen. I 'dd like to publish this early next week if that's OK for you.

I added text:

"
6.2.3.  Support of IPv6 Encapsulation

   A RUL may support IPv6-in-IPv6 decapsulation when it is the
   destination of the outer header but that is not assumed by [RFC8504].
   If the 6LN is a RUL, it may be able to drop the inner packet if it is
   not the destination of the inner header.  By default the IP-in-IP
   tunnel should terminate at the parent 6LR so supporting this
   capability in a RUL is secondary.
"

Which seeds in the new text below:

"
6.2.  External Routes and RPL Artifacts

   RPL data packets are often encapsulated using IP-in-IP and in Non-
   Storing Mode, packets going down will carry an SRH as well.  RPL data
   packets also typically carry a Hop-by-Hop Header to transport a RPL
   Packet Information (RPI) [RFC6550].  These additional headers are
   called RPL artifacts.  When IP-in-IP is used and the outer headers
   terminate at a 6LR down the path (see Figure 7 for the format in
   Storing Mode), then the 6LR decapsulates the IP-in-IP and the packet
   that is forwarded to the external destination is free of RPL
   artifacts.

   IP-in-IP to the 6LR MUST be used if the final destination cannot
   handle or ignore the RPL artifacts or the way they are compressed
   [RFC8138].  An External route indicates by default a node or a prefix
   that is not known to handle or ignore the RPL artifacts.  The
   RECOMMENDED behaviour when using IP-in-IP to an External route is
   that the outer headers terminate at the 6LR that injected the
   External route.  Non-Storing Mode signaling MUST be used to inject
   External routes to the Root in order to advertise the 6LR that is
   associated to a RUL.

   In order to save the IP-in-IP encapsulation and to support Storing
   Mode of operation, it is preferred that the 6LN can ignore an RPI and
   consume a routing header in both the native and [RFC8138]-compressed
   forms.  In order to enable IP-in-IP to a 6LN in Non-Storing Mode, it
   is also of interest that the 6LN supports decapsulating IP-in-IP in
   both forms.
"


All the best,

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: jeudi 29 août 2019 15:24
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] UNaware leaves
> 
> 
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>     >> >   This specification does not alter the operation of a 6LoWPAN ND-
>     >> >   compliant 6LN, which is expected to operate as follows:
>     >>
>     >> really... I thought that we were making it able to deal with RPL artifacts,
> as
>     >> specified in section 6!!!
> 
>     > Which is as should already be. That's not even 6LoWPAN ND, that's IPv6
> if you look at it.
> 
> Well, I tried to push for 6man's host requirements bis (RFC8504) to include
> processing of IP(dst=me)IP(dst=me) to be included, but it was a hard push,
> and I didn't have the energy.
> 
> So, we are making requirements which go beyond 8504.
> 
>     >> What is the specific signal that the 6LR can use to know that the host is
> an RAN
>     >> rather than a RUL?
> 
>     > Yes we have text, maybe even repeated with terminology; e.g.,
> 
>     > "
>     > The 6LR advertises the
>     > Registered Address in DAO messages, if and only if it is triggered by
>     > an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a
>     > RUL.  If the 'R' flag is not set, then the Registering Node is
>     > expected to be a RAN that handles the reachability of the Registered
>     > Address by itself.
>     > "
> 
> got it.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-