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

[Owen DeLong <[e-mail]>]

On Jan 8, 2014, at 18:56 , Matthew Petach <[e-mail]> wrote:

> 
> 
> 
> On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong <[e-mail]> 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...

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.

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

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

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