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

Owen DeLong <owen@delong.com> Thu, 09 January 2014 04:02 UTC

Return-Path: <owen@delong.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 E3D6D1AE14A for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 20:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level:
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 WsG80mbTP5cr for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 20:02:33 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 77A521AE123 for <v6ops@ietf.org>; Wed, 8 Jan 2014 20:02:32 -0800 (PST)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s093w74b024900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 19:58:07 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s093w74b024900
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389239887; bh=p5Iwo0Am+UREUMRheNh2WNDogN8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=SAkFn1SMHtppiUuBLJskrcgQIcmFT9E07kAA0sYoMI4yk+6qFgc76N9D4olL8UB9U rWIX0+xt+ztGWVAWEgZ0fiK3DPq1xk/bFmJfKYmt2BDcF0bXYozTK3dCo057af+WQX XRkqhMJKDlSA/UL5gbcr9hkkYbRdIQDRm9vyys/c=
Content-Type: multipart/alternative; boundary="Apple-Mail=_57D3F96A-7370-44F9-BF65-0A7CD43849D0"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAEmG1=o_9TVBtSqwm3MQVz5_BKTP83Kqc+bbGWYm-9aBDyRvfA@mail.gmail.com>
Date: Wed, 08 Jan 2014 19:58:05 -0800
Message-Id: <1F806192-0F02-4DED-BF27-A9DB753CF621@delong.com>
References: <CAEmG1=rRYwJaZp3qYF47=263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com> <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> <CAEmG1=o_9TVBtSqwm3MQVz5_BKTP83Kqc+bbGWYm-9aBDyRvfA@mail.gmail.com>
To: Matthew Petach <mpetach@netflight.com>
X-Mailer: Apple Mail (2.1827)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 08 Jan 2014 19:58:07 -0800 (PST)
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:02:37 -0000

On Jan 8, 2014, at 19:34 , Matthew Petach <mpetach@netflight.com> wrote:

> 
> 
> 
> On Wed, Jan 8, 2014 at 7:17 PM, Owen DeLong <owen@delong.com> wrote:
> 
> On Jan 8, 2014, at 18:56 , Matthew Petach <mpetach@netflight.com> wrote:
> 
>> 
>> 
>> 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...
> 
> 
> It's actually not that convoluted; it allows you to segment
> your traffic flows across different upstream devices/interfaces
> without having to forklift upgrade your network infrastructure
> completely.  defaultA is actually an HSRP address that is
> master on routerA, backup on routerB; defaultB is master
> on routerB, backup on routerC; defaultC is master on
> routerC, backup on routerD; and defaultD is master
> on routerD, backup on routerA.  Each router takes
> care of 25% of the host load for the network that way.
>  

Meh... There are better ways to achieve that, and, in that case, you don't care so much that group A goes to router A, you care that the traffic is semi-evenly divided between the routers. Having multiple RAs with equal preference will come reasonably close to that automatically.


> In IPv4, that makes sense. In IPv6, it does not.
> 
> 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.
> 
> But it requires your router be configured to route
> multicast traffic between subnets in order for that
> to work, when in the v4 space, the traffic between
> hosts doesn't require participation from the router
> for host-to-host communication to function.

So?

>> 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.
> 
> It's somewhat awkward telling a group of users
> "so, in v4, you're on the same subnet and can
> communicate directly; but in v6, you're on
> different subnets and can't communicate
> directly".  Yes, I suppose we could try to do 
> do non-homologous topologies for v4 and
> v6 for dual-stacked hosts, but troubleshooting
> that kinda scares me a bit.  :(

It's not all that frightening, and, I agree that the cleaner solution is to just deploy RAs and not worry about it.

However, you stated that you specifically wanted group A using router A rather than just dividing up the traffic.

>> 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.
> 
> Would that mean having to go back and break
> up the v4 topology to match what's best for v6,
> or run a different topology for v6 and v4 on the
> same hosts?

I think you'd have to break up the L2 broadcast domain to make it work correctly with RAs, but you might be able to get creative with switch filters on which RAs are allowed to reach which hosts and leave them in a single L2 broadcast domain. In the latter case, you could also use an FF02:: multicast and reach all the hosts without crossing a router. Seems like a huge pain to maintain, however.

> It kinda sounds like the message is "v6 is a 
> different beast, and to use it, you have to
> redo your network, including your v4 topology,
> to best match what v6 wants."

More like "IPv6 is a different beast and if you've done truly strange things to work around deficiencies in IPv4, then the clean solutions available in IPv6 may be incompatible."

Seems to me that for the purpose you have described, advertising RAs from all 4 routers and letting the hosts each pick one would do the trick in IPv6 without modifying your IPv4 topology. If you have other reasons that you really want group A going out through router A, however, then things get trickier and you've got that pesky "IPv4 hack incompatible with IPv6 solution" problem.

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

Actually, I forgot about router lifetime=0... As Mark suggested, that works now and is a readily available hack if you want to disable learning IPv6 default routes by RA.

> 
> 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.
> 
> Sure, supersede vs ignore is fine; main point being
> the DHCPv6 server knows better what that group of
> hosts should be using than the router does, so the
> host should use what the DHCPv6 server sends it,
> not the RA message from the router.

For some definitions of "knows" and some contexts of "better".

>> 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
> 
> 
> Virtualization is actually increasing the number of deployments
> in that mode, rather than decreasing them.

Seems to me that there are much better ways to do what you describe for virtualization, but that's getting into a bit of a digression from the WG charter. Hopefully the information I have provided above can prove useful in addressing your issues without requiring major protocol surgery.

Owen