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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 09 November 2017 19:42 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8486129B09 for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2017 11:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Dnj25nrYel for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2017 11:42:00 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6594B129AEA for <v6ops@ietf.org>; Thu, 9 Nov 2017 11:41:57 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id s11so62290pgc.5 for <v6ops@ietf.org>; Thu, 09 Nov 2017 11:41:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=okylOGxxhzbYAobZh2G/cNdBYbOGiK8HJlvpSuSGUZY=; b=TSQnAviay5RlOF1L6XBc5HZ589+p0G0r/lT3YWf1N6cm1KfUFqqUnka6gHMdgeHvsn iKBbjD0RCf2rNE2+zkVrQlBwY3q4C74i255kpLLzQyIv3hqANf9eVkPg0nmepNslFTxC +vxmES2JhyzGv37Jtnm323reAXAllZCD98rZ+CbEe54ZTT6aFdiwcL1t4wv1ykyUxOcF vHaJ1tjgablo/KSmW12YKnKOJQvgCBLcc9QK8/zDXgtsdmR3MZfnuLFjgj2kybAxU2Ls CkCBPmHgS+i8+S5BRvX2Anemw8xiqOVNkVdkfGEe2dt6lDuP1FZNgu1X1BBOWV2abwON BGeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=okylOGxxhzbYAobZh2G/cNdBYbOGiK8HJlvpSuSGUZY=; b=TZNR4LqPAqOI2VLJG7R2FNpT3NyWwBAIMZvuHF4C/7HItpeZKqNb9VqEb6Suf1Fs8E GEYjdIJybzu0716dOUM17vAWhxin/An1NF6BTLkhOORiF1fDdek7bULjMBAA/h6Qh50o Oqzcjez0QxxcMvZbwtSbbfHK37EYSvFHi3Il8TIL/yXnAYSfrybUIAb7PoHVK68eq/eT 6iybAa7HvTRjAlOZ3a0IlJKwHAeRC+hJH1jrY2A385k1WSBTeSxSdGALPPLkPWY63Yqh e7Yi+fuSDsXDvJD3tSuCQuWddTp3aP/vHwCa4kY06/IZ/fujfUdmf832QaMA5H0imziR nO9g==
X-Gm-Message-State: AJaThX5DrBFBkUhwNuN6LGv+s5QlXfuMr9nV0iejuJFGxINK3YA6oRxu h5weE21GGnSaGoonThb1kfjCCA==
X-Google-Smtp-Source: ABhQp+SWpdJcTLfy/7DpcOAX23vYEfGGw/ZRBefc2tiKs1J0QhBVK3sDofiasIbxB9Gd6SW4ZXVcXg==
X-Received: by 10.101.64.4 with SMTP id f4mr1436052pgp.301.1510256516406; Thu, 09 Nov 2017 11:41:56 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 132sm9003204pga.80.2017.11.09.11.41.54 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 11:41:55 -0800 (PST)
To: v6ops@ietf.org
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>
Date: Fri, 10 Nov 2017 08:42:00 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/BnvlGW8weEp9qAXZacua1FqS-cI>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2017 19:42:03 -0000

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 <fgont@si6networks.com
>> <mailto:fgont@si6networks.com>> 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
>>     (<https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt
>>     <https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt>>).
>>     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,
>