Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 7 Sep 2012 15:09:10 +0000

Chairs:

Where does this Last Call stand? August 24th has passed ...

I do know Ted wants to see an I-D regarding the multiple provisioning domains but I am not sure whether that would block draft-ietf-dhc-dhcpv6-stateful-issues-00 until available. I just haven't had much time to work on that ID -- the concept is fairly simple in that servers would have to include the provisioning domain identifier in their responses and clients would have to make decisions based on the provisioning identifier - Advertisements that have the same provisioning identifier are selected from pretty much as clients do today without this support and if multiple provisioning identifiers are present, a client can select one Advertisement from each set and fork separate transactions (when and why a client may want to do this need to be worked out - such as is it only done if one domain provides addresses and another prefixes, or should the client do it always). It likely is also appropriate to allow a user to control which provisioning domains are to be used (much like Wifi network selections). There may also be some authentication information that could be used (much like the Wifi shared secret).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, August 09, 2012 11:15 PM
To: dhc WG
Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

The authors have requested a working group last call.   The document describes some problems that exist in the way DHCP clients handle multiple stateful options, and proposes a solution that unifies the client state machine to accommodate these issues.

This document could use additional review, so please take the time to read it over and comment on it if you have any comments.   If you are in favor of advancing the document, please say so.   If you oppose advancing it, please say so, and say why.   We will evaluate the consensus based on these responses on August 24.

Thanks!

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Sep 2012 15:38:13 +0000

> Where does this Last Call stand? August 24th has passed ...

There were a lot of comments in the WGLC, and lot of support for what is to be accomplished here, but several people raised concerns as well.   There were a few responses in favor of advancing the current document; Hemant Singh had some suggestions, to which Ole responded.   I do not know if the responses satisfied Hemant's concerns.   I raised some concerns which were not really addressed.   Wes Beebe raised a concern which Ole responded to, but again I don't know if Wes was satisfied with Ole's response.

So I think this is borderline.   There's clearly widespread support for what this draft is trying to do; I would like to hear from Hemant and Wes as to whether they are satisfied with Ole's responses.   I tend to agree with Wes' sentiment that we need to think this through very carefully; I would like to see a new draft that addresses Hemant's and Wes' concerns, if possible, and then do a second last call to get more review.   Does that work for the authors?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 7 Sep 2012 16:18:27 +0000

I believe Wes' and Hemant's issues were:

Wes (message on Thu 8/16/2012):

   Why MUST the client ignore an Advertise message with no bindings?
   What if stateful and stateless options are carried in the same message?
   Does this mean the stateless options will be ignored just because the stateful Options failed?

---

Ole's answer was that basically this is how RFC 3315 operates today and we didn't want to change this (we are fixing what happens if IA_NA and IA_PD are requested in a Solicit and only one of these is available) -- which is different than the no bindings at all case. RFC 3315 basically expects clients to use Information-Request in this case.

A while back, Ralph and I considered that this might be a good change - especially given the case when M says to use stateful but the server is not configured to give (the requesting client) any stateful bindings. Server could effectively respond with the other configuration options. But an Advertise is not the same as a Reply, so if the client was going to do a Request/Reply, we'd have to change that processing to and so why doesn't the client just do an Information-Request? (Sure, if Rapid Commit is requested, server would just Reply and client would be done.)

If the WG feels that would be a useful change, we can certainly do this change. But for this particular work, we didn't feel that change was warranted. And, it might be best to do under a separate document? Or something for a 3315bis?

Hemant (message on 8/17/2012) and Ole's response (using Ole's email on 8/20/2012):

> +1 to Wes' comment that this document is addressing a very important problem space and the solutions are needed urgently.  However, more thought is required for the solutions.
> 
> In regards to section 4.4, if the server only checks the network configuration to reply to a Confirm message, how is it possible for most network configurations that the server determines an IA_PD is on-link?   I suspect that is why RFC 3633 prohibited use of the Confirm for the IA_PD.  In any case this document should explain why did RFC 3633 have a restriction on using the Confirm for the IA_PD.  Or does network configuration include looking up the prefix pool configured on the server for allocation?  In contrast, to make an on-link determination for an IA_NA IA_Address, all the server has to do is match (longest-prefix match) all IPv6 addresses configured on the machine that the server is running on.  These addresses are clearly network configuration.  

