Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

Lorenzo Colitti <lorenzo@google.com> Tue, 21 November 2017 06:48 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77801275F4 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 22:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 NlgawPc4Y8J0 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 22:48:09 -0800 (PST)
Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 75E2B12751F for <6man@ietf.org>; Mon, 20 Nov 2017 22:48:08 -0800 (PST)
Received: by mail-yb0-x232.google.com with SMTP id g184so4052051ybg.3 for <6man@ietf.org>; Mon, 20 Nov 2017 22:48:08 -0800 (PST)
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=SQ+jf+k5U0corcBjvGIXPcHmyQRbZWjIrr+icRwU0Qk=; b=SENsDxiE2zDlm7ZS0gj1E675tL0iXu976bGBQk66RdbBeCmuTNx6gfSWa9IKlIPL1b FtpxboHezUnr0ftCq/NoSTR27+z3FBUJogbsGZN9TdbP6NczXrgK5IhHlNdCw2Gwgww4 BAdJH3TsvdpiGqIBdR9aaxZGQZmsTGjEW6D9xPiqkngjdVKh3t9LyOc7//3VvF0IpH2f d7rm4IEuRG2he93D5ovKVf7SX6JYrp9RVSQCsD/YbO7D55RsbQIgnG7djPXAU4KqQNHS eQioXQ5TZuR4IycIyrnfLH9roRGqDmEQ4b4vQTu8cN5sYn6QCRuxL4fL6N/lU7Lhz2sJ pUTw==
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=SQ+jf+k5U0corcBjvGIXPcHmyQRbZWjIrr+icRwU0Qk=; b=pBTkotWO5wiNcTrRdTkyiMjAU4ZHnx3w2kv7Ny3baE/D2nsjIrLDeGzhAK2BgxsIdC JH7WlxP4P8uAf42Yn9hA6SB2lGlhTeQhDt60O/3cUR7g2lDTeKWEeYZ4745kMf/tgaFu 5mm0vHc2yxdz1AzyP+kvBgn1ZN5qOHLCblnAMl455I+4SPfHShwKVSEOEwYhTSj6Awqw cq0/mNHckqd2m2Ffk3QJUluW8N+tC6012ZZSv5JtcnlWb0HC4R6QD3YqPHpcXRZH5lqY tmnDHkYag/55By8oRNoPTdAxqSmqDAgD3mOSUs+MLSrIaFhFhwQGw/EOnmIK8qpCbI0l B/XA==
X-Gm-Message-State: AJaThX5t8kr8x2CT62ginkZjo/O2rRpnPgDHUnW/nJo13qF1fqrUCbMh Q7gqtsMjwpDdEedkzU3rqZE7l/bfowvVgUaayGHDWQ==
X-Google-Smtp-Source: AGs4zMaW8QvqdgK5DImGhQXoeexE+HjuOwVIie6ut7k44jcd1tCpEmfSpLGzNSrzFMqSd2tGOGrMSYfkRFBQrZEgNHE=
X-Received: by 10.37.203.85 with SMTP id b82mr6452268ybg.57.1511246887209; Mon, 20 Nov 2017 22:48:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.4.194 with HTTP; Mon, 20 Nov 2017 22:47:46 -0800 (PST)
In-Reply-To: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 21 Nov 2017 15:47:46 +0900
Message-ID: <CAKD1Yr1+a+Bg3N=pX5_X2vhvkf50hY7N_Ay=aQQyq5ogsEWWMw@mail.gmail.com>
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05bdcce243cb055e789515"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/L9PI4WI6YkAajCWBf3RmkBA2Sr0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 06:48:12 -0000

On Tue, Nov 21, 2017 at 6:40 AM, Templin, Fred L <Fred.L.Templin@boeing.com>;
wrote:

> I would ask these discussion lists to consider what is it that you really
> don't
> like about DHCPv6. Maybe you think it is ugly.


As generally implemented and deployed, I think the main things that are
wrong with DHCPv6 are as follows. Note that these are not necessarily
limits imposed the protocol itself, but they are definitely limits imposed
by the implementations and how people typically deploy them. As such, the
following are not required to be true, but are only true in practice in the
vast majority of deployments.

   - In stateful form:
      - Inability to support multiple sources of information (the client
      picks the first lease it gets).
      - Very difficult to update devices when network changes because it's
      fundamentally based on leases and renews and RECONFIGURE is not (widely)
      implemented.
      - Makes possible stateful address assignment of individual IP
      addresses. It's really not a good idea to rely only on this for IP
      addressing, but there are decades of operational practice around
it in IPv4
      and old habits (and legacy deployed systems) die hard.
      - Typically deployed using relays and centralized assignment, which
      is very unsuited to topology changes.
         - If all you have is a central addressing server, you don't want
         to bother that server with constant topology updates from all over the
         network so it can update the hosts.
         - Also, if the topology changes enough, the server might even be
         unreachable from some hosts.
      - In stateless form:
      - Very hard to update devices when anything changes on the network.
      The minimum in the stateless DHCPv6 RFC is 10 minutes, which is *way* too
      long for certain types of networks like mobile hotspots.

The inability to update hosts with new network information is a crucial
weakness because it forces networks to appear to hosts as if they never
change. But networks change all the time. If you can't update the hosts on
a timely basis about a changes, either you never change the network, or you
have an outage, or you lie to the hosts. So we end up with things like VRRP
and NAT to ensure the host never sees the network change.

NAT, of course, is the ultimate way of never changing anything - you could
deploy IPv4 by assigning every host on every network 192.168.1.2 (gateway
and DNS server 192.16.1.1) and just NATing everything with layer-2 aware
NAT.