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

Mark Andrews <marka@isc.org> Thu, 09 January 2014 04:06 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 AA6B81AE027 for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 20:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.773
X-Spam-Level:
X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_SOFTFAIL=0.665] 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 ZMutHKLq4TMM for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 20:06:46 -0800 (PST)
Received: from mx.ams1.isc.org (amstel.isc.org [IPv6:2001:500:60:d::56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5591AE15D for <v6ops@ietf.org>; Wed, 8 Jan 2014 20:06:46 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id F16142383C8; Thu, 9 Jan 2014 04:06:24 +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 49964160446; Thu, 9 Jan 2014 04:16:50 +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 E3DE8160389; Thu, 9 Jan 2014 04:16:49 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E8188C981CE; Thu, 9 Jan 2014 15:07:38 +1100 (EST)
To: Owen DeLong <owen@delong.com>
From: Mark Andrews <marka@isc.org>
References: <CAEmG1=rRYwJaZp3qYF47=263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com> <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com>
In-reply-to: Your message of "Wed, 08 Jan 2014 19:17:08 -0800." <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com>
Date: Thu, 09 Jan 2014 15:07:38 +1100
Message-Id: <20140109040738.E8188C981CE@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 04:06:49 -0000

In message <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com>, Owen DeLong write
s:
> On Jan 8, 2014, at 18:56 , Matthew Petach <mpetach@netflight.com> wrote:
>
> >
> >
> >
> > 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.
>
> Ignoring for the moment that this is an incredibly convoluted corner case
> which is likely fragile, at best, in IPv4...

So what?

> In IPv4, that makes sense. In IPv6, it does not.

In your opinion.

> In IPv6, you don't have broadcasts, it's all multicast. You can define a
> multicast scope (ff04 perhaps?) that incorporates those 4 distinct IPv6
> subnets.

And how do the nodes know to listen to that address?

Just turn off default router assignment at the RA level and do it
via DHCPv6 for per host route assignment.

> > 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.
>
> That's because you haven't looked at the fact that in IPv6, these don't
> need a shared broadcast domain to continue working the way you describe.
>
> > 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.
>
> You could, but it would involve elaborate configuration on the routers.
> It makes more sense to divide these groups of hosts into separate IPv6
> networks.

Yes, but that makes lots of other assumptions of capabilities of the
existing components of the network at both layer 1 and layer 2.

One should be able to upgrade just that nodes and the routers without
touching cabling, switches and hubs and get similar functionality
in both IPv4 and IPv6.  RA's as the only source of default routes
are not able to meet this requirement.

> > 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.
>
> I don't see a mechanism for not treating a router announcing RAs as a
> candidate default route is likely to succeed. I think it would require
> modifications to host stacks that could not be backward compatible with
> existing implementations.

The existing host stacks should already be capable of using router
lifetime for this.

> I'm all for adding RIO equivalence in DHCPv6, though I think it is
> significantly less useful than advocated.
>
> > 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 can certainly see ways to suggest that DHCPv6 route information, if
> presented, should supersede any route information learned via RA. I don't
> see ignoring the RA information completely.
>
> > I hope that's a bit clearer; sorry to not have been clearer
> > earlier.
>
> Much clearer. I have to ask... Do you have a running network where this
> actually is still in use? I've seen a few environments like this, but
> most of them were deprecated years ago due to various problems that they
> create in IPv4.
>
> Owen
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org