right, either the server has the binding, or the server has configuration that it can look up in, to verify if the client has moved or not. if it has no information it MUST not reply.

> Section 4.1:  
> 
> # In relation to the first paragraph the document is addressing the fact that one server replies with, say, an IA_NA, while another server replies back with only the IA_PD.   Then why in section 4.7 the case of section 4.1 is deemed out of scope?   I also do not understand what does "equal" in section 4.7 mean.  Does it mean each server replies with all IAs that the deployment needs?

the assumption in 3315/3633 is that a client is connected to a single administrative dhc domain on an interface.
scenarios where a client finds two DHCP servers, that are administered by two different entities, are outside of the scope of 3315/3633 and therefore also outside the scope of this update. there is as far as I know separate work in progress on this.

> # In relation to the text in the last paragraph of section 4.1, if the client does not restart the Solicit retransmissions timers, what does the client do?

continues with the timers it has.
otherwise as the text says, a received advertise with a consequent restart of solicit timers would result in a solicit storm.

> 
> # Other comment:  Shouldn't the header of the document have an Updates tag to signify this document updates RFC 3315?

good point. both 3315 and 3633.

---

I guess the one change that I see is to assure we update the document header. We can respin the document for this change.

Section 4.4 is just extending the Confirm to include prefixes - this issue is already covered in RFC 3315 for Confirm processing:

                                                               If the server is unable to perform
   this test (for example, the server does not have information about
   prefixes on the link to which the client is connected), or there were
   no addresses in any of the IAs sent by the client, the server MUST
   NOT send a reply to the client.

The section 4.1 / 4.7 issue is the single vs multiple provisioning domains - we assume a single in this document.

If Wes or Hemant would like other changes to clarify any of their concerns, we would appreciate text to be added/modified.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Sep 2012 16:22:22 +0000

Was that a yes or a no?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 7 Sep 2012 16:41:13 +0000

Ted:

Speaking for myself, I believe the answer is yes ... once I know what the scope of changes are (other than indicating that the document updates 3315/3633), I am happy to update and respin the document and do a second WG last call if the changes warrant or if the chairs or WG feels it is needed.

I too would like to have seen and see more people comment on this because there are some fairly significant changes. It also surprises me that few of the people that pushed for these changes have commented.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, September 07, 2012 12:22 PM
To: Bernie Volz (volz)
Cc: dhc WG; Wes Beebee (wbeebee); Hemant Singh (shemant); Ole Troan (otroan)
Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Was that a yes or a no?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Sep 2012 16:43:41 +0000

> I too would like to have seen and see more people comment on this because there are some fairly significant changes. It also surprises me that few of the people that pushed for these changes have c…

Yes, I think that's what Wes was getting at as well.   I will give the document a thorough read during the new WGLC.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 13 Sep 2012 13:34:37 +0000

My comments fall under the category of "optimization".

Certainly the client can drop the original transaction and issue another
Information-Request set of messages for the rest of the information
already contained in the original transaction.  Just out of curiosity, why
is this behavior mandated?

While I think this work is very important, I would like to see more
comments from others on the significant changes to the protocol that are
contained in the document.

- Wes

On 9/7/12 12:18 PM, "Bernie Volz (volz)" <[email-masked]> wrote:

