Subject: [dhcwg] Confirm + Reply NotOnLink

From: Mike Spengler <[email-masked]>
Date: Mon, 18 Oct 2010 14:37:36 -0500

Hi,

I'm looking for a client behavior clarification...

When a client is informed of a possible link-change event, it sends a Confirm message with an IA / IA address for a valid lease it holds. If the client receives a Reply with a NotOnLink status, what is the state of the lease and address? Should the client delete the address and lease before beginning the Solicit?  I don't see anything explicit in 3315.

Thanks in advance.

-mike

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Oct 2010 14:30:11 -0700

> When a client is informed of a possible link-change event, it sends a Confirm message with an IA / IA address for a valid lease it holds. If the client receives a Reply with a NotOnLink status, wha…

You don't have a lease.   You have an IP address with preferred and valid lifetimes, which may be arbitrarily long.   If you get NotOnLink, it means that you can't use the address anymore, because it's not valid on the link to which you're connected.   But you haven't necessarily communicated with the server that issued the address, so presumably the address is still assigned to you.

Are you asking about this for the case where the server that sent you the NotOnLink just happens to also be the server that assigned the original address?   I would advise you not to free up the lease in that case, if that is your question.

---

From: Mike Spengler <[email-masked]>
Date: Mon, 18 Oct 2010 17:04:49 -0500

> Are you asking about this for the case where the server that sent you the NotOnLink just happens to also be the server that assigned the original address?   I would advise you not to free up the le…
In this specific case, the client was actually moved and got the Confirm Reply from a new server. But I was also curious about the general case of processing a Confirm NotOnLink Reply message.

-mike

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 21 Oct 2010 09:07:05 -0500

RFC 3315 (18.1.18) states:

   When the client receives a NotOnLink status from the server in
   response to a Confirm message, the client performs DHCP server
   solicitation, as described in section 17, and client-initiated
   configuration as described in section 18.  If the client receives any
   Reply messages that do not indicate a NotOnLink status, the client
   can use the addresses in the IA and ignore any messages that indicate
   a NotOnLink status.

This "performs DHCP server solicitation ... *and* client-initiated
configuration" is a bit confusing? Perhaps it was supposed to be "or"
depending on the server-id option. I don't think we were suggesting the
client does both?

I think the intent was that the client has possibly two choices:
1. If the server-id doesn't match, send a Solicit (without any
IA_ADDR/IA_PREFIX options).
2. If the server-id does match, send a Request (without any
IA_ADDR/IA_PREFIX options).

Note that the NotOnLink status just indicates that at least one of the
addresses (or prefixes) is not valid, not that they necessarily all are.
That is one reason the client may want to hold onto the current
information but mark it as suspect -- it may be that some of the
addresses (or prefixes) are still OK?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mike Spengler
Sent: Monday, October 18, 2010 6:05 PM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] Confirm + Reply NotOnLink

On 10/18/10 16:30, Ted Lemon wrote:
>> When a client is informed of a possible link-change event, it sends a
Confirm message with an IA / IA address for a valid lease it holds. If
the client receives a Reply with a NotOnLink status, what is the state
of the lease and address? Should the client delete the address and lease
before beginning the Solicit?  I don't see anything explicit in 3315.
>
> You don't have a lease.   You have an IP address with preferred and
valid lifetimes, which may be arbitrarily long.   If you get NotOnLink,
it means that you can't use the address anymore, because it's not valid
on the link to which you're connected.   But you haven't necessarily
communicated with the server that issued the address, so presumably the
address is still assigned to you.
>
> Are you asking about this for the case where the server that sent you
the NotOnLink just happens to also be the server that assigned the
original address?   I would advise you not to free up the lease in that
case, if that is your question.
In this specific case, the client was actually moved and got the Confirm
Reply from a new server. But I was also curious about the general case
of processing a Confirm NotOnLink Reply message.

-mike

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

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 26 Oct 2010 14:53:46 -0700

> depending on the server-id option. I don't think we were suggesting the

I thought it was suggesting the client does both - starting with
Solicit and then moving on towards Request.  Not both at the same
time, but the first, and then the second.

So as an errata I would insert the word 'then' after 'and'.

This is ISC dhclient -6 behaviour, anyway, upon receiving a NotOnLink
the client starts over at Solicit with no condition.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 26 Oct 2010 15:12:45 -0700

On Mon, Oct 18, 2010 at 02:37:36PM -0500, Mike Spengler wrote:
> Confirm message with an IA / IA address for a valid lease it holds. If the
> client receives a Reply with a NotOnLink status, what is the state of the
> lease and address? Should the client delete the address and lease before
> beginning the Solicit?  I don't see anything explicit in 3315.

The state of the lease is unchanged - the Confirm/Reply does not make
any changes to the recorded state of the lease on the server side, and
the client may still cache this lease for use should it return to the
same network.  So for example, an 802.11 client may keep lease states
cached for each ESSID it has visited, so long as the leases have not
yet had all IAADDR's valid lifetimes expire.  In such a case, when the
client moves from ESSID X to ESSID Y, it may speculatively Confirm for
the addresses it had on ESSID X (optimizing for the case it has changed
ESSIDs on the same network).  A NotOnLink in this case does not mean
the client must remove the cached information on ESSID X, which it may
still try again (with a Confirm) should it be returned there. *

The addresses should be removed immediately before beginning a Solicit,
they are (all) not appropriate for the network.

I think actually RFC 3315 on the Confirm is written from a mindset that
the client is coming from a state where the interface does not have any
addresses configured yet, and so there is no language about revoking
them.  Although that may be bias due to the platforms I work on, the
interfaces are generally unconfigured in all the example reasons to
Confirm the RFC lists, this hopefully explains the confusion in your
case.

* - It is less clear to me, if the client moves through Solicit to
    Request and is assigned a lease, if the server is allowed to
    clean up the client's other leases on networks it is not attached
    to, as though the client had supplied a Release, at this later
    time (it definitely can not at confirm/reply).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Oct 2010 12:52:56 -0400

>    time (it definitely can not at confirm/reply).

I don't think it is.   To do that would create inconsistent behavior--servers that knew of clients getting new leases would behave differently than servers that were unaware of clients getting new leases, so the network on which the client got its new lease would affect independent variables in the lease database.

Since the protocol spec doesn't say to do this, the server shouldn't do it.