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

Mark Smith <> Mon, 13 November 2017 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F31E1129B5B; Mon, 13 Nov 2017 11:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NuU2Qxjh3Cxu; Mon, 13 Nov 2017 11:43:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D57E129B50; Mon, 13 Nov 2017 11:43:38 -0800 (PST)
Received: by with SMTP id q18so11211558uaa.0; Mon, 13 Nov 2017 11:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GJiugp6wudEdMC81Q/wcLO5vkbqgRHJcKAfAOKIe8tg=; b=A+jxmtcMAXjvlrN9COSXI0dq4mv614FHR9f73He+Ie0fm6PqWSrwWhqGoMp3XxZr3D mApGjZQJySLXXLsULyIK1Ua9w23GdJDrvUF2PSmZGCV4NGNlj0z5FiYoxGvCgxDhA5EH 4lX3E0ALpGtp0ZKloiunr8FDD7Cx83qErS4bgQan5IgFkoOaY5k9EHx1QJn1qVANSt/s RVvuDWV/naXOMKct0BddsA+I4URyb25wHjwdiKU+VcLMEpElLYcpgFFxjP2FqX38DxD0 74kOAG19tnFRA0zbMLBpShbLlnXA/gjTGeQLIozxnjxt7477b+P39XnireQCTG3I4m7c hpzA==
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=GJiugp6wudEdMC81Q/wcLO5vkbqgRHJcKAfAOKIe8tg=; b=nwNkaWNW7Z1PTLPuJ1k8qy2mb52htBaiEoNmwuodISBfQflFlwHNERtn6h1gPJETUm eCrcULVJgJq5vOAZ2nOQjcjD3pLb4LxTtlqIYeFsJ64m1GtmS3EZ0t9m4H2++nz77lMB phkSn5/Drmd/dw2Op+RzQoyKeAbOrma3vjPTfQ2FtA0S+LJkG2fvKrp1YrHnZmzDP7ZW Qr17yIMSRhmDID05cmKWjeNDO/xK/sjLK+/UAngsMBj07bb41WB7IYv80XD1MZF2aZkt 1t2DRE8cy6q8MrDbwg0NmJ9sRI3du3YjIo40rEyczHflI1T3jQHVGDwGz2S0O0C+3Rol BGpg==
X-Gm-Message-State: AJaThX6FnpCJRCYlE0e/j2ECbhV7WrmLYFZSXPQFnhfGgruaYoaMJz5l b+9TdCzIDJ3FkkpwZQ0by/gSZnlVw5D+UYIzqvE=
X-Google-Smtp-Source: AGs4zMbRsllNPn9QOW2RqxtSm6lucVBGJv3qx0aZsIt+YREl5tPVu1wM1CL3qWIqW7ux9MdtQJ+g9buPQSBldcMX4Y8=
X-Received: by with SMTP id d31mr8295191uaa.53.1510602217317; Mon, 13 Nov 2017 11:43:37 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Nov 2017 11:43:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Mark Smith <>
Date: Tue, 14 Nov 2017 06:43:06 +1100
Message-ID: <>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Lorenzo Colitti <>
Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <>, "" <>, " WG" <>, Fernando Gont <>
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 19:43:40 -0000

On 13 November 2017 at 19:00, Lorenzo Colitti <> wrote:
> On Mon, Nov 13, 2017 at 4:52 PM, Mark Smith <> wrote:
>> It's a fantasy that routers don't fail, or that a single router on a link
>> is always enough.
>> Host connections are supposed to survive transient failures such router
>> reloads or switching to a different router that provides equivalent packet
>> forwarding service. If a host loses its prefix in this scenario because of
>> either of those events, then I don't think this method as currently
>> described is robust against a foreseeable failure.
>> I don't think it is a Best current practice if router redundancy hasn't
>> been considered or tested and deployed, and can therefore be documented. I
>> see value in the approach because of SLAAC compatibility with hosts however
>> I think it is currently half baked.
> Let me state this again:
> DHCPv6 PD has exactly the same problem.

No it doesn't.

> As far as I am aware there is no RFC that documents the solutions that are
> in use for DHCPv6 PD.

DHCPv6 has been designed to avoid having state in intermediary devices
by incorporating a relay agent into the architecture, specified in

Clients use DUIDs to identify themselves, and the DHCPv6 server
associates client attributes with the client's DUID. That is what
allows DHCPv6-PD to survive a router/DHCPv6 relay reboot.

This draft hasn't been published as an RFC, however it is also
considering this issue.

"DHCPv6 Relay Agent Assignment Notification (RAAN) Option"

A number of vendors seem to have implemented the functional equivalent
by looking directly at the ID_PD option when the DHCPv6 reply is sent
to the client - search for "DHCPv6 Relay Agent Notification for Prefix

The alternative is to have a RADIUS server provide the delegated
prefix information to a DHCPv6 server running on the router. "RADIUS
Delegated-IPv6-Prefix Attribute", RFC4818.

Possibly the RADIUS method could be used in this draft's scenario if a
layer 2 attribute such as the MAC address or per-client VLAN tags, or
802.1X authentication information, is used to identify the client.

If this draft can't document that method because it doesn't exist,
then, assuming Comcast is the only deployment of this, it seems
Comcast aren't trying to have a prefix assignment survive a router
reboot. That's a "flash renumbering" approach, which I don't think is
right for IPv6.

> This has not stopped the deployment of tens or hundreds of millions of
> networks that use DHCPv6 PD.

What was the alternative that didn't have this limitation?

There is a big difference between something working and something working well.

I worked on the first production deployment of residential broadband
IPv6 in Australia in 2010. Going by the beta software we were working
with from one of the major BRAS vendors, that was likely one of the
earliest in the world. Making it work was the goal. If the goal was to
make it work well, we wouldn't have deployed it. (I haven't worked on
an IPv6 residential deployment since because of Australia's position
of being early in the IPv4 game, and ISP consolidation making IPv4
pools bigger.)

Six years later, with much more production IPv6 deployment, new
methods and solutions shouldn't be functionally equivalent, they
should be functionally superior, because the consequences of failure
matter more.

> Why are we holding this document up on this?

Half baked cakes aren't cakes, even though they may look like them.