IETF Logo Mail Archive

Re: [v6ops] Making RDNSS a MUST?

Tim Chown <Tim.Chown@jisc.ac.uk> Tue, 04 April 2017 13:18 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 13827124282 for <v6ops@ietfa.amsl.com>; Tue, 4 Apr 2017 06:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level:
X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 tjh4kq8GlJUK for <v6ops@ietfa.amsl.com>; Tue, 4 Apr 2017 06:18:44 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239D5120725 for <v6ops@ietf.org>; Tue, 4 Apr 2017 06:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491311544; bh=pwv1MmaZcBaxwRm+kgDkVE72Ls8/tP/J0TBaqQdtDkc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=hS6NsY4wLDEi8+pUiZgqcS+/dny/0vpAQ+TE93qYK3K9x0peJpDoIOkM3kFP0F1Hr8k2IhHLbXvqwBfWsE59n9fpo0xQ3nBAFRnef5tiYCwSzmkzcpQtbHqEzJXETPfXNo8+HK3laSy9Rq7CL0r04xB/aGBH+w6dZDMcp3sH8AA=
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0049.outbound.protection.outlook.com [213.199.154.49]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-104-i0A3MB_PNmuYTqNehpWJ5w-1; Tue, 04 Apr 2017 14:12:20 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 13:12:19 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Tue, 4 Apr 2017 13:12:19 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Lorenzo Colitti <lorenzo@google.com>
CC: Ted Lemon <mellon@fugue.com>, IPv6 Ops WG <v6ops@ietf.org>
Thread-Topic: [v6ops] Making RDNSS a MUST?
Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAAJQYCAAUf3gIAABLgA
Date: Tue, 04 Apr 2017 13:12:19 +0000
Message-ID: <C5E7A978-ADDE-4530-92D7-699316B8DA3B@jisc.ac.uk>
References: <CAKD1Yr2FMvpgjSPv-1cdWQGTFzB8oRCvm=57MgOv=tH11awpOA@mail.gmail.com> <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <DE5EF8D8-A1FF-4CAF-A0D8-6AAF60FBD4E8@delong.com> <ec45051d-caf4-0675-f696-711dea582dbd@dougbarton.us> <bc6862bf-0cff-dc78-bd54-a5d85771c4dd@gmail.com> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <CAKD1Yr17EL2zv7REPxT5UM9bO7A4io7F0v995JDEULZM_n_exg@mail.gmail.com> <a844c9e3-0f72-6353-5634-a380bb1850ed@gmail.com> <58E253B4.9010501@foobar.org> <CAO42Z2zi4rBZ1QCJ9MBQnvXJX1_1QpMQphT7Nxbo4QB1Jxot5w@mail.gmail.com> <m1cv4MA-0000HqC@stereo.hq.phicoh.net> <alpine.DEB.2.02.1704031844212.27978@uplift.swm.pp.se> <EA4E5D14-B503-4287-B35C-17ECF65CCC44@fugue.com> <CAKD1Yr3bNdw92+j85MxKwjSem82yKOrD_pLpZT=gffXRgT+GCg@mail.gmail.com>
In-Reply-To: <CAKD1Yr3bNdw92+j85MxKwjSem82yKOrD_pLpZT=gffXRgT+GCg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [194.82.140.195]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:6FvPMCyHbAmfuhpL1ZUb34HWptWEBhMZpg2EmxzQM0T0GsF77g3LEM1357cyOZ1uVWbJiIaBxI1JAXWgZPST8wjtAZN98omRH2yfGH796BB3wcbwVIALoMFyhYsuY1+EN+UCthvjnHr/DyvGKL3DxTftKvNQeXrQ2m4OtitYP7FhiUFyk0knp63c/kxqbFkgRY1kPemyPOGmgmTsrKZuZm6vwcyGaClO9NTRJ/nzC/1aq27YaOvCLSfh4TUjEvOiELtWxRd+MtGLMsHo3Zr/ksZD7Hz5GtP/Q5KsRy1VgrpejwjghSBkywsInUrhn/MG/TNbs+knq1V0Ea7h+Uzswg==; 20:zRpsKaJ2qejS26kIuc2AK35PjVzLvwYzZN1hQuGZt5D3ZVz8Ut4+INjzCENU0av0l7eDStwNoyWBZvpSZFa0CJYzyDKsYLirGA/BXsScob8EkAnQn/WV/pxKtPNzGbfz6CUMQlYMckLzXciB2dUKtvPZ4WhqBq9sbk9VWdXJbo4=
x-ms-office365-filtering-correlation-id: ccd6edc0-aef7-4f2b-3f4a-08d47b5c3923
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1140;
x-microsoft-antispam-prvs: <AM3PR07MB1140646A0ECD420F470C2373D60B0@AM3PR07MB1140.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140;
x-forefront-prvs: 0267E514F9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39840400002)(39400400002)(39450400003)(24454002)(377454003)(38730400002)(189998001)(8936002)(66066001)(53546009)(6512007)(86362001)(57306001)(6246003)(53936002)(81166006)(4326008)(8676002)(3280700002)(33656002)(229853002)(5660300001)(50226002)(25786009)(36756003)(6436002)(54896002)(3660700001)(93886004)(2906002)(5250100002)(6916009)(42882006)(3846002)(2950100002)(102836003)(6116002)(7736002)(236005)(54906002)(99286003)(6486002)(2900100001)(6506006)(74482002)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 13:12:19.1290 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140
X-MC-Unique: i0A3MB_PNmuYTqNehpWJ5w-1
Content-Type: multipart/alternative; boundary="_000_C5E7A978ADDE453092D7699316B8DA3Bjiscacuk_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ueyeTq5Sf_l1U6OA8TCzN4mL1ZM>
Subject: Re: [v6ops] Making RDNSS a MUST?
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: Tue, 04 Apr 2017 13:18:46 -0000

Hi,

On 4 Apr 2017, at 13:55, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:

On Tue, Apr 4, 2017 at 2:21 AM, Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
This is frustrating.   It seems clear to me that requiring support for RDNSS would improve the situation.

+1

As a reminder: the original question in this thread was very simple: do we have rough consensus to say that hosts MUST implement RDNSS?

Given the strong opposition from major host OS developers, and others on this thread such as Barbara and James, I really don't see us getting to consensus that hosts MUST implement DHCPv6. Therefore, in practice there are only two feasible options:

  1.  Don't say anything, and have no mandatory mechanism that operators can rely on. Some network/device combinations won't work.
  2.  Say that RDNSS is a MUST, and provide a mandatory mechanism that network operators can rely on, even if it's not the one they like the most.

The question is not whether we prefer DHCPv6 or RDNSS. The question is whether we want to do #1 or #2.

I’m seeing strong support for RFC6801 RDNSS as a MUST. Personally, I would like to see this, for clients and routers, in RFC6434-bis and draft-ali-ipv6rtr-reqs respectively.

And that would give one MTI method to (on paper at least!) break the current deadlock.

But that doesn’t rule out a statement on *stateless* DHCPv6 support, does it? RFC8601 explicitly discusses what to do in the presence of both mechanisms, and iirc says to place a resolver address learnt by DHCP ahead of any learnt by the RDNSS option, effectively preferring stateless DHCPv6 if present. While I personally believe the RA-based option is technically better, I also see enterprise network admins running IPv6 today who are wondering how they’ll configure (say) NTP server settings, or other settings only available by stateless DHCPv6 and not via RAs. What’s the answer for them, as we move to IPv6-only operation?

Tim

v2.23.0 | Report a Bug | By Email