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

james woodyatt <> Thu, 09 November 2017 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D593D1279EB for <>; Thu, 9 Nov 2017 15:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 RXFnIby7O4xj for <>; Thu, 9 Nov 2017 15:01:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 628A9126C2F for <>; Thu, 9 Nov 2017 15:01:18 -0800 (PST)
Received: by with SMTP id y75so6745073ywg.0 for <>; Thu, 09 Nov 2017 15:01:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=haqRjcUVjfn5CO4mMFdvjE/eXCgMds67v07xi8sfDM4=; b=hs9wN0BOahqRV7qLxHzzJPYm+Tl4+XZebzJsvlHvd4PI7fOOf66MGCC7vrOaQZ+A3O xg1/sZbMdHzemnPWjwTGEj5MOuivrRDe268/yO6UWmhapQKb/shee9I+PbCZhG9mgOvq NGteuWJaO8u1imr2mnMaMWhvh/ycFWhVJJskhCfQQprIj3ljgTiKsUhr58QY+n/t5HS1 w6QeYqRCxFvXn2ZN8x+nil+JmfPxZpu6IJcDyFJUXxD6xkshLcd7CC0aEXvZz/IiZK5R IAwks+g0lpFP42I8cQr6i7DOotJCl5Y+6tiligprAh2k0kDWoLLdikFdV2PW+VlowgCP ZVUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=haqRjcUVjfn5CO4mMFdvjE/eXCgMds67v07xi8sfDM4=; b=MyLMqQVM/MuqfhbAxGziDQFQN6LSeZF7hEsKUmmpitrU245DY2nkbFmzxtG5SXsXHp RxjgK+aiG6mPKnjfJbmo7/oWJsTOdESc+/yUS0sbYmAdfU/+tVrgmEo6UxuvwgLewYt6 8pTs7tK5UtZ/ArDiCajztmSZ73tLm29zftJcJ8mU6/Qr03Wc7BSgfMC9+vI5hjv/OBMA IJzpBZTNcUK1trM9O4s0uulPGyYF7gGWXqMyajJm2srDQKzRxL8dRVd5ddwxngGUGfY5 oyfL6oiFj7jC+5cBI5lG/gYh6NEUQIzdFZ5D3P8eeoFuW7qbRXONNuRQthRNK6yGJgjY c4WA==
X-Gm-Message-State: AJaThX4iOjKB71ykhQ7F/sjYc0+cNcLBFV/BQhSSTTpy8J8c2BHbIJmF V70WHJpFkfgj3LHvsJIaQZYeMw==
X-Google-Smtp-Source: ABhQp+TU9NsS1dl6OIdqA87GqCHvano/Goc52/XvPvMOnd1wFGpG+qW6g1z4xCrc8ZGTYN636Pmipg==
X-Received: by with SMTP id z185mr1470157ywa.258.1510268477307; Thu, 09 Nov 2017 15:01:17 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id i207sm796667ywe.38.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 15:01:16 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8079F2A4-00E6-4980-A58B-42DFE08E4429"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Thu, 9 Nov 2017 15:01:25 -0800
In-Reply-To: <>
Cc: IPv6 Operations <>, "" <>, "" <>, "" <>, "" <>
To: Brian E Carpenter <>, Fernando Gont <>, "Templin, Fred L" <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
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: Thu, 09 Nov 2017 23:01:23 -0000

On Nov 9, 2017, at 12:36, Brian E Carpenter <> wrote:
> On 10/11/2017 07:19, Templin, Fred L wrote:
>>>> 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.
>> On this point, I agree with Fernando. RFC4861 says that RAs can be unicast but
>> that means unicast at both L2 and L3 (i.e., and not multicasted at L3). 
> Who says that? As Fernando reminded us, RFC6085 says otherwise.
>> RFC5214
>> is an example of where both L2/L3 unicast are used in RAs in the spirit of RFC4861 .
>> Is there some reason why the requirements of this draft cannot be satisfied
>> by L3 unicast?
> Hosts listen for L3 multicast RAs.

My answer to Fernando’s concern about this late addition to section 4 possibly moving this draft into the ambit of 6MAN. I don’t think it does.

Here’s why. I don’t see the intent of RFC 6085 as to change the operational semantics of IPv6 multicast in the way that this draft sees it. When an IPv6 forwarding node sends a multicast packet with an Ethernet unicast address because the router knows that its group membership on the link comprises exactly one node… however, the RECEIVING node cannot be expected to share that knowledge. Therefore, when a host receives a multicast RA message in a unicast Ethernet frame, it cannot be expected to recognize that as a signal to indicate there are no other hosts on the link. Fortunately, this draft doesn’t violate that assumption of the protocol. The last paragraph of section 4 goes to this point:

   After the subscriber received the RA, and the associated flags, it
   will assign itself a 128 bit IPv6 address using SLAAC.  Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.  The
   subscriber will for that purpose, perform Duplicate Address Detection
   algorithm.  This will occur for each address the UE attempts to
   utilize on the shared provider managed network.

If the unicast address on the multicast RA message were to signal that the subscriber really is the only member of the all-hosts group on the link, then it would not be necessary for the host to perform Duplicate Address Detection (DAD), now would it? Of course, it has to perform DAD— how could it not do that? Imagine all the things that could break if it didn’t.

Not mentioned in this draft (more is the pity) is that the provider router may send ND Redirect messages with a Target Address not in use by the subscriber host but still having the per-host unique prefix. Of course, in this scenario, the subscriber host cannot know that the prefix advertised in the RA message is a per-host unique prefix, so of course it’s then expected to process any ND Redirect messages it receives, and to update its Destination Cache according to RFC 4861 How could it not do that? Imagine all the things that could break if it didn’t. (I can imagine quite a lot, actually— I’m thinking of applications for this even now.)

I was critical of this draft in V6OPS because I thought it didn’t make all of this sufficiently clear to the reader, but it was all pointed out to me on the list in subsequent discussions, and I seemed to be out of the rough consensus that it was necessary to clarify any of this stuff in the text, i.e. the fact that I initially misunderstood how this BCP is not actually a protocol specification should be no reason to believe that any ordinary reader might make the same mistake. Accordingly, because all of the protocol requirements about DAD and ND Redirect still hold despite all the diversionary text in the introduction about link-layer isolation, I’ve dropped my procedural objections to this draft.

--james woodyatt < <>>