Subject: Re: [dhcwg] DAD in DHCPv6.

From: Greg Daley <[email-masked]>
Date: Wed, 05 Oct 2005 16:07:54 +1000

Hi Ted,

Ted Lemon wrote:
> On Sep 28, 2005, at 9:32 AM, Andrea G Forte wrote:
> 
>> I have to say though that this is rather confusing as [17] is  
>> referring to the statless configuration (and this misleaded me in  the 
>> beginning). Furthermore in [17] DAD MUST be performed in either  
>> stateful, stateless or manual, while in RFC 3315 DAD SHOULD be  
>> performed. Which one of the two is it?
> 
> 
> I guess the presumption is that in stateless, the chances of an  address 
> conflict are significantly higher than in stateful, thus a  MUST for 
> stateless, and a SHOULD for stateful.   In general we try to  avoid 
> saying MUST if it's not necessary; for example, in a mobile  phone 
> environment, where battery life is affected by how many packets  the 
> phone transmits, you really want to be able to avoid sending  extra 
> packets.   In this environment, the operator has much more  control over 
> what happens on the link, so there's no real need for  DAD, and in that 
> case we'd expect the cell phone DHCPv6  implementation to violate the 
> SHOULD.
> 
> It's probably the case that in the next rev of these RFCs, there  should 
> be some harmonization work done - it's really very early days  for the 
> DHCPv6 protocol, as you've no doubt noticed, and there are a  few rough 
> edges left to sand down.   :'}

I guess in this case, RFC3315 is not correct with the intention of 2462,
was expressed in IPv6 WG recently (for example with Optimistic DAD).
 From what I recall, even with low probabilities of collision available,
most people wanted to maintain mandatory DAD for stateless devices
(Please refer yourselves though, as my memory is proverbially bad).

There's no qualification on which addresses or networks the DAD
MAY NOT be undertaken on (taking this as the rough inverse of SHOULD)
in section 18.1.8.

Depending on the configuration flags of routers on the network, a host
may be able to autoconfigure addresses which conflict with the pool
allocated to a DHCPv6 service.   An autoconfigured address may
therefore predate the Reply, and a valid autoconfigured address could
be clobbered by a DHCPv6 host.

So I guess it doesn't make sense to remove the requirement for DAD,
unless (at least) the autoconfiguration flag isn't set in Router
Advertisements.

It's also worth considering that while Mobile IPv6 is concerned with
additional packets, no dilution of the DAD requirements occurred in
RFC3775.  Additionally, a low latency mechanism to perform DAD
is in development, so it may be worth reexamining the premise
underlying the SHOULD.

Perhaps the issue is that 2462 defines both SAA and DAD, so people
associate the issues closely.  I guess I see SAA as being
complementary or even competing with DHCPv6 in some environments,
but DAD as fundamental to both.

Greg

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Oct 2005 23:21:34 -0700

> unless (at least) the autoconfiguration flag isn't set in Router

It would be kind of strange to enable autoconfiguration and DHCPv6 at  
the same time.   Can you think of a scenario where that would make  
sense?

---

From: Greg Daley <[email-masked]>
Date: Thu, 06 Oct 2005 14:25:33 +1000

Hi Ted,

Ted Lemon wrote:
> the same time.   Can you think of a scenario where that would make  sense?
> 

I guess it will be the default where DHCPv6 is configured.

Almost all hosts support SAA, but not every host
supports RFC3315.  I'd guess that where strict control
over addressing isn't required, people will leave the Autoconf
flag set in RA Prefix Information Options.

from draft-ietf-ipv6-2461bis-04.txt section 4.2
(about the Managed Configuration flag):

"...  1-bit "Managed address configuration" flag.  When
       set, it indicates that Dynamic Host Configuration
       Protocol [DHCPv6] is available for address
       configuration in addition to any addresses
       autoconfigured using stateless address
       autoconfiguration. ..."

This is a very minor variation to the same section in RFC2461.

It seems to imply that for a particular router, SAA and DHCPv6
can be configured simultaneously, and it doesn't seem unusual.

This also seems to be supported by the node-requirements draft
section 5.2.1 on DHCPv6, which says non DHCPv6 hosts can ignore
the "M" flag in RAs.

These hosts will only be able to autoconfigure an address using SAA.

Greg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Oct 2005 22:13:20 -0700

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

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.

---

From: Greg Daley <[email-masked]>
Date: Thu, 06 Oct 2005 16:54:00 +1000

Hi Ted,

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

> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Oct 2005 00:36:49 -0700

> DHCPv6 if it's available).

We're not talking about people here, Greg.   We're talking about  
machines.   Machines just do what you tell them to do.   Since we  
haven't specified what machines should do in the scenario we've  
described, we can expect them to do consistently whatever they are  
programmed to do.   And they are programmed to do stateless address  
configuration when it's available.   So we can expect them to do that.