>Ole's answer was that basically this is how RFC 3315 operates today and
>we didn't want to change this (we are fixing what happens if IA_NA and
>IA_PD are requested in a Solicit and only one of these is available) --
>which is different than the no bindings at all case. RFC 3315 basically
>expects clients to use Information-Request in this case.
>
>A while back, Ralph and I considered that this might be a good change -
>especially given the case when M says to use stateful but the server is
>not configured to give (the requesting client) any stateful bindings.
>Server could effectively respond with the other configuration options.
>But an Advertise is not the same as a Reply, so if the client was going
>to do a Request/Reply, we'd have to change that processing to and so why
>doesn¹t the client just do an Information-Request? (Sure, if Rapid Commit
>is requested, server would just Reply and client would be done.)
>
>If the WG feels that would be a useful change, we can certainly do this
>change. But for this particular work, we didn't feel that change was
>warranted. And, it might be best to do under a separate document? Or
>something for a 3315bis?
>
>
>> +1 to Wes' comment that this document is addressing a very important
>>problem space and the solutions are needed urgently.  However, more
>>thought is required for the solutions.
>> 
>> In regards to section 4.4, if the server only checks the network
>>configuration to reply to a Confirm message, how is it possible for most
>>network configurations that the server determines an IA_PD is on-link?
>>I suspect that is why RFC 3633 prohibited use of the Confirm for the
>>IA_PD.  In any case this document should explain why did RFC 3633 have a
>>restriction on using the Confirm for the IA_PD.  Or does network
>>configuration include looking up the prefix pool configured on the
>>server for allocation?  In contrast, to make an on-link determination
>>for an IA_NA IA_Address, all the server has to do is match
>>(longest-prefix match) all IPv6 addresses configured on the machine that
>>the server is running on.  These addresses are clearly network
>>configuration.  
>
>right, either the server has the binding, or the server has configuration
>that it can look up in, to verify if the client has moved or not. if it
>has no information it MUST not reply.
>
>> Section 4.1:  
>> 
>> # In relation to the first paragraph the document is addressing the
>>fact that one server replies with, say, an IA_NA, while another server
>>replies back with only the IA_PD.   Then why in section 4.7 the case of
>>section 4.1 is deemed out of scope?   I also do not understand what does
>>"equal" in section 4.7 mean.  Does it mean each server replies with all
>>IAs that the deployment needs?
>
>the assumption in 3315/3633 is that a client is connected to a single
>administrative dhc domain on an interface.
>scenarios where a client finds two DHCP servers, that are administered by
>two different entities, are outside of the scope of 3315/3633 and
>therefore also outside the scope of this update. there is as far as I
>know separate work in progress on this.
>
>> # In relation to the text in the last paragraph of section 4.1, if the
>>client does not restart the Solicit retransmissions timers, what does
>>the client do?
>
>otherwise as the text says, a received advertise with a consequent
>restart of solicit timers would result in a solicit storm.
>
>> 
>> # Other comment:  Shouldn't the header of the document have an Updates
>>tag to signify this document updates RFC 3315?
>
>I guess the one change that I see is to assure we update the document
>header. We can respin the document for this change.
>
>Section 4.4 is just extending the Confirm to include prefixes - this
>issue is already covered in RFC 3315 for Confirm processing:
>
>                                                               If the
>The section 4.1 / 4.7 issue is the single vs multiple provisioning
>domains - we assume a single in this document.
>
>
>If Wes or Hemant would like other changes to clarify any of their
>concerns, we would appreciate text to be added/modified.
>
>- Bernie
>
>There were a lot of comments in the WGLC, and lot of support for what is
>to be accomplished here, but several people raised concerns as well.
>There were a few responses in favor of advancing the current document;
>Hemant Singh had some suggestions, to which Ole responded.   I do not
>know if the responses satisfied Hemant's concerns.   I raised some
>concerns which were not really addressed.   Wes Beebe raised a concern
>which Ole responded to, but again I don't know if Wes was satisfied with
>Ole's response.
>
>
>So I think this is borderline.   There's clearly widespread support for
>what this draft is trying to do; I would like to hear from Hemant and Wes
>as to whether they are satisfied with Ole's responses.   I tend to agree
>with Wes' sentiment that we need to think this through very carefully; I
>would like to see a new draft that addresses Hemant's and Wes' concerns,
>if possible, and then do a second last call to get more review.   Does
>that work for the authors?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 14 Sep 2012 13:53:56 +0000

Again, one reason is that Advertise response to a Solicit is not necessarily the "final" information the client is allowed to use - Reply is used to communicate that (after Request or Information-Request). And the Request, Renew, Rebind are all about communicating bindings - for example if Solicit/Advertise is same as Information-Request/Reply, if client wants to refresh options, does it use Renew/Reply or Information-Request/Reply.

