Subject: Re: DHCPNAK for DHCPv6?

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jul 2001 14:15:02 -0700

> We need to be careful about what "give up its existing IAs" means.
> 
> Consider a mobile node ... perhaps this signals to it that it must
> contact is Home Agent? In which case, it would want to keep the
> (IA) addresses but get new addresses for the local network such that
> it could (hopefully) contact the Home Agent.
> 
> Also, consider your laptop. You plug it in at the office and get some
> addresses. You later take it home. You do this 5 days a week. No reason
> your laptop could not hold onto the "old" IAs and try one set first and
> if that isn't accepted, try another. I'm not proposing that it do this
> (likely cheaper to drop old and get new ones), just that it could. A
> smarter implementation could even look at what the Router Advertisement
> contains and match up IAs that it thinks are valid based on the prefixes.
> 
> Obviously, the IA isn't valid on that link and thus MUST NOT be used on
> that link. If the client needs addresses, it should go to the Solicit
> phase.

This is precisely what I was trying to get across, but I phrased it
poorly.   Can you turn this into language that could go into the
draft?

Would the authors accept such language if it were provided?

			       _MelloN_

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 17 Jul 2001 15:54:55 -0500

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 4:18 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6? 

> I agree that the prefix handling should avoid the need for the
> NACK. There is still an issue of non-address configurations and
> perhaps a general "DHCP Error" option (in a Reply) that can be used
> to communicate problems might be useful. But, it is also something
> that perhaps can be added later (though existing clients would of
> course ignore that option).

I think this is fine (don't see the new for a new option, unless it's
a text error message), but I think it would be good to have some
verbiage that just says "if the client gets a Wrong Prefix message, it
SHOULD by default give up its existing IAs and go back to the DHCP
Solicit phase, but SHOULD be configurable not to, or something like
that."  I am not sure how this situation could come about, as long as
the client is listening to router advertisements, but it worries me,
and I'd like to see it covered.   I guess this is something that could
wait for some implementation experience after last call, though.

			       _MelloN_