Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

Lorenzo Colitti <lorenzo@google.com> Thu, 24 October 2013 06:42 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 444A711E8109 for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 23:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW-VpwxmmnUs for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 23:42:18 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 80F8011E8140 for <v6ops@ietf.org>; Wed, 23 Oct 2013 23:42:15 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id tp5so3158904ieb.31 for <v6ops@ietf.org>; Wed, 23 Oct 2013 23:42:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JkopkNRqdhXXU1luUaU5/2KDjzSyx/QAh/ZovxD0gN0=; b=SAlr61Zn0zPcstt4+Jj6rORFax6B4rb/9mMBDhs9gQ+SeICmco/0nsK7lsdDrpLi29 Hzk6CBYSHaU7pvO1G7DBsr0tjx8cadBzaBKb0PE94PfbcUBlwjHDFsGYd/RTFBv4eaou GbG9MNzh4zLuumZ4kwNC4VxE/tXD3WWrxCMjZiq88AxZqDzo9W9bmOeBzkEsA1IdGG5A 30/0xsQWCe4FLWuzu7/OFgmrIue0CKMTaSihDzPEzm7uRMeEJDVG1s4CZ5uL9XxeyqWZ PsTEyJ08XXpeVzc46cqHS/CFyfg4eyP/QtlbCS5jFIxi1jHtdwaN4EhWSCCP4oZr+6xS baNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JkopkNRqdhXXU1luUaU5/2KDjzSyx/QAh/ZovxD0gN0=; b=du6iHJWvtctlC5Y23cVA+3RfoV56NYPonibyi9bJD7fY76yEsm7rFTLCe+uiZ4Rmnn CocOsQIqSzj1bqujf/bMPq3NmqmIylI5+Gw0zN+vfaHsuF7SdiEcJWcYpck/+n+Y9P+F xD4GWsmT8gZ64tsnAZNYrWhUmnwLvz7Y/2IDMQtz6w82nTjpXCo3nq5hkXHiIFa4RnGb ca+hQ2XcS9AIZt50LzQGptRouXVibWl44B8umBxfNin9sMAQlTByhhwLyX33zwI5t8tW ZpH+RGkvDGpKJkrcBG9aE/nn1heRaqLbeV6zxWmLaQiieo4iz/06BUf/SwIxGf7MnUap 61eg==
X-Gm-Message-State: ALoCoQnresqWJY+1hzH5lfNu61L/JXTvdzEZlmUmyCYljyEIY/PVpwpqs/1oh8VvUOzWPnvNdJAYOcyINpY1tZMbnSjHyoFB/ln1qpAMk1EpCrL48tuVU8DX6QWz9nwfrD3BvazQ9wiSfZxKWbRPp/aqOpCLqdBdvs4RFG4xtgI3E4J9gg2my1fYR2ky0eHMMfF2lMn0woNZ
X-Received: by 10.43.57.79 with SMTP id wf15mr710165icb.14.1382596934812; Wed, 23 Oct 2013 23:42:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.86.106 with HTTP; Wed, 23 Oct 2013 23:41:54 -0700 (PDT)
In-Reply-To: <CE8E29EC.59EE4%victor@jvknet.com>
References: <52689EE0.3030201@inex.ie> <CE8E29EC.59EE4%victor@jvknet.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 24 Oct 2013 15:41:54 +0900
Message-ID: <CAKD1Yr0ky0SSrhYz9R82bTO+GhrsBVL-_Uf-9sbYuLWKYpmi0Q@mail.gmail.com>
To: Victor Kuarsingh <victor@jvknet.com>
Content-Type: multipart/alternative; boundary=bcaec51dd90f2af3b504e976ef09
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, Ted Lemon <mellon@fugue.com>, Dave Thaler <dthaler@microsoft.com>, "Ole Troan \(otroan\)" <otroan@cisco.com>, "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 24 Oct 2013 06:42:19 -0000

On Thu, Oct 24, 2013 at 2:56 PM, Victor Kuarsingh <victor@jvknet.com> wrote:

> It's quite obvious that in environments like sensor nets, home nets and
> other places, SLACC/RAs supply significant value.  In other areas, like
> an operator access network (edge element addressing), it's a different
> case.  Operators, such as the one I worked or, would never (rarely?) let
> an element auto-configure itself onto the network.
>

Right - and there's the rub.

It seems to me that we have two different ways of configuring things (RA
and DHCPv6) that don't differ in functionality but differ in how suitable
they are for different environments. One mechanism (RA) is dynamic,
self-configuring, serverless and fate-sharing, and the other is static,
operator-controlled, and centralized.

Operators and enterprises want the one they feel gives them more control
and are willing to provision the infrastructure to make it reliable (e.g.,
centralized configuration repositories; DHCPv6 servers and relays; VRRP so
they don't need fate-sharing, etc.). But the one that offers more control
falls over in home networks, because the infrastructure to run it is either
not available or unreliable: there's nothing anyone can do to make the
DHCPv6 server (or the DHCPv6-provided router or DNS server) keep working if
the user has unplugged it or tripped over the power cord, and there's
nothing that can withdraw a stateful DHCPv6 lease if the original server
has been unplugged, because nobody knows the nonce any more.

I think we need to accept that neither protocol is sufficient in all
environments. We have to realize that DHCPv6 just isn't suited to dynamic,
self-organizing environments like home networks. We can keep hacking it
with more semantics like unsolicited updates, but at the end of the day
we'll simply end up with something that looks like RAs - multicast updates
to everyone on the link (equivalent to multicast RAs), configuration
requests/replies (equivalent to RS/RA), and so on. Then we'll have to
implement DHCPv6 guard to stop rogue servers, and even then there will be
no fate-sharing with routing. On the other hand, RA doesn't offer the
wealth of different option types that DHCPv6 has, and while it's possible
to do fine-grained configuration with unicast RAs, today most RA
implementations don't support fine-grained per-client configuration via
unicast RA or "RS relaying" to a central server to fetch per-client RA
information.

I see two possible ways out of this:

1. Decide a clear split between what goes into RA and what goes into
DHCPv6, and then stick to it. For example, we could say that configuration
information that is required to obtain basic connectivity on a network must
be available in RA so it can be dynamically updated and shares fate with
routing, and that everything that's not strictly required for the host's
connectivity can go into DHCPv6. I don't know if it will be possible to
draw a line here. If operators insist that DHCPv6 by itself must be
sufficient, then we have no choice but to duplicate information.

2. Attempt to say that RAs and DHCPv6 are simply containers and propose a
unified option format so we can have the same options in both of them. I
know this was already proposed once and was shot down, but I wasn't around,
so I don't know why. (CCing a few people who might know).

Cheers,
Lorenzo