With the proposed changes we are actually a bit closer to supporting this because if the client wants addresses or bindings but only got other config options earlier, it would perhaps be acceptable to let it Request or Renew or Rebind with the bindings to attempt to get those bindings. But we did not take this step as it would require a few more tweaks. (Rebind may be the best choice here as that allows other servers to respond.) But this needs to be more carefully thought through and I am not sure it is worth it to do this. And in any case, perhaps done as a separate work.

---

Agreed that more review / comments especially from client implementers as to whether the changes proposed in the draft are appropriate. As the CableLabs (DOCSIS) community were pushing for this, we really need more of them to respond. If they don't, perhaps it means there is no issue and this work isn't needed as current client implementations have already figured out how to deal with the situation in an acceptable mannor.

- Bernie

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 15 Sep 2012 01:09:19 +0000

Ted/Bernie/Ole,

Humble apologies I was buried with other priorities and did not check my DHC WG email folder in a while. I actually replied to the xlat document in v6ops during my 10 days of PTO up till the Labor Day.  Bernie kindly reminded me this week of this document.  Most of my comments have been addressed.  Some pending are included below.

Why was the CONFIRM message deliberately specified by RFC 3633 as not supported for the IA_PD?  

It would be good to reply to this question.  Otherwise the IESG is likely to ask the same question and the answer to such a question may uncover issues for us.  

For one, it is easy for a server to respond to a CONFIRM to an IA_MA by just matching the IPv6 address configured on the machine the server is running on.  I am always reminded by some authors of RFC 3315 that the server distinctly does not consult its client bindings to respond to a CONFIRM for an IA_NA.  The server just relies on the machine IPv6 configuration to compute a status of on-link or not-on-link.  Thus why it is not a sea-change to support the CONFIRM for the IA_PD option and we may need to step gingerly?  If the server has to respond to a CONFIRM for an IA_PD, the server now consults with its bindings (I think Bernie alluded to in his reply to this thread) which the server did not do before for the IA_NA.  Searching thru bindings has delay implications and additional server computations.  Or as I had already said in my earlier reply that the server checks what prefixes are configured on the server to determine on-link status.  However checking prefixes for IA_PD at a server has to exclude prefixes that are used for allocation of IA_NA.  So now the server maintains two types of prefixes.  

Thus I will try and propose some text over the weekend that IA_PD support in CONFIRM can't suffice with network configuration.  Some other data in the server needs checking and we should try and be little specific about the data.  Just saying something like "the sever checks network configuration" doesn't cut it for the IA_PD.  

Let me see what I can do over this weekend and propose some text as to how the server checks for on-link or not for the IA_PD to respond to a CONFIRM.  I will also catch up with other emails on this document and reply, if necessary.

Regards,

Hemant

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, September 07, 2012 12:22 PM
To: Bernie Volz (volz)
Cc: dhc WG; Wes Beebee (wbeebee); Hemant Singh (shemant); Ole Troan (otroan)
Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Was that a yes or a no?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 15 Sep 2012 16:36:26 +0000

Bernie,

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Friday, September 07, 2012 12:18 PM
To: Ted Lemon
Cc: dhc WG; Wes Beebee (wbeebee); Hemant Singh (shemant); Ole Troan (otroan)
Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

>Ole's answer was that basically this is how RFC 3315 operates today and we didn't want to change this (we are fixing what happens if IA_NA and IA_PD are >requested in a Solicit and only one of these is available) -- which is different than the no bindings at all case. RFC 3315 basically expects clients to >use Information-Request in this case.

I agree with use of the Information-Request message rather than changing the behavior for Request/Reply processing.  Now, when the Information-Request message is sent to the server, don't we expect an Information-Request storm at the server akin to a Solicit storm because INF_MAX_RT is 120 secs?  If yes,   the SOL_MAX_RT is also 120 secs which is getting changed in Ralph's SOL_MAX_RT draft.  So shouldn't Ralph's document now also address the INF_MAX_RT if the document does not already do so?

