Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 24 October 2019 09:21 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C779C1208A9 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 02:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 PvIgATsCSnmU for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 02:21:00 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F581200B8 for <v6ops@ietf.org>; Thu, 24 Oct 2019 02:21:00 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9O9Kvhi011476; Thu, 24 Oct 2019 11:20:57 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36523205842; Thu, 24 Oct 2019 11:20:57 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 283BE20582B; Thu, 24 Oct 2019 11:20:57 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9O9KvkF017627; Thu, 24 Oct 2019 11:20:57 +0200
To: Fernando Gont <fgont@si6networks.com>
References: <85b1ef40-f107-0ece-3e71-377f4d22dd46@si6networks.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Message-ID: <bb750ae0-940c-2477-fc6b-cea38af777e5@gmail.com>
Date: Thu, 24 Oct 2019 11:20:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <85b1ef40-f107-0ece-3e71-377f4d22dd46@si6networks.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/MLcxaOP501ceZYrf4xG-DBVVTmQ>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2019 09:21:03 -0000


Le 23/10/2019 à 10:51, Fernando Gont a écrit :
> Folks,
> 
> Earlier this year there was a lot of discussion about slaac renumbering
> problems. Our original I-D covered everything from the problem statement
> to proposed protocol updates and operational workarounds.
> 
> Based on the comments received while discussing this topic on this list
> and other forums, and in order to keep the discussion better focused on
> specific aspects of the problem, we have posted a v6ops-targetted
> document that focuses on:
> 
> * The problem statement
> * Discussion of operational workarounds, and associated constraints
> 
> The document is available at:
> https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum
> 
> We'd like to hear from the wg whether we have missed anything, whether
> the document is useful to the community, etc.

The document is useful because it sheds light on an existing problem 
that is not described elsewhere.

In particular, the home networks scenario is very appropriate.

First, I must say that the home network that I use uses a fixed /56 
allocated by my ISP.  In this, the prefix never changes, and it is not 
obtained by DHCPv6-PD - it is guaranteed by contract signed by hand. 
Such a case could be mentioned, as not being a problem described in this 
draft.

Second, with respect to this text:
> o  The most common deployment scenario for IPv6 in home networks is
>       that in which a CPE router employs DHCPv6 Prefix Delegation
>       (DHCPv6-PD) [RFC8415] to request a prefix from an Internet Service
>       Provider (ISP), and a sub-prefix of the leased prefix is
>       advertised on the LAN-side of the CPE router via Stateless Address
>       Autoconfiguration (SLAAC) [RFC4862].  In scenarios where the CPE
>       router crashes and reboots, the CPE may be leased (via DHCPv6-PD)
>       a different prefix from the one previously leased, and therefore
>       advertise (via SLAAC) the new prefix on the LAN side.

I agree with this deployment scenario.  We have used a similar scenario 
here in the lab (not at home).  We wrote a 'DANIR' draft that describes 
the implementation: the IoT Router (similar to a CPE) requests a prefix 
with DHCPv6-PD and then forms /64s and advertises them on the Ethernet link.

I must say that this kind of software (request a prefix with DHCPv6-PD, 
form sub-prefixes, and put them in RAs on the other interfaces) does not 
exist as open source or some other available package.

Because of that, I am surprised that you call it 'the most common 
deployment scenario'.  Is this a scenario that is _expected_ to be 'common'?

Then, a list of bullets follow, with more scenarios.

I would like to request addition of two other scenarios:

- an IoT scenario, in which an IoR Router connects several sensors to 
the Internet.  For example, an IoT Router is deployed in a box at a 
traffic lights.  The IoT device is the Traffic Lights Controller 
connected on Ethernet to the IoT Router.  The IoT Router is connected on 4G.

- a vehicular networks scenario: the On-Board Unit is deployed in a car. 
  This OBU has a 4G interface and an Ethernet interface.  There are 
several computers in the car that need IPv6 addresses.

One may think about fitting these proposed two scenarios (IoT, and 
vehicles) into the three others ('switch-port VLAN', 'planned network 
renumbering' or 'automated device config mgmt').  But these scenarios 
sound more like Enterprise.  IoTs and vehicles rarely if ever involve 
VLANs or planned network renumberng.

Alex

> 
> Thanks!
> 
> Cheers,
>