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

DY Kim <> Sat, 11 November 2017 03:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 201031270A0; Fri, 10 Nov 2017 19:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_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 188lfUsR0ylj; Fri, 10 Nov 2017 19:02:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B9291200C1; Fri, 10 Nov 2017 19:02:18 -0800 (PST)
Received: by with SMTP id t10so7728252pgo.3; Fri, 10 Nov 2017 19:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4FkiQG5q2XywWR3NTMput3+SmTP/2cb2WO5QivdX1DU=; b=p+sY+1EQ8KYlloSrL8A6pza8FcU/s4V+0B85jrvAcmdfRck/wFuRqkHXHbZO0mEus8 l79JGe0Ey4seJJL8BFl6myLoqIm05zbA6RMr5x8/y+6iQvbRRCWhFBjENkfDrMz4d/tm uSgMQFFZEg8YIttArnMfmjNWSNd4Bz8VPA27zwSgy2+qya9YqcGrU0QuorYw/X/GkYID +4I1wr1RrQd21cBkEvKk43wIqxnKJHZ2aaoxtXo3qkOWxNKbiPDkeZNB/8J+7kvWV0GI M2hXLwmmLN24pyrz5fKQTP4uOK4b6BRrFLbkassFhlPwrVO4WdeTryggC/e7/nVtuhr/ 7FWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4FkiQG5q2XywWR3NTMput3+SmTP/2cb2WO5QivdX1DU=; b=Il19ZWJeYqTGALdmwmNLNkGL945d62GaeiTwwhFJpG1ASntrtxSczqwssSPfMuSO2W 5C3CmsR1/8doXaLjOviHRq+1wuUPOAtSSGqIQ0ENIkW1tcEkOhl1LghR/Ri2EQAye1U1 SIKDTxA/LEiRcofvqIo/yKQhFW9Ce0BYQn/T5PO50uIjeCsXrAdtIPiahPqNLwZ1Pk8K YJ3oORibrzEqwJb9oX9IlhkDEnbBV5tzP/3YdCUV7nEoNx06NFNLoTow2FebKTNE1JOz b7duo3NfaIphSV7aHEv+pfPqlH1a+sUCz3hpRexvtctRFzb5PNskNCK+vAdcXlhadrQZ Fq8w==
X-Gm-Message-State: AJaThX5zhV1E5rvWu0ZVSRdLNFLY6ND9EvnlmaAA14MG4cD9qBpXnbFT VhYrBXQNrGu+o/o3tLMSyhk=
X-Google-Smtp-Source: AGs4zMb+kuJe1ck/eLXKr7IVdIbVah27sDgEfsfoIBsMVwbDuvUkF4cf+kbref7fmaMfg3uApSDjUw==
X-Received: by with SMTP id f195mr2531008pfa.188.1510369337738; Fri, 10 Nov 2017 19:02:17 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id y3sm1269329pff.122.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:02:16 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim <>
In-Reply-To: <>
Date: Sat, 11 Nov 2017 12:02:12 +0900
Cc: Fernando Gont <>, IPv6 Operations <>, "" <>, "" <>, "" <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.3445.4.7)
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: Sat, 11 Nov 2017 03:02:19 -0000

The issue is about the router crash and recovery, not SLAAC itself; not particular about SLAAC.

Even with the legacy operation wherein the router is assigned a link prefix (from the site server by some means) to be advertised to the hosts on the shared link and the hosts run SLAAC for address assignment to their interfaces, what happens if the router crashes?

Either the router has kept that link prefix in a stable storage, or if not, the router might have to acquire a new link prefix from the site server, and not even knowing whether the refreshed prefix should be the same as or different from the previous one, the router and the hosts on the link might go through a painful renumbering anyhow.

Hence, the issue, if any, should be raised against the router spec, not against this draft or even SLAAC, I’d think.


> On 11 Nov 2017, at 11:45, Ted Lemon <> wrote:
> The issue is that if you have allocated a prefix for a host and then you reboot the router, either you retain the allocation in stable storage, or you don't.   If you don't, how do you make sure that the host doesn't get renumbered?
> That's the sense in which this is stateful, whereas SLAAC by itself is not.   It's not really SLAAC that's stateful—it's the mapping between the link-local SLAAC address and the prefix that's assigned to the host.