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

james woodyatt <> Mon, 13 November 2017 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5706B129B50 for <>; Mon, 13 Nov 2017 11:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 zS4gN_ExQBq2 for <>; Mon, 13 Nov 2017 11:03:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81B29129B56 for <>; Mon, 13 Nov 2017 11:03:21 -0800 (PST)
Received: by with SMTP id m191so10618955itg.2 for <>; Mon, 13 Nov 2017 11:03:21 -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=2tDDsVAF4K/+9Y59oKitInH2fevXWL/9eb9GODUOTmI=; b=EZcSLd7JoADSsMFI+4ebVpuQNvTiYaIrYCskj4q26f2Qh8WpQjlZtMe5GGtBUqX6LY PT3Pxg8E75goLPy70/b2wVjBnKgmwgzYH/gyIem1VwS2VJG1Xb1vbi70THBHKA4UEML6 n1v1xO8+9GBJTh7OXueteKE6Wwc5M9bcWqmGxsYESN3fEEBZbEDaaDboNhJAydhLOgu/ s7ml6779ZXBJgBgEihPirpVeHjXBN/yTszoN8CdiVwkHRz3ru80pbz8TYdbiKqOFx2jV CQ/kpRYdg3HW+bO319OKy+EM2BW46P2EPbT7zetCUg6M5BIXdHs5eOE2QiIU6Q6Wq3vX 5T6A==
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=2tDDsVAF4K/+9Y59oKitInH2fevXWL/9eb9GODUOTmI=; b=HEkMl9ZgjdsYQKy0EVqHrmk5kRu9/uuB17dNKDQdlPNQ2EEO1KuFX1tH2VVY5zDbE0 f28E9kdHaucMUVOG0CyyhCpm0cuLGvltgyS4G2jHwZx0KL5ZRQ46x0C+ESKctzUBl5/p lqzIN1dHoyipD2KlWaev1qMbvRJa6s1eziedYggKmyHwnVqjwj2IJVJFu7uaHT8tlc26 TWhLQyARvnEefKeUgdwoVuOyrXw8KbhR0yzhjaqUkoEcC9uH/13YQpDCdRCkFTYR4JCg gRxRUZ3ipscL1XElaM0U6B0OwRns50OXg+rO/rOdwECsvWo1S5DljM4FoEeC/U6HTBe5 Lwfw==
X-Gm-Message-State: AJaThX6dW9ts6m9N7g4DafMoUb3dn0bzoj2NIv0tP51UnGQ1cm4Qw6AB Rw5UpeGz7PntgpVpjN9RS9U1WQ==
X-Google-Smtp-Source: AGs4zMZjzmKkJ8VxzIX5xyCWbEbF+saSrEXIkxrlbe6JzQbU6XTGMsLjFV/k8cUUiYICKC4r/Pz6mQ==
X-Received: by with SMTP id s143mr10939982itb.64.1510599800444; Mon, 13 Nov 2017 11:03:20 -0800 (PST)
Received: from ([]) by with ESMTPSA id g79sm4568312itb.43.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 11:03:19 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9B99862-968F-4B5A-B099-3FC47336626F"
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: Mon, 13 Nov 2017 11:03:18 -0800
In-Reply-To: <>
Cc: "" <>, " WG" <>
To: Lorenzo Colitti <>
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: Mon, 13 Nov 2017 19:03:24 -0000

On Nov 12, 2017, at 18:14, Lorenzo Colitti <> wrote:
> On Sat, Nov 11, 2017 at 9:41 AM, Joe Touch < <>> wrote:
> FWIW, I would agree with that if this were an issue of WG focus creep. 
> AFAICT, the issue appears to go much deeper, which means it's an Area
> boundary issue if it is indeed a protocol extension.
> IMO, OPS stays in the lane of suggesting sets of *existing* protocol
> parameters and features, or indicates where MAYs and SHOULDs can be
> relaxed (or not) - all of this remains compliant with the protocol.
> Changes to the protocol should not be considered operational decisions,
> again IMO.
> Excuse me, but I really cannot fathom why we are saying that this draft defines a new protocol when it is an explicit goal for all existing implementations to continue to work. How can this be a new protocol when all implementations implement this already?

I agree with Lorenzo here, and I have to push back against Mr. Touch’s earlier message insisting that a protocol specification cannot be useful unless it defines the finite state machines for each participating member. This is not even true in theory, much less in actual practice. In theory, and here I am referring to the literature of bisimulation and the calculi for communicating processes, it’s generally sufficient when formally specifying a protocol to require implementations to exhibit "barbed equivalence" with one another. Indeed, what is the point of insisting on interoperability between disparate implementations if we only accept strict bisimilarity as conformance?

Moreover, we don’t even require formal protocol specifications here, preferring instead— as a matter of explicit policy— to publish informal specifications rather than formal ones. Therefore, it seems to me that a more broadly expansive understanding of the term “protocol” is warranted than the very narrow, much more formalized one that Mr. Touch outlined.

Here’s how I see it: when we publish a protocol specification here, what we are defining the rules to a multiplayer game where each player is free to adopt whatever strategy within the rules is optimal for achieving their aims. Our job as Internet engineers is to insure that the rules of the new and revised games we publish are balanced and do not contribute any damage to the Internet as a communications ecosystem. This draft does not modify any of the rules for provider routers that subscriber hosts legitimately expect them to follow. It makes no recommendations to change any host behaviors. It is therefore not a new protocol. It is merely a new strategy for performing an existing protocol.

It’s also my view that this draft is mainly an attempt by service provider operators to establish a new convention for keeping state in the network on behalf of hosts, and its authors have taken great pains— cut many corners and shaved off a lot of risk mitigation— in order to avoid requiring, or even inviting, hosts to modify their behavior. Maybe, if 6MAN were more responsive to the needs of both provider router operators and subscriber host users, a more elegant solution to the problems this draft is meant to address could have been developed. I don’t blame V6OPS for devising new strategies for dealing with perceived deficiencies in the protocols that 6MAN maintains. Not at all. It’s their job. I’m also far from sure there is even a deficiency here for 6MAN to consider. I can easily see how this draft essentially amounts to exactly the sort of refinement that 6MAN intended to permit when it specified IPv6 Neighbor Discovery the way it did.

--james woodyatt < <>>