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

[Alexandre Petrescu <[e-mail]>]

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,
>