Subject: RE: [dhcwg] DAD in DHCPv6.

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 6 Oct 2005 07:48:29 -0400

Please also remember that IPv6 hosts aren't like IPv4 hosts where one
address is generally all that is used per interface. There's nothing
prohibiting M + A. You can easily have two or more prefixes on a link
and some may be A and others !A.  In this environment, *BOTH* stateless
and stateful are in use, but on ***DIFFERENT*** prefixes. This is
perfectly acceptable.

There is always room for misconfiguration. For example, suppose you have
two prefixes and the RA tells the host M and each of the two prefixes
has A enabled. So, the host auto-configures addresses on both prefixes
and runs DHCPv6. The DHCPv6 server is configured to do stateful on
Prefix A and sends the host an address on that prefix (this assumes that
the host sends an IA_* option). This would not be good but is not much
different than other misconfigurations that can happen.

But, there's also the possibility that the DHCPv6 server provides the
client with an address on Prefix C!! And, perhaps a future RA will
advertise that (as !A).

The much more interesting case Greg is what happens if you want to
*SWITCH* between stateless and stateful for a prefix? This is a much
better argument for requiring DAD (though DAD itself is no guarantee of
problems as it has limitations).

When we revise the DHCPv6 RFC to advance it along the standards track,
this should be discussed at that time and I believe bringing this in
line with the other RFCs (which I believe are using MUST) is warranted.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Greg Daley
> Sent: Thursday, October 06, 2005 2:54 AM
> To: Ted Lemon
> Cc: [email-masked]; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] DAD in DHCPv6.
> 
> Hi Ted,
> 
> Ted Lemon wrote:
> > On Oct 5, 2005, at 9:25 PM, Greg Daley wrote:
> > 
> >> It seems to imply that for a particular router, SAA and DHCPv6
> >> can be configured simultaneously, and it doesn't seem unusual.
> > 
> > 
> > In your proposed scenario, where the managed bit is set but 
> stateless  
> > address configuration is enabled, what will happen is that 
> all of the  
> > IPv6 addresses on the network will be allocated 
> statelessly, because  
> > this is what current IP stacks do, and there is no RFC that 
> says they  
> > should do otherwise.   So if you want a network with 
> stateful address  
> > configuration, in practice you *must* disable stateless.
> 
> That's not necessarily a reasonable assumption (people won't use
> DHCPv6 if it's available).
> 
> People implement new features because they think they will get a
> benefit out of a technology.  If DHCPv6 provides a benefit, people
> will use it.   This is the way with TCP enhancements too (people
> implement them because they're beneficial).
> 
> The question is: Does DHCPv6 address allocation buy the host anything?
> If the answer is yes (for example dynamic DNS updates...) people will
> use it.
> 
> They're not bound to use it though if autoconf is on...
> 
> So mixed environments are possible, and not necessarily a description
> of broken configuration.
> 
> 
> > I think a more likely scenario is one where we enable stateless  
> > addrconf, but indicate that devices can configure network 
> parameters  
> > using stateless DHCPv6.   In this scenario I think you get the  
> > functionality that you're proposing for the 
> stateless+stateful  scenario 
> > you describe - devices that don't grok DHCPv6 can still use  the 
> > network, but devices that grok DHCPv6 get additional  
> functionality.   I 
> > believe that as time goes on it will become  commonly 
> accepted that the 
> > M bit and stateless address configuration  are mutually exclusive.
> 
> I agree that the scenario you describe with stateless DHCPv6
> is likely.
> 
> They're explicitly not mutually exclusive though, with today's
> documents (As I referred before).
> 
> Autoconf=0 is mutually exclusive with configuration of global
> addresses using SAA.  If it makes sense to specify special
> behaviour for DAD, then it should be based on the documented
> assumptions about which address configuration strategies are in use.
> 
> I think it's fine to make a document describing exclusively
> managed addressing, but today, switching on the M flag
> doesn't turn off the A flag in PIOs...
> 
> Greg
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg