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

Ted Lemon <mellon@fugue.com> Thu, 24 October 2013 13:47 UTC

Return-Path: <mellon@fugue.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 043BB21E8093 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2013 06:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 TyO4ol6YRqjn for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2013 06:47:17 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8211E81C9 for <v6ops@ietf.org>; Thu, 24 Oct 2013 06:44:50 -0700 (PDT)
Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 88D5B23802F4; Thu, 24 Oct 2013 09:44:43 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <CE8E8EC3.59F3A%victor@jvknet.com>
Date: Thu, 24 Oct 2013 09:44:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com>
References: <CE8E8EC3.59F3A%victor@jvknet.com>
To: Victor Kuarsingh <victor@jvknet.com>
X-Mailer: Apple Mail (2.1816)
X-Mailman-Approved-At: Sat, 26 Oct 2013 22:18:26 -0700
Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "Ole Troan \(otroan\)" <otroan@cisco.com>, Dave Thaler <dthaler@microsoft.com>
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 13:47:32 -0000

On Oct 24, 2013, at 8:55 AM, Victor Kuarsingh <victor@jvknet.com> wrote:
> From: Lorenzo Colitti <lorenzo@google.com>
>> 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).
> 
> [VK] This seems like an intriguing idea. Would this mean that every option must go into each container, or that there will be a common set of options which go into both, and perhaps exceptions go into one or the other? (On that latter part, I guess that line of thinking gets us back to where we are).

I think the main reason we didn't do this is that it seems like a mistake to have two mechanisms for delivering the same information.   If we really think RA is the right way to do all host configuration, why not just add a stateful mode?   If we really think DHCP is the right way to do all host configuration, why not just add support for configuring routes?   Stateful RA could actually be piggybacked onto DHCP, so that the router just creates a DHCP message and forwards it upstream, or answers it locally, depending on the circumstances.

Doing what's proposed here means that code on clients needs to be four times more complicated than it would be otherwise.   Putting DNS server options in RAs was a bad idea.   Continuing down that path is a worse idea, particularly since this proposal would mean there'd be two ways of representing DNS server information in RAs.

If we really got this wrong, we should fix it, not make it worse.

Anyway, that's the rhetorical position I'm going to stake out for now.   I'm curious to see if anybody can come up with a reason to disagree that doesn't simplify to either "I hate RA" or "I hate DHCP."