Subject: [Dhcpv6bis] Server behavior for Renew/Rebind in RFC3315 and RFC3633

From: Marcin Siodelski <[email-masked]>
Date: Tue, 18 Feb 2014 11:55:22 +0100

I was recently going through the RFC3315 and RFC3633 sections which
describe server behavior for Renew and Rebind. I found stateful issues
draft helpful in understanding the desired behavior of the server for
IA_NA processing. Specifically, the "stateful issues" draft clarifies
that the server sends NoBinding status if it can't find existing lease
for the particular IA_NA (and when it doesn't allocate it).
At the same time, the RFC3633 section 12.2 says that delegating router
sets lifetime 0 for the IA_PDs for which there is no binding entry:
"If the delegating router finds that any of the prefixes are not in
the requesting router's binding entry, the delegating router returns
the prefix to the requesting router with lifetimes of 0."

This brings two questions:
- Do we desire the same behavior for Renew/Rebind of IA_NA and IA_PD?
In particular, that server may allocate the PD if there is no binding
for it?
- Should server send NoBinding option (instead of setting lifetime to
0) if it doesn't allocate the PD and there is no corresponding binding
entry?

If any of the above is true, should it be addressed in stateful issues
draft or RFC3315bis?

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Feb 2014 10:13:47 -0500

> If any of the above is true, should it be addressed in stateful issues

Isn't 3315bis intended to subsume stateful-issues?

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 18 Feb 2014 16:21:24 +0100

It is. I am just wondering if anything I raised should be addressed in
stateful issues draft first, and then be merged along with other
changes from stateful issues draft to bis doc. Or, it should go
directly to bis document. Or... they are not real issues because there
is some reasoning behind having different behavior for PDs vs IAs.

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Feb 2014 10:56:44 -0500

On Feb 18, 2014, at 10:21 AM, Marcin Siodelski <[email-masked]> wrote:
> I am just wondering if anything I raised should be addressed in

You might want to ask Ralph and Ole why they did it differently.   I think this has come up before but I don't remember the reasoning.   In any case, if you make an incompatible change you will have to figure out how old implementations of clients and servers can still interoperate with new.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Feb 2014 15:59:41 +0000

Hi Marcin:

When we do 3315bis, I would like to assure that we cover all of the cases for the packet processing. If you have revised text that you want in Stateful Issues, please propose it. I do suspect that the current Stateful Issues draft does not cover all cases. Note that some cases may depend on server policy.

I think the basic logic here is (I will use "lease" to mean either an address or prefix delegation):
- Rebind is different than Renew in that it has essentially the same issues as Rapid Commit does. Since the Rebind can be processed by all servers, care must be used if anything "new" must be allocated to the client.
- Both should attempt to locate existing resources (bindings and leases) and renew them.
- In some cases, new resources may be allocated (either new leases to existing bindings, or to new bindings).
- An unknown binding (to the server) should NOT automatically result in NoBinding for that binding. It should be possible for the server to treat this as a Request (for that binding) and add the binding and assign leases. Exactly which cases should return NoBinding or NoAddrsAvail/NoPrefixAvail is something that needs to be considered and could certainly be influenced by server policy.
- 0 lifetimes should be used to indicate to the client stop using that particular lease, for whatever reason (not on link or no longer appropriate for that client).

Request/Renew/Rebind should essentially have the same basic processing but will have subtle differences:
- Request implies that the client is NOT using the leases. Thus, the server is much freer to ignore requested leases (rather than return 0 lifetimes).
- Renew and Rebind indicate that the client is using the leases. Therefore, the server should attempt to extend the lease, provide new leases, or indicate problems (i.e., 0 lifetimes for 'bad' leases).
- Rebind has to be more restricted than Renew because of the possibility that multiple servers will respond and so allocating new leases is problematic (except in cases where Rapid Commit would be allowed).

I am sure I forgot an issue or two in the above cases. 3315 does have a mismatch of text in various cases - i.e., the general "Reply" processing covers more than the specific server request processing cases.

Perhaps we can have a discussion about how to write this up and what the processing should be and include it in a revised stateful issues draft. Note however that the stateful issues draft, which is there to revise 3315 primarily, has to be careful to use RFC 3315 terminology and so may not be as clear as it could be with regard to Prefix Delegation.

What about us (you and me, perhaps others) spending some time in London hashing this out (actually writing the revised text!!)? We can then provide it to a wider audience (DHCPv6bis first) and the DHC WG? I assume you'll be at London IETF?

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Tuesday, February 18, 2014 5:55 AM
To: [email-masked]
Subject: [Dhcpv6bis] Server behavior for Renew/Rebind in RFC3315 and RFC3633

I was recently going through the RFC3315 and RFC3633 sections which describe server behavior for Renew and Rebind. I found stateful issues draft helpful in understanding the desired behavior of the server for IA_NA processing. Specifically, the "stateful issues" draft clarifies that the server sends NoBinding status if it can't find existing lease for the particular IA_NA (and when it doesn't allocate it).
At the same time, the RFC3633 section 12.2 says that delegating router sets lifetime 0 for the IA_PDs for which there is no binding entry:
"If the delegating router finds that any of the prefixes are not in the requesting router's binding entry, the delegating router returns the prefix to the requesting router with lifetimes of 0."

This brings two questions:
- Do we desire the same behavior for Renew/Rebind of IA_NA and IA_PD?
In particular, that server may allocate the PD if there is no binding for it?
- Should server send NoBinding option (instead of setting lifetime to
0) if it doesn't allocate the PD and there is no corresponding binding entry?

If any of the above is true, should it be addressed in stateful issues draft or RFC3315bis?

Marcin

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

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 18 Feb 2014 23:03:17 +0100

> What about us (you and me, perhaps others) spending some time in London hashing this out (actually writing the revised text!!)? We can then provide it to a wider audience (DHCPv6bis first) and the…

Sounds like a good plan. I will try to gather some use cases and we
can go over it in London.

Marcin