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

Nick Hilliard <nick@inex.ie> Wed, 30 October 2013 22:14 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 0014B21F9FAC for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2013 15:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 R60VYcToHeSv for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2013 15:14:57 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id BC03321E809D for <v6ops@ietf.org>; Wed, 30 Oct 2013 15:14:56 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9UMEncN035321 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 22:14:50 GMT (envelope-from nick@inex.ie)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org
Message-ID: <527184D9.8070409@inex.ie>
Date: Wed, 30 Oct 2013 22:14:49 +0000
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
References: <CE8E8EC3.59F3A%victor@jvknet.com> <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <alpine.OSX.2.00.1310281905440.11422@ayourtch-mac> <CAKD1Yr0qLd7syFizEUMa6DM2a2LY6Rv5GSFyoQAs4Pir6gcNkA@mail.gmail.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <alpine.OSX.2.00.1310291443480.31066@ayourtch-mac> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <alpine.OSX.2.00.1310292030450.31066@ayourtch-mac> <CAKD1Yr1myWu7BUmcP3sJqPXFtRyGhy=Qqd2yMsYBFQjPce3GUA@mail.gmail.com> <alpine.OSX.2.00.1310292040510.31066@ayourtch-mac> <52702DC2.1080507@inex.ie> <CAKD1Yr2OTbCTTBKEe6Ktt_gF3eM1VxH1Rkk14WxTMFzdMzX-kA@mail.gmail.com> <52714CA2.2090409@inex.ie> <1383161990.2899.YahooMailNeo@web142502.mail.bf1.yahoo.com>
In-Reply-To: <1383161990.2899.YahooMailNeo@web142502.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 WG" <v6ops@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: Wed, 30 Oct 2013 22:14:58 -0000

On 30/10/2013 19:39, Mark ZZZ Smith wrote:
>> The question is why would someone use RA for multiple gateway announcement
>> when you'll get much better operational performance from a FHRP + single
>> gateway address?  And why use RA for addressing when you'll get finer
>> grained operational host control using dhcp?
> 
> It's been said a number of times in this thread. You can have client
> specific RAs that solve that problem. This is not a missing capability
> that duplicating RA functionality in DHCPv6 would then provide.

You don't have address assignment with RA: you have prefix assignment and
host address selection.  I'm sure this is great for other people, but I do
not want this behaviour on my networks, ever.  I want address assignment
via stateful dhcp.  This is a missing capability of RA.

>> Or when you need to use dhcp
>> anyway in order to make your hosts do what they need to do?  Or on server
>> farms when most of your hosts are statically addressed and it doesn't make
>> sense to have multiple gateways with different addresses - and you'll get
>> better uptime by not using RA?
>>
>> I'm not proposing to take away the option of using RAs if that's what 
>> you
>> want to do.  I'm only suggesting that for many situations, it makes more
>> sense to have a single static gateway address (optionally with multiple
>> routers using a FHRP if you need reliability) and that consequently the
>> idea of periodically announcing a selection of arbitrary gateways via RA is
>> operationally second rate.
>>  
> 
> I'd really like to know specific details of these many situations, and
> what specific benefits switching off RAs would have.

Please see my earlier email:

http://www.ietf.org/mail-archive/web/v6ops/current/msg17769.html

The standard argument of having multiple routers on a network announcing
different prefixes and allowing host self-selection is a red herring. This
is going to be an edge case because most networks are not multihomed.  A
small number are; let them use whatever they want.

The standard argument of having multiple routers on a network announcing
multiple gateways for the same prefix value is a red herring because the
failover time for RA gateway address selection cannot match that of a FHRP
based mechanism.  No doubt some people will want to use multiple gateways
addresses.  If they do, I wish them well.

If you want to run with RAs, then go for it.  I don't because they add
nothing to my production configurations except unnecessary complication.
All my networks are mtu 1500 and I don't need to tweak ND timers and all
that.  Other than assigning a defgw, the only thing that RA does on my dhcp
enabled networks is to point everything towards dhcp.  From my point of
view this is entirely pointless and if dhcpv6 had defgw assignment, I could
ditch an entire protocol.  This would be good (simpler configuration,
easier to protect at L2, etc).

For service provider and enterprise purposes, it is more sensible to
centralise configuration and have a single protocol for assigning all
network parameters than having two auto-configuration protocols doing
slightly different things in slightly different ways with poorly defined
interactions and several pitfalls if you don't know what you're doing.

> I've been in many
> situations in many networks, and when I consider my IPv4 experience (and
> also compare it to my Novell IPX and Appletalk experiences), I see a lot
> of value in having RAs provide default gateway(s) (VRRP/HSRP or not)
> information and other layer 3 parameters to directly attached hosts from
> the directly attached router(s).

Glad it works for you.  I see it as being utterly pointless, because it's
an entire protocol just to provide a single network parameter which could
just as easily be provided by another protocol which I need to run anyway
because stateless dhcpv6 has stuff that I need to provide on production
networks that RA doesn't provide.  Does this work for you as a problem
statement?  What about any of the other reasons I've provided?

> This is in comparison with the IPv4
> alternative effort of enabling and configuring a heavier and more
> resource consuming stateful DHCP server on either the first hop routers,
> or enabling DHCP relays and then having to have a redundant DHCP
> infrastructure somewhere else in the network.

stateful dhcpv4 works incredibly well in production.

> It could be argued that DHCP could be enabled and configured by default,

This is a straw man.  Straw men don't help.

Nick