IETF Logo Mail Archive

Re: [v6ops] Making RDNSS a MUST?, hum v2

Lorenzo Colitti <lorenzo@google.com> Thu, 06 April 2017 16:19 UTC

Return-Path: <lorenzo@google.com>
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 0AE051276AF for <v6ops@ietfa.amsl.com>; Thu, 6 Apr 2017 09:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 ws3Pm3QqZrWP for <v6ops@ietfa.amsl.com>; Thu, 6 Apr 2017 09:19:45 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABB3129549 for <v6ops@ietf.org>; Thu, 6 Apr 2017 09:19:36 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id d188so46089903vka.0 for <v6ops@ietf.org>; Thu, 06 Apr 2017 09:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+6bI9KfnUVOGmgSLpZPAJ68+YrBqQq3RP0Fn1syXuns=; b=s5mkClcvvfc0+Fn2VCg9UB7i8UEyDuiJww5x7ud4lT3q8YJmXFS37IYh1GP9WeGkpy sH4tYwWO/NXc3L3lFoPJtX3iZO4mUFq/3KNB6Nke1rvuIoDy7Yb0shB0UTOn7F0bQZJY jTSk2PN208k9Nj1yZcDNYNSgLNfdecLBmRWukCIzCnVDwbmH8HQgc8Dgr4dW0XfqOIUa NnTST4HAPn/MdDQ+2DrnK+FZzFr3uz48JjkugCukzwQykP3kofFUH89d15iQnWFcZ7Qo m3m0f5/FZyf2C4ADzR75hUFMgQ/vIq5XUHC9877Y8v4B2VhIT0smDUJNmfOx7g1gE+bS NNGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+6bI9KfnUVOGmgSLpZPAJ68+YrBqQq3RP0Fn1syXuns=; b=WxaT+ZRMjlNV1z/y6yaEQPVRjEG92lmxA4eY22tbAEljAFdMgYOnWgbaczThNbgAkS zEgvv5SRwrYEZcaH/O7fPKmpKISoT7G4A2s6goSAXvrB68A1RPg5/ODe3+D0Aktx76no VRbb11meV+Fws1Wwx9eh9ougneRodvE8SQV+V+WzNAk7FLc0e/wnjju2x2WHZ+SUZ2Xn uUl+gH1MQeRyKtyuaOIDNhtluij13suu1igoSEA70sdy+MBnYmjMSyxEr77W2rXtbRQj OyFUY9OGVPOzremsSsyjR49DFZQ0c0PrYOREQl67QVjVyqRlxWDIlN392HVDCw2Jbce6 +DKg==
X-Gm-Message-State: AFeK/H2Top3K0hdzDfvzHNNylxQixqQdHK9OwWRo2anqGjmgn2Q94EOLZ6GQFbnN0/oYBey8sSvmea52aG5X1J7L
X-Received: by 10.31.107.93 with SMTP id g90mr16138056vkc.155.1491495574868; Thu, 06 Apr 2017 09:19:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 09:19:14 -0700 (PDT)
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <CAKD1Yr2FMvpgjSPv-1cdWQGTFzB8oRCvm=57MgOv=tH11awpOA@mail.gmail.com> <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> <CAJE_bqfXJG+-CXZnOaeerKZMpk-TnZxgv=onJSudX6oYQBo7_w@mail.gmail.com> <m1cvhA2-0000G1C@stereo.hq.phicoh.net> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <CAN-Dau1=9HXni9XydcWOO6r8SKrOeOXfqo=Vx=NUoNtUze8dfA@mail.gmail.com> <F94218CB-2F61-42D1-AFBC-8F2F18264C4F@fugue.com> <CAN-Dau3KpVyyVZZcM26+SN867XF+SnsC7vj2TQww2m-CUs9YuQ@mail.gmail.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <A7E71D2A-33CE-4869-B51F-5D345D118E37@gmail.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <CAOSSMjUPRSvEmx6KGLGLZwZbMLYVYsG-ik1w4N1q4RHcZHt6=w@mail.gmail.com> <CAAedzxqP98efWiEh4fcNeRvzUuaUvH+O-pf6322gQ+HJ40pBRg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 07 Apr 2017 01:19:14 +0900
Message-ID: <CAKD1Yr1AY2uEAHmx_f5EGnzcoju8qxxAxO50EFzvDjoKV1dv6A@mail.gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: Erik Kline <ek@google.com>, Timothy Winters <twinters@iol.unh.edu>, IPv6 Operations <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Content-Type: multipart/alternative; boundary="001a11478dd0ece8a2054c81df8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/sUhBEqXcX4rjGk7IBpqImadSdJI>
Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2
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: Thu, 06 Apr 2017 16:19:47 -0000

On Thu, Apr 6, 2017 at 11:12 PM, STARK, BARBARA H <bs7652@att.com> wrote:

> > As a vendor of a device that is sometimes a router I am opposed to, and
> have precisely zero interesting in,
> > implementing a DHCPv6 relay or server function.  It adds nothing, and
> can actually break clients that prefer
> > DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.​
>
> [...]
>
> 2. You say you don't want to break clients (hosts) that prefer DHCPv6 DNS
> over RDNSS. Since you oppose DHCPv6 relay or server (in the absence of a
> qualifier I take server to mean stateful or stateless -- so you oppose both
> types of server?), does this mean you believe the way to prevent breakage
> is to only offer RDNSS to clients (so their preference is irrelevant, and
> they had better also implement RDNSS in spite of their preference)?


I think this is the sort of thing that Erik opposes. I thought I had sent
it to the list, but actually it was an off-list reply.

====
The Android phone in my pocket is a router when I go to the coffee shop
every morning and turn on tethering. As the maintainer of that code, I
absolutely do not want to spend software engineering time writing a DHCPv6
server that is not only less capable than the RDNSS implementation that we
have now, but also degrades functionality.

The reason it is degrades functionality is that with stateless DHCPv6 it is
impossible to implement even such basic things as "tell the client that its
DNS server is now gone because the cellular network went down and came back
up with a different prefix when you temporarily lost cell coverage". This
works today using RDNSS, but if we implement DHCPv6, this will stop working
for clients that support DHCPv6, even if they also support RDNSS.

   1. Client gets DNS addresses from both RDNSS and DHCPv6, and prefers
   DHCPv6 due to RFC 8106.
   2. Upstream goes down. We deprecate the prefix (we can't make it invalid
   because of the 2-hour rule), and declare the DNS servers invalid. We can't
   do anything about DHCPv6.
   3. The upstream comes back with a new prefix. We announce the new DNS
   servers using RDNSS. But the client still uses the out-of-date
   DHCPv6-provided DNS servers, because RFC 8106 says it should prefer DHCPv6
   over RDNSS.

I cannot live with breaking user experience like this.
====

v2.23.0 | Report a Bug | By Email