Thanks,

Hemant

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 16 Sep 2012 00:16:36 +0000

I have included Ralph. Not sure exactly which situation will cause an Information-Request storm (just other-config)? I generally would expect a server, if it exists, to respond to Information-Request even if it returns "no" config info.

But yes should be discussed with respect to Ralphs's draft.

- Bernie

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 16 Sep 2012 16:17:25 +0000

Bernie,

Here is what I prefer for text for section 4.4 of the document.  All other text in the current section 4.4 is redundant with RFC 3315.

   The Confirm message, as described in [RFC3315], is specific to
   address assignment.  Note a server processing a Confirm message
   that includes only IA_NAs does not have to look up any client
   bindings. This document extends the Confirm to include other 
   IA option types.  It is desirable other IA option 
   types do not enforce the server to look up any client bindings 
   to respond to a Confirm.  Another IA option type is the IA_PD. 
   The server uses configured prefixes to determine if a prefix in 
   the IA_PD option is on-link to respond to a Confirm.

Another issue I'd like to bring up for the Confirm section of this document.  I realize the document only supports the case of one server replying to both the IA_NA and the IA_PD.  However, after a client has completed DHCPv6 for both the IA_NA and the IA_PD, some configuration on the server changes.  Later the client issues a Confirm and the server configuration change causes one IA type to fail the on-link check.  If the Status code option in the Reply is global, the Reply has a failed on-link code and the client moves to Solicit processing and the Solicits may continue indefinitely.  I recommend using the Status code option per IA option type.  Then for an IA option type not on-link status, the client can now use Information-request rather than moving to a Solicit transaction.  Thus more text changes to RFC 3315 are required.
 
Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, September 14, 2012 9:09 PM
To: Ted Lemon; Bernie Volz (volz)
Cc: dhc WG; Ole Troan (otroan)
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Ted/Bernie/Ole,

For one, it is easy for a server to respond to a CONFIRM to an IA_MA by just matching the IPv6 address configured on the machine the server is running on.  I am always reminded by some authors of RFC 3315 that the server distinctly does not consult its client bindings to respond to a CONFIRM for an IA_NA.  The server just relies on the machine IPv6 configuration to compute a status of on-link or not-on-link.  Thus why it is not a sea-change to support the CONFIRM for the IA_PD option and we may need to step gingerly?  If the server has to respond to a CONFIRM for an IA_PD, the server now consults with its bindings (I think Bernie alluded to in his reply to this thread) which the server did not do before for the IA_NA.  Searching thru bindings has delay implications and additional server computations.  Or as I had already said in my earlier reply that the server checks what prefixes are configured on the server to determine on-link status.  However checking prefixes for IA_PD 
 at a server has to exclude prefixes that are used for allocation of IA_NA.  So now the server maintains two types of prefixes.  

Regards,

Hemant

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 17 Sep 2012 00:26:36 +0000

The server I work on does not look up bindings for Confirming IAPREFIX (the server has allowed Confirm on prefixes since day one) so this text is false and is not required. The server does the same processing it does for addresses. It looks up the link and prefix configuration and if the delegated prefix sent by the client (or address sent by the client) is contained by a configured prefix the client is told success. If it can't tell (this is mostly the case for addresses that are link-local but also in cases where the clients "location" can not be determined from one of the addresses or prefixes provided by the client) it doesn't respond. Otherwise the client is told not-on-link.

