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

[Matthew Petach <[e-mail]>]

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.

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.



> 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