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

Matthew Petach <mpetach@netflight.com> Tue, 07 January 2014 03:11 UTC

Return-Path: <mpetach@gmail.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 A326E1AE3E4 for <v6ops@ietfa.amsl.com>; Mon, 6 Jan 2014 19:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.643
X-Spam-Level: *
X-Spam-Status: No, score=1.643 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] 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 PzdeE2AQxtMW for <v6ops@ietfa.amsl.com>; Mon, 6 Jan 2014 19:11:06 -0800 (PST)
Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A009F1AE3E0 for <v6ops@ietf.org>; Mon, 6 Jan 2014 19:11:06 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id rq2so19339183pbb.31 for <v6ops@ietf.org>; Mon, 06 Jan 2014 19:10:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=S9k7x3GTAcIDxNxmxyYuuBr5qr6pCadA/xnzJ0nIPuc=; b=ZzYZt0XqzKKFyzFqAWqbUTIccHmv+yycAfR/lZ//oPynp++qKtLnONZxyBWN+LI/W4 sIrgmCAzITlYLN45tuojLnnrqRjGKZNVKvC/ZngmSJiECX9EpvIaY73fkezLHQTB5XU4 b7cTrr6FIJbx86Xl4zFHMQJgEyIwg16g8ROiBZs7y+kUO6YRanPabw4QtLpUFPV2h4ee aynprR6XZU/FmfDw5vwQoudQOQpBBMV3IS+haWH2p+IEh/9yp2jimIJqo05AdfiRq3ek GF5pns5K+8tCcwtC2hkH4bUI8wuelkmMmxSA2+et048AmJXEJktib1hPUeAazaj5CVcq IiiA==
MIME-Version: 1.0
X-Received: by 10.66.123.5 with SMTP id lw5mr2157152pab.83.1389064258132; Mon, 06 Jan 2014 19:10:58 -0800 (PST)
Sender: mpetach@gmail.com
Received: by 10.70.1.130 with HTTP; Mon, 6 Jan 2014 19:10:57 -0800 (PST)
In-Reply-To: <98CACA9B-AD61-460A-93AC-D5EEA1176706@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>
Date: Mon, 06 Jan 2014 19:10:57 -0800
X-Google-Sender-Auth: -6T0RcfAf7I4EM1DFrfMusZNz5E
Message-ID: <CAEmG1=qLxqWdB8JR4rbAS-TyqQtPcGnZvVb7DSBCrmFcrm0vUA@mail.gmail.com>
From: Matthew Petach <mpetach@netflight.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bf0e7c8ad212d04ef58b988"
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 03:20:35 -0000

On Sun, Dec 8, 2013 at 11:38 AM, Owen DeLong <owen@delong.com> wrote:

>
> On Dec 8, 2013, at 11:22 , Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote:
>
> > On 08/12/2013 19:40, Owen DeLong wrote:
> >> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko <ayourtch@cisco.com>
> wrote:
> >
> > ...
> >>> I think you nailed it here: With RA you *discover* the routers
> available on the link, with DHCP in legacy IP, you *configure* them.
> >>
> >> No, with DHCP, you discovered what some remote host rumored them to be.
> >
> > I don't think we should be having this argument. We should be
> > trying to write down objectively the type of scenarios where
> > DHCPv6 is applicable, the type of scenarios where RA-only is
> > applicable, and the type of scenarios where both (simultaneously)
> > are applicable.
> >
> > There's no right or wrong answer here.
> >
> >   Brian
>
> In IPv6, as I read the RFCs, there's no valid way for a host to know that
> it is supposed to get information from a DHCPv6 server unless it receives
> an RA with the M and/or O bits set.
>

[been sitting on this for several days, pondering whether or not to send
 it out.  finally decided it's not in my nature to not be impetuous, so
after
 careful consideration decided I needed to go ahead and continue to be
 impetuous, and send it out.  apologies for it now being a very stale rant.]



As I read this thread, I try to avoid banging my head into the
wall in frustration.

People seem to be replying based on a notion that the current
set of RFCs define the way the future must be.

That is not a true notion.

There are multi-billion dollar companies that have a need
to operate their networks in very specific ways.  If those
ways are not supported by the RFCs, they will pay money
to vendors to have options added to the software to allow
them to operate their networks in that way.  See for example
the filter-aaaa-on-v4 option in BIND; while there was resistance
to the idea that DNS servers be configurable to not
return quad-A records to v4 queries, in the end, the
needs of the business won out.
There is a
similar dynamic at play here.  There are very large networks
that require DCHPv6-only implementations to work, and they
will get software to support that model, one way or another,
because without it, they cannot move to a dual-stack
environment.  Not from a technical perspective, of course,
but from an accounting and control perspective; the DHCP
server must be the source of both v4 and v6 address assignments,
and the only such source, in order for the staff to know for certain
who has been assigned a given address on the network.

You can argue back and forth until you're blue in the face;
but it's rather like trying to persuade a glacier to stop
advancing by pointing a hair dryer at it.  There *will* be
networks that will be run with address assignments from DHCP only,
both for v4 and v6, and it can either happen with support from the
RFC-discussing community, or it can come via paid-for-knobs in
software to allow for non-RFC DHCPv4+DHCPv6-only environments.

Remember, RFCs are guidelines only, not laws, and
if the guidelines don't support the operational needs
of businesses, they _will_ bypass them in order to
keep the business functioning.

Very large scale enterprises are well grounded in
the model of having the host config say "obtain
addresses dynamically", and having the source
of those addresses be an authoritative box which
tracks and accounts for all addresses given out.
The notion of clients selecting their own address
does not work in those environments, and trying
to insist they alter their business to fit your idea
of how things should work is less than useful.



>
> 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.

Matt



>
> Owen
>
>