Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

Owen DeLong <owen@delong.com> Sat, 07 December 2013 21:27 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D01AE424 for <v6ops@ietfa.amsl.com>; Sat, 7 Dec 2013 13:27:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.992
X-Spam-Level:
X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
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 91S2SQQMkBYt for <v6ops@ietfa.amsl.com>; Sat, 7 Dec 2013 13:27:24 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6422D1AE422 for <v6ops@ietf.org>; Sat, 7 Dec 2013 13:27:24 -0800 (PST)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB7LO7eS032573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Dec 2013 13:24:07 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB7LO7eS032573
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386451447; bh=ot0YCruiyIWPpDWNMOGBCjeMXOc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KirFIqlA8YyQFJukHmaFXkhvhHAarB6d61HpOPB1zjh2Z0vz0vvLZ96QNFBlVWZEL SXmpMRcxbcOHrwe+L9WdxEZtjanEQjjpouYAB0ds9QY15FfeG4lsxwJ0vfSSCCFH6q HMgfi3GUB0mPzLs+ef8z/qT3kViXHg4kQKJ6cBT4=
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <alpine.OSX.2.00.1312072028290.68814@ayourtch-mac>
Date: Sat, 07 Dec 2013 13:22:58 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F024FF5B-35A6-4221-952C-4A730A68C59D@delong.com>
References: <alpine.OSX.2.00.1311271353550.3903@ayourtch-mac> <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <alpine.OSX.2.00.1312060759220.68814@ayourtch-mac> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <alpine.OSX.2.00.1312072028290.68814@ayourtch-mac>
To: Andrew Yourtchenko <ayourtch@cisco.com>
X-Mailer: Apple Mail (2.1822)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 07 Dec 2013 13:24:07 -0800 (PST)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 07 Dec 2013 21:27:26 -0000

>> I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will.
> 
> It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes, and the amount of pain that the big change in the network like adding a new protocol causes.
> 
> As soon as the first number is smaller than the second one, nothing gets done.
> 
> Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6.
> 

I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's pretty trivial if you know enough to tune them properly.

If you don't know what you are doing, then you can really mess yourself up with RA tweaking that you shouldn't be doing.

However, I do not advocate IETF breaking the internet just to prevent people from breaking their LANs out of ignorance.

>> There is no single answer to why people might resist deploying IPv6, no single solution, and things that motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works.
>> 
>> 
>> 
>>> I think in this discussion are again getting into the argument of "the best solution" instead of trying to collect the properties of the RA and DHCP.
>>> My position is that single best solution does not exist, because 
>> 
>>> everyone's problems are slightly different. So, rather than preaching for everyone to adopt the single solution which is the best in one scenario and suboptimal in the other, we should be engineering a way to be able to apply different solutions in different circumstances without the overhead of double work.
>> 
>> A single solution that solves most cases is better than two different,
> 
> That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that.

Actually, the problem is that people have conflated two different problems and like to pretend that they are one.

In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem.

RAs solve the problem of telling a host which routers are available on link.
RAs also sort of solve the problem of dynamic host configuration (address, RDNS servers, DNS Search list)

For better or worse, to keep RAs very light weight, they do not provide a complete or robust solution to host autoconfiguration.
For that, you need DHCPv6 which is a protocol designed to do host configuration.

While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments. Even if we made the changes you are proposing, eliminating RAs would be unlikely in the vast majority of circumstances, at least for many years to come.

Owen