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

Owen DeLong <owen@delong.com> Tue, 07 January 2014 18:13 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 B8D281AE0FB for <v6ops@ietfa.amsl.com>; Tue, 7 Jan 2014 10:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level:
X-Spam-Status: No, score=-2.538 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
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 hQS1fSicCErC for <v6ops@ietfa.amsl.com>; Tue, 7 Jan 2014 10:13:34 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8D21AE0FA for <v6ops@ietf.org>; Tue, 7 Jan 2014 10:13:33 -0800 (PST)
Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s07IAoMw026234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Jan 2014 10:10:50 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s07IAoMw026234
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389118251; bh=BEG7B7DFtvBoU+itYWWYlbYSWH0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=s+kHz6ujedvyDzNt2UcxnszC1WnFqNs1yPOkBZEj5LXLIqLSUOHuGuuO3OcdfWnoH zUomotpXlHeCCSz1P3FmuV/A0i8B54Up8g2LI++M/gXeExg1Osbwc4RaVLHuk0ojXO V25fZL+V95Ktl79Gb5igk3ruPHtVGqhwY6HyjKso=
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1F9590A-3028-4219-9914-A098DE2E16B3"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAEmG1=qLxqWdB8JR4rbAS-TyqQtPcGnZvVb7DSBCrmFcrm0vUA@mail.gmail.com>
Date: Tue, 07 Jan 2014 10:10:49 -0800
Message-Id: <0570E136-702E-4200-9C7F-528A9A6281C7@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> <F024FF5B-35A6-4221-952C-4A730A68C59D@delong.com> <alpine.OSX.2.00.1312080643090.68814@ayourtch-mac> <B561C767-677A-4A37-BA69-EB24951B2817@delong.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <CAEmG1=qLxqWdB8JR4rbAS-TyqQtPcGnZvVb7DSBCrmFcrm0vUA@mail.gmail.com>
To: Matthew Petach <mpetach@netflight.com>
X-Mailer: Apple Mail (2.1827)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 07 Jan 2014 10:10:51 -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: Tue, 07 Jan 2014 18:13:37 -0000

> 
> As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only and Both.
> 
> The scenarios where RA-Only make sense are any scenario where you do not need greater control of the client configuration than Prefix information, routing information, and DNS resolver addresses and search strings.
> 
> In any scenario where you need to supply the host with more configuration information on a dynamic basis, DHCPv6 is also required.
> 
> Also, if you want dynamic DNS updates, deterministic assigned suffixes, etc., these fall into the DHCPv6 realm.
> 
> It's really as simple as that as near as I can tell.
> 
> If you want to run without RAs, then you are into the realm of static configuration. I, personally, do not see this as a problem.
> 
> Or, you're a company with tens of thousands
> of desktops, where static configuration is not
> a viable option, but control over address 
> assignment from central servers is a must;
> in that environment, DHCPv6-assignment-only is 
> a reality, and will exist; it is already being explored 
> today, and to to deny that it is coming is equally as
> useful as cursing the coming of nightfall; it
> will happen, with or without your agreement
> or support.
> 

We are talking about two different things…

DHCPv6-assignment-only is possible today. It is what happens if you set the M bit in the RA. DHCPv6 will then have full control of address assignment.

What is not possible today is to do that DHCPv6 assignment without receiving an RA to instruct the host to do so.

Why is that a problem for the network environments you have described?

As to getting software to do it, that’s not really the problem. The problem is that there’s already lots of deployed hardware and software that is implemented as defined in the current RFCs.

It’s the elimination of RAs that is problematic. Using DHCP exclusively for address assignment isn’t difficult. Adding routing information to DHCPv6 wouldn’t be all that difficult.

Eliminating RAs from the process would require a major change that would likely pose some level of compatibility problem with existing deployments.

Owen