> documents (As I referred before).

Right, that's the problem.   There's no spec that says what to do.

> doesn't turn off the A flag in PIOs...

Yes, that's painfully obvious.   The point I am making here is that M 
+A=undefined.   In general, it seems to produce the same effect as !M 
+A, but there's no spec, so there's no way to really predict what it  
will do.   So any network administrator with any common sense will  
never configure M+A; and network administrators who don't know what  
they are doing will likely experience inexplicable problems because  
they won't know not to configure M+A.  Romantic discussions about who  
will implement what based on what value they perceive are  
interesting, but do not address this issue.

It might be worth writing a draft that just says "M+A is not  
recommended."   It sounds, though, like you don't agree that this  
shouldn't be recommended, which brings us back to the starting point  
of this discussion.

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 Oct 2005 00:14:19 +0700

Date:        Thu, 6 Oct 2005 00:36:49 -0700
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | Yes, that's painfully obvious.   The point I am making here is that M 
  | +A=undefined.

Undefined how?

They're independent, and should remain that way.   Each is defined, nothing
magic is required to operate them in all possible configurations (except having
both M off, and A disabled for every prefix, makes the link something of a
configuration nightmare).

If A is set for a prefix, the host autoconfigures an address on that prefix.
If A is set on 2, 3, or 4 prefixes, the host autoconfigures an address on
each such prefix.

If M is set, the host attempts DHCPv6 - if a DHCP server replies and
supplies an address, the host configures that address.

Neither one of those has any affect on the other.  What's the problem?

As to why anyone would want to do that - well, one reason that I might,
is that I might have a bunch of hosts I'd like to have particular addresses,
and for them to always have those addreses, regardless of what EUI-64's
they may happen to own, and without actually touching the hosts
individually (ie: no manually configuring each host - I want to be able
to update them all quickly if the prefix has to alter).

Those, I set up in the DHCP server (updating its config whenever the
host's identity changes, or it becomes necessary to alter addresses).

Other hosts that just happen to be connected to the link get whatever
address(es) they happen to configure themselves with today - if they
change their NIC cards, they'll get different addresses tomorrow.
No-one really cares (this is probably the majority of the hosts).

The hosts with DHCP addresses also have that form of address, which will
work fine for them to communicate out with, but which are probably not
being advertised in the DNS (only the DHCP assigned addresses are
advertised to the world).

About all that (I think) we're missing for this (and the lack isn't
crucial), is a way for a DHCPv6 server to tell a host (client) "there
is no address from DHCP for you, you can stop trying".

I know DHCPv4 doesn't have anything like that - the theory being that
no DHCP server can say that, as some other server might have an available
address, so we just allow clients to retry N times, and eventually either
give up, or fall back to infrequent attempts.

I think DHCPv6 is the same - and as a default config for servers, that
probably makes sense.   But it would be kind of nice (to the client) to
be able to explicitly tell it to simply use whatever addresses it has been
able to obtain in other ways (which at the very least is an LL address).

kre

---

From: Greg Daley <[email-masked]>
Date: Fri, 07 Oct 2005 14:16:31 +1000

Hi Ted,

Ted Lemon wrote:
> machines. 

:)

I'd guess that some hosts will have configuration flags to turn on
DHCPv6 clients, and these clients to run DHCPv6 when the M flag is
set.

>  Machines just do what you tell them to do.   Since we  

Yes we can.   We can also expect them to do DHCPv6 if the M flag is
set (and they've got DHCPv6 clients)...

> will implement what based on what value they perceive are  interesting, 
> but do not address this issue.

Well, I think that the base specifications are supposed to be
robust (the internet shouldn't end) regardless of how sensible
network administrators are, though.

If it is reasonable to assume that some time in the future
any host which receives M+A could configure a prefix using DHCPv6
(or even now, if the situation is broken and badly defined), then
specifying cautious DAD behaviours are appropriate.

> shouldn't be recommended, which brings us back to the starting point  of 
> this discussion.

I think it would be OK to describe what the gotchas are.
At this stage, I wouldn't prohibit M+A, but would point out what
the potential problems (address collision, lack of management of
particular address resources) and required operations are:

- A host MUST do DAD if assigned an address from an autoconfiguring
   prefix.

- If the host doesn't know if the prefix is autoconfiguring, it
   SHOULD do DAD.  (I'd personally prefer MUST do OptiDAD??)

etc.

It would be OK to then (either separately or in the same document)
provide router side configuration advice which describes how to
avoid the bother (M+!A).

I'm not disagreeing that some specification is required.

It seems that one of us seeks to describe a reasonable deployer
behaviour, and another seeks to support reasonable host behaviour.

Even if the deployer behaviour is completely effective when deployed
though, it's worth considering if the potential for non-deployment
warrants attention on the host.

Greg