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

Lorenzo Colitti <> Fri, 10 November 2017 00:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73DF11288B8 for <>; Thu, 9 Nov 2017 16:35:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j8eDRidLUhlE for <>; Thu, 9 Nov 2017 16:35:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7612127444 for <>; Thu, 9 Nov 2017 16:35:32 -0800 (PST)
Received: by with SMTP id j140so12928584itj.1 for <>; Thu, 09 Nov 2017 16:35:32 -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=EK73B3p7r2GeOtDd6Li5n2hzB+1NaAcfrnlNwSc8Qks=; b=YxsLV2NTVq16gqELfNOATxJ49Xftrbkm4H6DEnaByCRHbyw0+9vlB+bZ5k1EJMVxf+ yZVPx2y37A4f/qH5xEnWSV3Xmmy5iInKjFJ3MgJtthHUf7vTaQ8+tPXrz1xoTdILKoIH P3B81MK1oa20JbhN/pzyc+/Ip/9nWAGYRfpOVgpRWxX/wmablLt7o9CBwM1pkb3NEln/ UloOZR9nHFyjOGKf6oZDz3cx5azq75V/5xFqMAG3GFeKDeSKns+Fof61Pt+Gck1NfSSG KDhTNGLnnKWoheD9aTNUDCIkjudq/blQnqQ5sRlHAp6lnghkofMqYVE6cb8LnZSTS0TH NUCg==
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=EK73B3p7r2GeOtDd6Li5n2hzB+1NaAcfrnlNwSc8Qks=; b=RON765BlBD1o7ASVgozVfZbBNXXVBojKxQolw7Ph1Xvg1/EymFJP6FVFPI0oXjm3cH jrxlRRKflrznbIVobc01XmKwuzcDee3FHfKmfx2tXcUiO9k/Eb9ZjDrQhmdTQOQtDiRW qb0cGpTbCMGQIf1hZjspYuT0HbUES2kJgr6VuQbnlm7Rsg+aq7Zp+CT8PLv9oFjHcZPk yuf81SYaPOK9/LCdxNGTg1GlWtlafb4swXxV2JBtEImqnsD1jJ1D4qc+BBrVBITZj236 iFW+ahYQ2M/010Xmaqxj427g6Hg2XLYYM33Qkr/LiJDL07kh9Pg9+yHjh+kG6nbuU84d OBNw==
X-Gm-Message-State: AJaThX4NO5uXr3NH8vqkuxgrkxAqmRkHikVFTazyINsHa37kzGXf5v4R 1/zBYOgtSlpzkgNdHaSK0WPNJ4depsvuf2ESwV5s3w==
X-Google-Smtp-Source: AGs4zMayeSqIJf5pdYRV4QhRcQ95UXdnId0g0chmoKIh56pFVMgvPOQZ/RfyS4XggGvs+ezJBR6FpDv2UyoVHGh6PZo=
X-Received: by with SMTP id b65mr2174144ith.151.1510274131601; Thu, 09 Nov 2017 16:35:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Nov 2017 16:35:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Lorenzo Colitti <>
Date: Fri, 10 Nov 2017 09:35:10 +0900
Message-ID: <>
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont <>
Cc: IPv6 Operations <>, "" <>, "" <>, "" <>,
Content-Type: multipart/alternative; boundary="94eb2c0b285821282e055d961997"
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: Fri, 10 Nov 2017 00:35:35 -0000

On Fri, Nov 10, 2017 at 2:48 AM, Fernando Gont <>

> > I don't see how this is a protocol change. Sending RAs unicast is
> > already allowed by RFC 4861, so this is just an operational practice.
> That's incorrect. We are talking about sending multicasted internetlayer
> packets to a unicast link-layer address. There's nothing in RFC4861 that
> suggests you should do that. RFC6085 says "you shouldn't drop packets if
> they are internet-layer multicast but link-layer unicast". But
> certainly, unless a protocol spec says otherwise, the normal mapping
> applies.

The intent of 6085 is clearly to allow this. The introduction says that the
purpose of the document is to allows mapping a multicast group to a
link-layer address "when it is clear that only one address is relevant".

> The additional text did not actually change this practice at all.> It
> > simply clarified what has always been a fundamental premise of this
> > operational practice: if you want to give each host its own prefix, you
> > need to ensure that the RA with that prefix is only received by that
> host.
> If you want to give each host it's own prefix, you do prefix delegation.
> So far, SLAAC doesn't do prefix delegation. If you want to do prefix
> delegation in slaac, write a std track document in 6man, not a BCP in
> v6ops.

That statement does not match reality. All IPv6-capable phones (well over
100 million at this point) have a /64 prefix that is dedicated to them by
the network, and the mechanisms used for that are RAs and SLAAC. See RFC

> > This is a bizarre claim. The first-hop router must always have fully
> > up-to-date state on all the prefixes it is sending RAs for, otherwise it
> > cannot fulfill its fundamental purpose of forwarding traffic to those
> > prefixes. The word "stateless" in SLAAC applies to addresses configured
> > to the host, not how routers route traffic.
> A SLAAC router need not maintain any sort of dynamic mapping. It's
> static configuration information of the sort "I'm announcing this prefix
> on this interface".. If you think otherwise, please point me the section
> in RFC4862 where this conceptual data structure is mentioned. (Note:
> Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).
In many cases that's not correct. Consider DHCPv6 PD, which you cite as an
example above. IIRC there is nothing in any RFC that says that the
first-hop router of a requesting router needs to maintain a mapping between
delegating prefix and requesting router, but that mapping is 100% required
for DHCPv6 PD to work.

>     3) What happens if the SLAAC router crashes and reboots, loosing state
> >     of the "leased" prefixes?
> >
> > You seem to be assuming that the router does not store the prefixes in
> > stable storage.
> Routers store configuration info, not dynamic mappings.

Again, see the DHCPv6 PD example above.

>     4) How are prefixes selected? And, what's the minimum size of the pool
> >     of prefixes for the selection algorithm not to break due two "prefix
> >     collisions"? Does the selection algorithm have any specific
> properties?
> >
> > I see no reason why this should be in scope for this document.
> Actually, what's not in the scope of this document, and not within v6ops
> charter, is the protocol you are specifying to handle prefixes with SLAAC.

Protocols are out of the v6ops charter, and that's fine because there is no
protocol in this document. :-)