Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs

Brian E Carpenter <> Sat, 20 January 2018 04:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26627126B72 for <>; Fri, 19 Jan 2018 20:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] 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 gjuyf_XP1N3F for <>; Fri, 19 Jan 2018 20:17:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D412012D7EE for <>; Fri, 19 Jan 2018 20:17:28 -0800 (PST)
Received: by with SMTP id y26so2855016pfi.10 for <>; Fri, 19 Jan 2018 20:17:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j7sFCp9LjCAW/Yfka03K3RLKHLE7MCcXimhpVDCNXcg=; b=K3sQA/bNQYqvQoA88uRVQ/O9mRetqZFClZDcpfmaIXceSakFpo3NbINSDxSCXcWM7T s87uSN8KtiTDFJuvlyi1pyla7r/XlPX0/b8eWPXYfEABPFts0RJCpXtTLpU1I8zKgRB+ 1bjAZHXSKneDbAqcOg0juB584D+EZu4m1wVAt7YM/lSFFplPyqP6U/puNQChqj4CCaqR ivm9pX+CwLpmCBWHMlhOoFxbi5dHX9YfsR+VBwlbvrqWkoKxDwDfkf8swLSHkmyTtMv5 YSWMxj/sR1UvHI1yl1qfx+b2WlKihAVT8nRpFCRukN2MRlAH7cyy7btzUnxE495MHUN2 LzSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=j7sFCp9LjCAW/Yfka03K3RLKHLE7MCcXimhpVDCNXcg=; b=t6cCbeGpHEhB9Zjl1bsksym6UIXUPrqoV6eyr7T4+RFRiXs4EGJcPKE2woBkv17qiB 3fUlhaZAb+QDsxq56VX4BWLJxamVNvUS/WQnJxCZW3qhQa1E6XsBwd021qgCP4F6ovuj XjC1jS0RmChNEUs7ywyoxykuM+dXBZnay2VqsZG8J8xcIVrjGiojaan52K6NCBo1KtLR bWwGY8tq2pTamuhZpuaRfJF8fp+D6I8uZZez6IFhQQcPaZtsWYpgpFrevqI93a8SFHYw +D0GFKKpTN8zkWhL85gQoKDxZnqL10VhyoN+DqfWYvcGfci387ElLR306wL4MGBVJSu6 Ao1Q==
X-Gm-Message-State: AKwxytdMBFWLJHhpbGAFZ99NsVVCwnp5OOQpUOdVeQQdRn9YRm2yRwV2 kr52Fjh2zkPC8R69DKVJJgYmBA==
X-Google-Smtp-Source: AH8x224+5Fdz9T+75uuZ4gLCcABFXY420nWkbMfG8MAy3rfciZPkb8jPrF2n+P/8npAsOBXt8Cy5LA==
X-Received: by with SMTP id h191mr879668pfe.149.1516421848151; Fri, 19 Jan 2018 20:17:28 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id v7sm15480658pgs.83.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 20:17:27 -0800 (PST)
References: <> <> <066901d385ab$64d663b0$2e832b10$> <> <> <> <058c01d39188$cb3f7630$61be6290$>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Sat, 20 Jan 2018 17:17:30 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <058c01d39188$cb3f7630$61be6290$>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Jan 2018 04:17:31 -0000

On 20/01/2018 13:51, wrote:
>> Yes, I think that's the problem.

Just to restore a little context, Lorenzo wrote that in response to something I said:

>>> Lorenzo, are you saying that the requirements in this draft need to be
>>> scoped? That doesn't sound unreasonable, but if so, what would the
>>> scoping text look like?


> The basic question comes down to this: Does the WG think building a basic set of requirements "pretty much" _all_ IPv6 routers should run a worthwhile concept, 

a) I think you mean "should be able to run if needed, must be configurable on/off".
b) If you can provide scoping text that defines which routers are covered, rather than a generalisation like "pretty much all", we could stop arguing.

> or -- is it that there are always going to be too many corner cases we can think of, too many exceptions to try to account for, to make this useful work? In other words, can we hope for an actual set of base IPv6 features with which to create an interoperable network, or is everything, always, going to be a "one off?"

All IETF standards are voluntary, so we can never get away from the corner cases and exceptions. IMHO the best we can do is as above: define scope, define recommendations, require configurability.