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

Mark Andrews <marka@isc.org> Thu, 09 January 2014 03:28 UTC

Return-Path: <marka@isc.org>
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 7E82F1AE0D7 for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 19:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level:
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 kB_9t9tjfIDS for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 19:28:28 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 08FD81AE053 for <v6ops@ietf.org>; Wed, 8 Jan 2014 19:28:28 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 2E4E92383A7; Thu, 9 Jan 2014 03:28:06 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4624C160446; Thu, 9 Jan 2014 03:38:31 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B7899160389; Thu, 9 Jan 2014 03:38:30 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 77E84C97CF5; Thu, 9 Jan 2014 14:29:19 +1100 (EST)
To: Matthew Petach <mpetach@netflight.com>
From: Mark Andrews <marka@isc.org>
References: <CAEmG1=rRYwJaZp3qYF47=263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com>
In-reply-to: Your message of "Wed, 08 Jan 2014 18:56:02 -0800." <CAEmG1=rRYwJaZp3qYF47=263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com>
Date: Thu, 09 Jan 2014 14:29:18 +1100
Message-Id: <20140109032919.77E84C97CF5@rock.dv.isc.org>
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: Thu, 09 Jan 2014 03:28:30 -0000

In message <CAEmG1=rRYwJaZp3qYF47=263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com>
, Matthew Petach writes:
>
> On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong <owen@delong.com> wrote:
>
> >
> >
> >> 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?
> >
>
>
> I'm sorry, it's been a really busy week, so I'm a bit behind in
> following up to the people who have asked for further clarification.
>
> Here's the slightly more detailed description of the situation:
>
> 4 groups of hosts on the subnet;
> groupA, groupB, groupC, groupD;
> four different policies on the DHCP server.
> subnet has 4 different upstream routers.
> groupA is handed IP address on routerA as default gateway
> groupB is handed IP address on routerB as default gateway
> groupC is handed IP address on routerC as default gateway
> groupD is handed IP address on routerD as default gateway
>
> all four groups are within the same L2 broadcast domain,
> and have applications that make use of that same-subnet
> relationship.
>
> In looking at DHCPv6 vs RAs, I don't see how to give the
> different groups of hosts the appropriate default router IP
> unless the default router is provided by the DHCP server.
> The routers don't have a way to target their respective
> RAs to just members of the appropriate group of hosts,
> and there doesn't seem to be an option to tell the hosts
> in groupA to only listen to RAs from routerA.
>
>
>
> > 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.
> >
> >
> So, I apologize for the confusion.  I didn't mean that RAs need
> to go away; I simply meant we need a way for the hosts to
> ignore the default router information from the RA, and instead
> to obtain that from DHCPv6.  Essentially, having the RA only
> pass the "go ask DHCPv6" option bits to the hosts, and
> everything else gets superseded by what the DHCPv6
> server sends to the host.

If you want all the nodes to not use the RA to set a default route
then set Router Lifetime to zero.

      Router Lifetime
                     16-bit unsigned integer.  The lifetime associated
                     with the default router in units of seconds.  The
                     field can contain values up to 65535 and receivers
                     should handle any value, while the sending rules in
                     Section 6 limit the lifetime to 9000 seconds.  A
                     Lifetime of 0 indicates that the router is not a
                     default router and SHOULD NOT appear on the default
                     router list.  The Router Lifetime applies only to
                     the router's usefulness as a default router; it
                     does not apply to information contained in other
                     message fields or options.  Options that need time
                     limits for their information include their own
                     lifetime fields.

> > Eliminating RAs from the process would require a major change that would
> > likely pose some level of compatibility problem with existing deployments.
> >
> > Owen
> >
> >
> Sorry; it's not really eliminating the RAs from the process as much
> as saying "ignore what the RA is sending you, other than the
> option bits telling you to go ask the DHCPv6 server for your info,
> and use what the DHCPv6 server gives you, including your
> default route information."
>
> I hope that's a bit clearer; sorry to not have been clearer
> earlier.
>
> Thanks!!
>
> Matt
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org