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

Fernando Gont <> Fri, 10 November 2017 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08E6F129453; Fri, 10 Nov 2017 11:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.852
X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tWs4mm97V7mB; Fri, 10 Nov 2017 11:53:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B361128D0D; Fri, 10 Nov 2017 11:53:38 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F203682983; Fri, 10 Nov 2017 20:53:32 +0100 (CET)
From: Fernando Gont <>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Brian E Carpenter <>,
References: <> <> <> <>
Cc: "" <>
Message-ID: <>
Date: Thu, 9 Nov 2017 23:35:21 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 19:53:41 -0000

Hi, Brian,

Please let me top-post to try to focus the discussion here:

1) My comment to the list was essentially arguing that this document
contains a protocol specification, and such part is not suitable. I
think it should be easy to converge on something regarding this one:

Can anyone (you, for instance), provide a definition of what is a
protocol, and the run this document through such definition and figure
out if it fits or it doesn't?

It would seem to me that many folks seems to be assuming that the only
thing that can be said to be a "protocol spec" is something that
specifies a new packet format -- a definition with which I disagree.

2) The rest of the conversation has been about details (or lack of) of
what I believe is the protocol being specified in this document. Such
discussion can be interesting. But I believe at this point the item to
be discussed is #1 above.


On 11/09/2017 04:42 PM, Brian E Carpenter wrote:
> On 10/11/2017 06:48, Fernando Gont wrote:
>> On 11/08/2017 11:58 PM, Lorenzo Colitti wrote:
>>> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont <
>>> <>> wrote:
>>>     While reviewing this document a few days ago, I found that Section 4
>>>     (page 5) contains what is a protocol spec, rather than an operational
>>>     BCP. It contains rules regarding how to set the link-layer address (to a
>>>     unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
>>>     now remember which prefix has been "leased" to which node -- something
>>>     that seems to be way outside of the v6ops charter, and that should have
>>>     been done in 6man, instead.
>>> 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. 
> No. It's more subtle than that. We are talking about sending packets with
> a LL multicast destination address to a unicast LL address. The packets
> are not in fact multicasted, although the recipient will in fact receive
> them on a multicast socket.
> Again I ask, so what? It may be different from what we thought of in 1998,
> but I simply don't see why it's problematic.
>> 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.
> Actually RFC6085 also says: " This document
>    extends this mapping to explicitly allow for a mapping of an IPv6
>    packet with a multicast destination address into an Ethernet link-
>    layer unicast address, when it is clear that only one address is
>    relevant."
> That seems to apply perfectly here.
>> There's nothing in RFC4862 that may suggest "leasing one prefix per
>> node". 
> No. That is the operational innovation in the present draft.
>> In fact, all nodes share all the prefixes being announced. 
> All nodes that receive the announcement share it. In this operational
> mode, only one node receives it. Again, what's the problem?
>> And
>> when you don't want multiple nodes to share them, you just segment the
>> network one way or another. From the point of view of SLAAC, there's no
>> "one prefix per node". If it happens, it's because you segmented the
>> network, not because SLAAC is meant for that.
> Yes, effectively this draft does segment the LAN from a logical
> viewpoint. Why is that a problem?
>>>     Looking at diffs, it seems this additional text was incorporated very
>>>     recently, in version -09 of the I-D, published in mid September
>>>     (<
>>>     <>>).
>>>     It seems to be that this change is way beyond what the authors
>>>     originally proposed
>>> 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 would be a more complicated way of getting the same result.
>>>     1) The protocol spec specified in this document requires the SLAAC
>>>     router to keep state of the "leased" prefixes -- what seems a major
>>>     change to SLAAC, which now would be kind of as stateful as DHCPv6.
>>> 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).
> Sure. The implementation will need a data structure per host, not per
> interface. Any way of handing out prefixes needs that. Why should I care?
>>>     2) There are scenarios in which multiple nodes might receive the same
>>>     packet -- say a NIC let's the packet through because it is in
>>>     promiscuous mode -- wich could possibly lead to two nodes configuring
>>>     the same prefix.
>>> Why do you say promiscuous mode is a problem? Even in promiscuous mode,
>>> network stacks already understand which packets are being send to the
>>> host network stack and which are not. For example, in the linux
>>> networking stack, well before the packet ever gets to the ICMPv6
>>> protocol handlers that would process incoming RAs, ipv6_rcv does:
>>> if (skb->pkt_type == PACKET_OTHERHOST) {
>>> kfree_skb(skb);
>>> return NET_RX_DROP;
>>> }
>> Great that Linux double-checks this. But it need not. Linux is just one
>> implementation. A very popular one. But one implementation.
>>>     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.
> I think that depends on the router. Configs are not static in the general
> case anyway.
>> Simple scenario:
>> With slaac, the network is 100% resilient if a rotuer crashes and
>> reboots (because, as the name implies, it is stateless). With this
>> protocol you are specifying in this document, if the router crashes and
>> reboots, the network may just break -- same prefix may be reassigned to
>> different nodes, etc.
>>> It's certainly the case that if you want this scheme to
>>> work across router crashes, then you need to ensure that the prefixes
>>> are stored somewhere. That sort of seems self-evident, but we could add
>>> it to the text.
>> SLAAC stores *configuration information*. This protocol that you are
>> specifying requires SLAAC to store the *dynamic mappings* of which
>> prefix was "leased" to which host. And the fact that you need this for
>> this mechanism to work is an indication that you are specifying a
>> protocol. (Call it Stateful SLAAC, or AAC ;-) )
>> An operational practice is when you fiddle with the knobs that a
>> protocol gives you. Here you are introducing a state machine into SLAAC.
>> That's certainly not an operational practice, but rather a fundamental
>> change to SLAAC that makes it a stateful protocol
> It's not in SLAAC. It's almost certainly a layer above SLAAC.
>    Brian
>>>     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.
>> Thanks,
> _______________________________________________
> v6ops mailing list

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