Confirm never says a particular address or prefix is leased to the client. It just says whether the client has clearly moved or not (no response means the server can't determine).

So, I do not agree with this text change at all.

Regarding the second issue ... If the configuration has changed to remove prefix delegation or addresses, but not the other, and the Confirm returns Not-On-Link, client would move back to Solicit but why would Solicits continue forever? Are you thinking a client would implement some, but not all changes? I would think that is wrong - this is a package of changes the client and server need to implement. So, the other changes would prevent the continous Solicits? We have no good way to return separate status codes for prefix vs address and I don't see this as needed per what I just wrote?

Note that likely the client will get back the same address or prefix when it Solicits, just won't get the other that is no longer configured.

Perhaps Ole has a different view or there is something I am missing here?

- Bernie

---

From: Ole Trøan <[email-masked]>
Date: Mon, 17 Sep 2012 10:02:45 +0200

Bernie,

> Perhaps Ole has a different view or there is something I am missing here?

I have the same view as well.

(the reason we did what we did in 3633 with regards to Confirm, was because of the text around "Onlink". in hindsight we've realised that having different behaviour per IA was a bad idea, and Bernie came up with a simple fix for how to use Confirm for IA_PD also.)

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Sep 2012 15:26:38 +0000

Hemant:

Where do you stand on this? Is the Confirm still an issue for you? Is there something to add to the draft to help clarify things?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Monday, September 17, 2012 4:03 AM
To: Bernie Volz (volz)
Cc: dhc WG; Ted Lemon
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Bernie,

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 22 Sep 2012 12:48:19 +0000

Bernie & Ole,

Sorry for the delay.  Please see in line below.  Also, let's talk sometime next week at work and we can resolve the issues offline and then let the mailer know.

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Sunday, September 16, 2012 8:27 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; dhc WG; Ole Troan (otroan)
Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

>The server I work on does not look up bindings for Confirming IAPREFIX (the server has allowed Confirm on prefixes since day one) so this text is false >and is not required. 

That's one server.  We could use text that has generic requirements for all servers.  I wrote a bunch of text including text that says client bindings should not be looked up.  I also said most of the text in the Confirm section of your document is redundant with RFC 3315.  Thus it makes sense to retain most of the text I proposed.  I think the text you say is false is this.

"The server uses configured prefixes to determine if a prefix in the IA_PD option is on-link to respond to a Confirm."

>The server does the same processing it does for addresses. It looks up the link and prefix configuration and if the delegated prefix sent by the client >(or address sent by the client) is contained by a configured prefix the client is told success. If it can't tell (this is mostly the case for addresses >that are link-local but also in cases where the clients "location" can not be determined from one of the addresses or prefixes provided by the client) it >doesn't respond. Otherwise the client is told not-on-link.

Hmm, does DHCPv6 assign a link-local address to a client that a client will issue a Confirm for a link-local address?  I am also replying to Ole in this email.  Ole said 

"(the reason we did what we did in 3633 with regards to Confirm, was because of the text around "Onlink"." 

It makes sense that OnLink is defined in some document.  Both RFC 3315 and RFC 4861 have identical definition for "link".  This definition says nodes on the link can communicate below the IP layer.  So how is a globally routable IPv6 address in an IA_NA or a prefix in the IA_PD determined to be OnLink when both entities communicate at the IP layer?  I know you have given details on how does your server determines OnLink.  But those are details and internal constructs of one server.  We need an example for how do all servers determine what is OnLink for the IA_PD prefix.
  
>Confirm never says a particular address or prefix is leased to the client. It just says whether the client has clearly moved or not (no response means >the server can't determine). 
>

Looking up a link matching a prefix configuration does not work for all cases.  The client moves and another link on the server can serve the same prefix.  So now the server has to look up a collection of prefixes.  How are prefixes collected?  Based on what metric? 

>Regarding the second issue ... If the configuration has changed to remove prefix delegation or addresses, but not the other, and the Confirm returns Not->On-Link, client would move back to Solicit but why would Solicits continue forever? Are you thinking a client would implement some, but not all changes? >I would think that is wrong - this is a package of changes the client and server need to implement. So, the other changes would prevent the continous >Solicits? We have no good way to return separate status codes for prefix vs address and I don't see this as needed per what I just wrote?

If you don't have a good way to return separate status codes for prefix vs. address, then I doubt if the sever has a good way to determine if each of the prefix and address is NotOnLink?  Why would the Solicit not continue forever.  Then network has only one server.  The server has removed one IA type and the client 's Solicit will not be responded by the server any more.  Thus if Reply received to a Confirm has one IA type as NotOnLink, the client switches to the Information-Request with that IA type. 

Thanks,

Hemant