Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Victor Kuarsingh <> Mon, 13 November 2017 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A79D6128CD5 for <>; Mon, 13 Nov 2017 06:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ftq8h7sJuF1A for <>; Mon, 13 Nov 2017 06:56:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60FDE129A84 for <>; Mon, 13 Nov 2017 06:56:14 -0800 (PST)
Received: by with SMTP id h81so5840565oib.8 for <>; Mon, 13 Nov 2017 06:56:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9qAts52zhFFeQZI+a2GVVKRcgo4q598oXj7nLVQHL84=; b=D8sskFO7AYqmrgGJWltznRT+MzIIeffZ3KW3RPeAa5eO3c1frmx41ZB6x+cSbjV3Wj P0nbJvkOgCKC2yh0rC/h8/RCIxUe86ndqOsu2GEOZeELH5k7ZGVsC6HoMpicNltPJxJV uIpv1bvgj8GNDStvBiyBueT8uSyYUgjVUJ6wlIBEDn96uNixdP+Zx2k7y5IMV9EtaiqT /qEQBPV3FoxwkE63t8Xu7omCADTvVHKRWFDpoCZ43qkiWqheidq30uvhEjudqSd6uLp7 1PE8cbbDZx9oL/hXn7emmGUs//ZCJPBqSf3hNnHGVO/kNfzMpCIxX0PgDboIXFS0lFUL fAcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9qAts52zhFFeQZI+a2GVVKRcgo4q598oXj7nLVQHL84=; b=OGRJ+iNHK1So22v2vnd6uG6fSBbIhT3kzPmUZEIiEO0z4k5idHQxQq6SXXpHHcW1Cq 6q+9dwB9lKRlM4xl9RtZfW4wzXshZm1z0OCLTtwpRy0ga5nLc2bWMfv0F/IZu9iD0COe IVo7J2hYpU/Hmq8aJkTE3A6NBWRbcGHDwBvRthgIuIiYkArYUv/kiekRfKtcNORYcVNG 9h7vIeU7XUxGRytnRv61iY7r6JT92SHSN9D2ciNhsmypt1Teexohfqtig5NricRKPB6p 1NOQlYWd3BzVbEu1uymP2wYCuK6KL1lpuOIgEW5fh/b9EhLcOwB+M24KNc+faTXjyUiT BOJQ==
X-Gm-Message-State: AJaThX6x/CzlIl1xUi7pfMaAlwD9zcMDKGAuX+y7wgyrS9FLRbykhWV2 I4xddga8dGGMa39PaJDzsAMVHfZMNTVsUz3Gg2vHqg==
X-Google-Smtp-Source: AGs4zMZw1x4NKKqQunVzbwtkQ5fVyqQ5ZzBlj49p0nUl6q23nXMxJKnKeqvkBsfqPe0MxBFulhoGnimx5MzWkLrfr00=
X-Received: by with SMTP id a191mr51523oib.86.1510584973416; Mon, 13 Nov 2017 06:56:13 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Nov 2017 06:56:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Victor Kuarsingh <>
Date: Mon, 13 Nov 2017 09:56:12 -0500
Message-ID: <>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont <>
Cc: Lorenzo Colitti <>, "" <>, " WG" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Nov 2017 14:56:17 -0000

On Mon, Nov 13, 2017 at 9:29 AM, Fernando Gont <> wrote:
> On 11/13/2017 10:17 PM, Victor Kuarsingh wrote:
>> On Mon, Nov 13, 2017 at 8:51 AM, Fernando Gont <> wrote:
>>> On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:
>>>> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont <> wrote:
>>>>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
>>>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont <
>>>>>> <>> wrote:
>>>>>>     >From a operational point of view, one would wonder why pursue this path
>>>>>>     as opposed to e.g. do DHCPv6
>>>>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
>>>>>> not recommended by the IETF. RFC 7934.
>>>>> Yes, sorry: I meant DHCPv6-PD.
>>>>> RFC7934:
>>>>>     Due to the drawbacks imposed by requiring explicit requests for
>>>>>     address space (see Section 4), it is RECOMMENDED that the network
>>>>>     give the host the ability to use new addresses without requiring
>>>>>     explicit requests.  This can be achieved either by allowing the host
>>>>>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>>>>>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>>>>>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
>>>>> Therefore, why re-invent PD in SLAAC?
>>>> PD is quite vast, and this draft describes a specific set of use
>>>> cases.  It does not seem like a re-invention of PD in SLACC to me.
>>> Again: Why not use DHCPv6-PD?
>> I would leave this up to the operators to decide.
> We are the ones trying to make SLAAC stateful, contributing to IPv6
> automatic configuration complexity, and apparent lack of coherence with
> respect to which protocol supports both, and why we e.g. disregard the
> work of other WGs (e.g. dhc).

I don't see how this work has any impact on what was done in DHC and
disregards it.  We potentially conflating things here?

Much in the same way RFC8106 (DNS info in RAs) does not disregard
DHCPv6 since it too can offer DNS information.

> If you want to *partially* duplicate functionality in another protocol,
> please provide a rationale, or don't.

Same point as above.  Some apparent duplication may exist, but these
are also two different deployment models. There are reasons why
operators choose one or the other model.  Telling them to use a
different model is not a valid rebuttal in my mind.

>> They are designing
>> their network and know their requirements best.
> Exactly: nobody specified the requirements, or said why DHCPv6-PD
> doesn't fullfill them.

What if operator does not have a DHCPv6 service for that access
network? (not saying this was driver for draft, but this is one
example).  Adding in a robust DHCPv6 service is not always trivial, so
if an operator is desiring to have this (/64 per host) capability,
while potentially keeping their service deployment framework SLACC,
why are we objecting to it?  SLAAC is a viable model to use, and the
draft describes the reasons for wanting a /64 per host.  So it seems
clear to me.

To exemplify, (maybe too far out of context),

If I asked for an extension to IS-IS for my deployment, and you told
me to use OSPF because that option was already there, my response
would be - "I am not using OSPF".

>> There are many factors the weigh into why operators make certain
>> decisions.  There are circumstances were DHCPv6-PD would be quite
>> valid, and others, as described in the draft, where the methods
>> described are desirable.  I don't think there is any one way to build
>> a network (I am yet to have built two that look exactly the same given
>> different input requirements).
> You still have not answered my question.

The operator has chosen to use a SLACC model, they need/want the
robustness/capability from a /64 per host.  So, if that's the case,
what DHCPv6 has to offer is not relevant   to what the operator would
need in this case.  A direct quote form the draft seems to also show
one of the reasons (others reasons can exist or may exist in future)

"To not exclude any known IPv6
   implementations, IPv6 SLAAC based subscriber and address management
   is the recommended technology to reach highest percentage of
   connected IPv6 devices on a provider managed shared network service."


Victor K

> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492