IETF Logo Mail Archive

Re: [Roll] [Anima] on the use of RPL without RPI (was Re: [6lo] Adaption of ROLL for mesh-under)

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 13 April 2017 21:31 UTC

Return-Path: <brian.e.carpenter@gmail.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 8D3FC1296B0; Thu, 13 Apr 2017 14:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 shPxCL3tlujz; Thu, 13 Apr 2017 14:31:54 -0700 (PDT)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB5F1294B2; Thu, 13 Apr 2017 14:31:54 -0700 (PDT)
Received: by mail-pg0-x230.google.com with SMTP id g2so35738417pge.3; Thu, 13 Apr 2017 14:31:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Dr4iqbuCM4nle96CYi7PzKKrTmPYx0IoURsHvcA1pF4=; b=uXPJJy1WFM+2hmxVUgQHxRY28+Qc6rOU7CekLEij4PRer+d3E7gWkejA2K5qBaN9+f EypGoB1HWEJvAoSjo3eppsoxrUV2qKebFy048+E3UIPQ8YGYNiI9YHnV7YsApVPV0u7T 4S93ATrBDjkfKas7aOer4yELS2Jn1jKapM0JW8Nfil8De5wsw36F+vRwjK8tiUcWVASx Y8oQ2foYnlyDtFh0Bp5FXi8bQEdm36YTSm5q54qFcKuUDhQy/43HqPFaOGU7wl+Yqet6 Xd+n1xN8VP+SEdA7dzNic6MMMUgLqJhEwoiN5acfBOydhHgeV2y+qSHrmbEPQqV+AcLs qoOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Dr4iqbuCM4nle96CYi7PzKKrTmPYx0IoURsHvcA1pF4=; b=fVNGCarfTA5afS4Xy3oHwGSgdwyFHFv87b5arHVmT05sKs96qRikVvrIkYJiTAqmmZ At+FpwtXTPyjy5uufRrd7Zp5syJFr8tSz8yeX84D+gQD4h4dAUv/eeMNV85eMoaRNjrb nHiS1VAPYl2MXEtN715C2rx8IvDZGAqtp4aRYSfC8B3HOI6pbdgHfsbJA2dInRqfyOPf ZBNZtLi7NT6rNCYJGi3FVbmsBg6m69zu2BiFgXW9FAyjCS47tchn7zGZBOO63kQ9wml/ 5F4sKr9scRu3ewspFrX7pPL2xVZhILF24nwt3SW+YclGr8OkVvEXm/jUyqRASYAuoomv oE1g==
X-Gm-Message-State: AN3rC/7qB8RXGEMeOsFNFH/xTatUWVkMcmnAl219EgUG4CfCnWJTSsPK I1Ajuec8YTrT5Q==
X-Received: by 10.99.215.85 with SMTP id w21mr4246788pgi.217.1492119113792; Thu, 13 Apr 2017 14:31:53 -0700 (PDT)
Received: from [192.168.178.26] ([118.149.101.64]) by smtp.gmail.com with ESMTPSA id 2sm44191853pfx.107.2017.04.13.14.31.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 14:31:52 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <1491971619970.42705@ssni.com> <CD3480AD-3934-4C9E-B6F3-E399A32BACC8@tzi.org> <1491974218584.69073@ssni.com> <ae35261f3dac4a9fa123f33610bb9805@XCH-RCD-001.cisco.com> <15236.1492095258@obiwan.sandelman.ca> <6ce1718ab83342bcad9c19d6d9e96935@XCH-RCD-001.cisco.com> <6577.1492101395@obiwan.sandelman.ca>
Cc: "roll@ietf.org" <roll@ietf.org>, "anima@ietf.org" <anima@ietf.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <07e8d178-0545-5fe1-75a6-ecad449565ae@gmail.com>
Date: Fri, 14 Apr 2017 09:31:56 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <6577.1492101395@obiwan.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/BMtbSY2Ks5gZoNZU0ZLhAHOoAdg>
Subject: Re: [Roll] [Anima] on the use of RPL without RPI (was Re: [6lo] Adaption of ROLL for mesh-under)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Apr 2017 21:31:56 -0000

On 14/04/2017 04:36, Michael Richardson wrote:
...
> I also think we could in light of rfc2460bis renegotiation, argue for
> insertion of RPI header by the ACP without IPIP encapsulation :-)

I wouldn't bet on that for a few more weeks yet. We do have a couple of
mitigations however:

1) Since the ACP is strictly using ULAs, we can assert that ACP packets
are not intended for the open Internet. It would in fact be tragic for
many reasons if an ACP packet "escaped".

2) Since the ACP will be based on IPsec/ESP, we can assert that breaking
IPsec/AUTH is not an issue.

However, we would also need a story on PMTUD within the ACP.

>     > So all in all, considering the hassle of updating silicon along the
>     > forwarding plane, I'd think that living without RPI is fine. Now if you
>     > tell me that it is always going through software that is easy to
>     > update, then why not?
> 
> I think that this is the case.

Updating the ACP code network-wide, in a large network, might not be so easy.
Ignorant question: what happens if only some RPL nodes support RPI?

   Brian

v2.23.0 | Report a Bug | By Email