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

Mark Smith <> Thu, 09 November 2017 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59A9B129B44; Thu, 9 Nov 2017 13:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Status: No, score=-2.196 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cx9LKSV737hD; Thu, 9 Nov 2017 13:14:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 723911200B9; Thu, 9 Nov 2017 13:14:00 -0800 (PST)
Received: by with SMTP id t184so4883462vka.6; Thu, 09 Nov 2017 13:14:00 -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=2F2FmR+pR+KeZxk2to4eVZP534fr6PiDWCWtSMuEjOY=; b=QV+p80rm1sX0lrCZ/DVG1Fn5C4y23PLSHh+WPAtso2xeIgPcEQonwxhnXcjsGuepUh uygnVthDy/L33CTBKNr7WQ1NmuEZWlYuxdOloW/AY+alZkRTqxIkKTEdJjbdpEbr7OCs qKW3KPIH7PSgOuDe8k+0giy173vGUzyII6huzly9FFn8KgnXFdkAlTrBT9QGMAQr+SPD 93aPhzqi6Gd5f6N8iO9lrNz0gaxHiUKY+vUUQxyNf7/kaluQjJI6cBDLkl4PCflOXiL4 JmGSMWi/amT6XYqcPjbKbtHSRKRoamzbwx+IYYPiX53Cx4bj9uk39ughZedlKq4WfEFN E2dA==
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=2F2FmR+pR+KeZxk2to4eVZP534fr6PiDWCWtSMuEjOY=; b=Uia6hwdmuIZmdBiDHjwFSIsZcRhWivgYlt6UXsPsIv0P2x43Lysw1YorVojr5HrqRi qLyX8pk+1ejg8sx78dhbRXKOI2nMGHFEy2FDrJ+YEEexCj0zUgYTTt+qP6vxCEgEdMeU CO544POQsG9zrb+0UR0n8Gk/w7Hl8qD6PBbIZudODfXpcJbQNgormwRoQKiWlYO9ffhe FY32eeujJyrr6N/y1nX5YDoH0i00/JJPSS/G54LkW4/zruvIz8EcFwckqJuKmPtaqO3v 2nUJ76vF/5hZ8TxEdGQ7vvFKrtJSfpUoBJX7+tyrIVXNg+2E1FFZZkqVdw0VJ9R0gZ02 gFTg==
X-Gm-Message-State: AJaThX7v4WjMZWJipo1ecuBnD7sbGp8HHyFIB5fFr38MQncZySvhWwye NdXe6yWnfsqB8giLlkGXtjpGF19qpCjugQB3CYM=
X-Google-Smtp-Source: AGs4zMY3wGUM/70zoP+VLd4Dp4fdU0YN/gF00zNWy4B3MSgJu8fyfv3BhM9w6sZGSWfKmgOo6kHhn0socC+ip+cRgmo=
X-Received: by with SMTP id o205mr1590471vke.147.1510262039339; Thu, 09 Nov 2017 13:13:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Nov 2017 13:13:58 -0800 (PST)
Received: by with HTTP; Thu, 9 Nov 2017 13:13:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Mark Smith <>
Date: Fri, 10 Nov 2017 08:13:58 +1100
Message-ID: <>
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: "Templin, Fred L" <>
Cc: Fernando Gont <>, Lorenzo Colitti <>, IPv6 Operations <>, "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="001a11415eee5f67d7055d934862"
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 21:14:02 -0000

On 10 Nov. 2017 5:19 am, "Templin, Fred L" <>

> > 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
that means unicast at both L2 and L3 (i.e., and not multicasted at L3).
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?

I think it would be better to do it that way and suggested it because of
the principle of least suprise. Ole said that for an implementation he
works on, it is easier to do link layer unicast of multicast RAs rather
than RA unicast (perhaps because the implementation isn't performing NUD
and therefore isn't performing discovery of IPv6 neighbours, so knowledge
of their Link-Local addresses isn't available).

I'm comfortable with both options (as a contributor to RFC6085), although I
think unicast RAs should be the recommendation.

(I've thought there can also be security benefits of link-layer unicasting
for IPv6 multicasts when possible.

"MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6"



Thanks - Fred

IETF IPv6 working group mailing list
Administrative Requests: