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

Nick Hilliard <nick@inex.ie> Thu, 24 October 2013 04:15 UTC

Return-Path: <nick@inex.ie>
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 0EFC711E811B for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 21:15:43 -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 40IYMY+VLaZb for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 21:15:42 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 32E4311E8109 for <v6ops@ietf.org>; Wed, 23 Oct 2013 21:15:41 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from vpn-250.int.inex.ie (vpn-250.int.inex.ie [193.242.111.250]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9O4FTN3024312 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 05:15:31 +0100 (IST) (envelope-from nick@inex.ie)
Message-ID: <52689EE0.3030201@inex.ie>
Date: Thu, 24 Oct 2013 12:15:28 +0800
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>, "Ole Troan (otroan)" <otroan@cisco.com>
References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <alpine.DEB.2.02.1310211454090.26825@uplift.swm.pp.se> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <alpine.DEB.2.02.1310221511520.8663@uplift.swm.pp.se> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <alpine.DEB.2.02.1310230533340.1838@uplift.swm.pp.se> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <1382556056.28376.YahooMailNeo@web142505.mail.bf1.yahoo.com>
In-Reply-To: <1382556056.28376.YahooMailNeo@web142505.mail.bf1.yahoo.com>
X-Enigmail-Version: 1.6
X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804
X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3
X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee
X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24.
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "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 04:15:43 -0000

On 24/10/2013 03:20, Mark ZZZ Smith wrote:
> RAs are prehaps misnamed. They're not really router advertisements,
> they're advertisements (typically) sent from routers. View them as layer
> 3 configuration protocol packets, because they do far more than
> advertise a default router, and don't even need to advertise a default
> router to be useful.

I know what RAs are.  Both protocols provide info to network hosts
necessary for functional ipv6 connectivity.  They have different
approaches, but they are both lan configuration protocols.

If you feel that SLAAC+DHCPv6 or SLAAC only is the right thing for you,
then that's great and I'm really happy for you.

There is a tiny amount of protocol glue missing which would allow dhcpv6 to
act as a fully functional standalone protocol, and the various attempts to
introduce this glue have been shot down repeatedly, mostly on the basis of
arguments like "how do you expect your network to work when critical
components of your network are broken?", "we don't like duplication of
functionality at the IETF (but we'll ignore all the other duplicated
functionality in other ietf protocols)" or "polling sucks".

None of these points address the core issue which is that there are a lot
of operators who have a strong preference to use a single lan configuration
protocol instead of two protocols with strongly overlapping functionality
and an ambiguous and poorly defined interaction model.

There is no reason for DHCP not to to be standalone-capable, so that
operators can make up their own minds about what to use on their networks.

I completely understand that you want to use SLAAC on your networks: please
stop insisting that I run it on mine.

Incidentally a couple of minutes ago, Andrew Sullivan just spoke these
words about the IETF at IGF2013 in Bali:

"We're not in the business of telling people how to run their networks".

Nick

> They can be use for:
> 
> - changing host MTUs, instead of individual manual configuration on each host
> - announce on-link presence of prefixes, exclusive of whether hosts have addresses within the prefix, instead of individual manual configuration on each host
> - adjust neighbor discovery parameters (e.g., timers), instead of individual manual configuration on each host
> - announce prefix(es) to be used to generate SLAAC addresses, instead of individual manual configuration on each host
> - indicate to hosts whether to use DHCPv6 or SLAAC or both (during a transition between SLAAC/DHCPv6 or vice-versa), instead of individual manual configuration on each host
> - advertise a default router, and an associated lifetime, instead of individual manual configuration on each host
> 
> 
> 
> 
>> networks.
>>
>> Nick
>>
>