Subject: Re: [dhcwg] Request for opinions regarding the "draft-cha-ipv6-ra-mo".

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Aug 2008 06:34:16 -0700

It's a subtle problem.   I think it will be difficult to get the point  
across, but we can do it.

I promised you some comments on your draft.   As I said in the  
meeting, I had a brainstorm when I read the draft in preparation for  
the meeting, and I'd like to know what you think about this.

I think it helps to enumerate the scenarios.   First, I think there  
are four potential starting states:

1. M bit set, DHCP has not yet acquired an IP address
1a. M bit set, DHCP has not yet acquired an IP address, still have an  
old autoconfigured address
2. M bit set, DHCP has acquired an IP address
2a. M bit set, DHCP has acquired an IP address, still have an old  
autoconfigured address.
3. M bit clear, have stateless IP address
4. No RA received yet, link-local only

If you are in state 1, and you receive an RA with the M bit clear, you  
immediately begin to autoconfigure, and stop trying to do DHCP.    
There is no meaningful distinction between this state and state 4.

If you are in state 2, and you receive an RA with the M bit clear, you  
continue using your IP address.   After a certain interval passes, if  
you have not seen an RA with the M bit set, you autoconfigure an  
address.   As time progresses, the valid lifetime on the DHCP-acquired  
address goes to zero.   You do not attempt to extend it.

If you are in state 3, and you receive an RA with the M bit set, you  
continue to use your autoconfigured addresses, and you start the DHCP  
client.   If the DHCP client produces one or more addresses, you begin  
using them, and set the preferred lifetimes on your autoconfigured  
addresses to zero.   To be clear, until DHCP produces an address, you  
keep doing stateless addrconf.

If you are in state 4, then when you receive your first RA, you do  
stateless addrconf if M==0, and you start DHCP if M==1.

I added 1a and 2a because if you have dueling RAs, you may want to  
keep your stateless IP address.   I think in case 1a, if you receive  
an RA with M==0, you extend the preferred and valid lifetimes on the  
autoconfigured address.   In 2a, it's actually fine to let the  
stateless address expire, because you have a valid address from the  
DHCP server.

So I think the hysteresis that your draft provides is a good start,  
but in specific cases we can do better, and we should.

There are scenarios where the client will wind up unable to use the  
network if there are dueling RAs.   For example, if the DHCP server is  
giving out IP addresses that the infrastructure does not support, or  
if stateless addresses are blocked by a firewall.   But I don't think  
we can solve these cases with protocol.   In these cases, user  
intervention is unavoidable.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 2 Aug 2008 11:36:07 -0400

Ted:

I would remove any statement about autoconfiguring addresses.
Autoconfiguring is completely independent of DHCP. If an RA with a
Prefix Information Option with the A bit set is received, the client
autoconfigures. This has NOTHING to do with the state of the M bit (and
whether the client has previously obtained an address for that prefix
using DHCP). Let's not tie DHCP and stateless autoconfiguration together
here - they are completely INDEPENDENT of each other (yes, a particular
link may use one or the other, but it may also use both).

Thus, 1a and 2a are gone. 3 is just "M bit clear" (the fact that there
may or may not be stateless addresses does not matter).

The main problem this draft is trying to solve is providing a way for an
adminstrator to stop clients that are running DHCP (because they
previously received an RA with the M or O flag set). The basic idea is
to have the client stop running DHCP when no RAs are received with the M
flag set.

So, there are two issues:
1. Under what conditions should DHCP be stopped? As there could be
multiple devices sending (conflicting) RAs, when is it proper for the
client to stop DHCP. (So, it isn't as simple as "you receive an RA with
the M bit clear, ... and stop trying to do DHCP.")
2. What does it mean to "stop" DHCP when it has already acquired an
address via DHCP. Does it mean that the client should immediately send a
Release, "stop" at the next renew/rebind, or "stop" when going back to
Solicit "state"? If no address has been obtained via DHCP (in Solicit
"state"), then stopping "immediately" is not an issue.

Note: All of the above is per interface.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Saturday, August 02, 2008 9:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Request for opinions regarding
the"draft-cha-ipv6-ra-mo".

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Aug 2008 12:31:59 -0700

Bernie, the whole point of this discussion is to explore what to do  
when routers are misconfigured, or the managed/unmanaged policy changes.

As for your second set of questions, I think I addressed what I think  
it should mean to "stop DHCP."   If you don't agree that this is the  
way to do it, cool, but this is one way to do it, so it would help to  
have some commentary if you don't agree that this is the right way to  
do it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 2 Aug 2008 15:37:43 -0400

I was just summarizing what the draft was attempting to address. Sorry
if that wasn't clear.

I agree with you that continuing to use the DHCPv6 assigned address
until it expires (no renewals) is the best course of action because it
is the lease disruptive to the client (such as if it had ongoing
communications using that address). I do think it is a SHOULD, not a
MUST as certain environments may want to allow other behaviors.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Aug 2008 14:59:46 -0700

On Aug 2, 2008, at 12:37 PM, Bernie Volz (volz) wrote:
> I do think it is a SHOULD, not a

Good point.