Subject: [dhcwg] lifetime of 'peer-address'

From: "David W. Hankins" <[email-masked]>
Date: Tue, 21 Aug 2007 13:09:31 -0700

I've been making an assumption, an unfounded one, based entirely upon
a lack of indication contrarywise, that the 'peer-address' field or
similarly where no relay is present the source IPv6 address of a
DHCPv6 packet is temporary state.

That is, "this is the address to send replies to this transaction" at
most and never "this is a permanent (probably link local) address you
can use now or at any time in the future to reach this endpoint."

This basic understanding was questioned on a recent discussion on
[email-masked], and I wondered what other opinions there were.

I tend to think that any expectation that a DHCPv6 client "will
always" Renew or Rebind or even Solicit when any link local addresses
have changed or disappeared is naive, so I don't think this
information can realistically be counted on.  I don't think the
client's source address is a contract for longer than it takes to
reply to the query (same of the server's or relay agent's source
addresses).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 23 Aug 2007 08:41:25 -0400

There is no contract about the link-local address, but in general why
would the client ever change that? It isn't like this address has
privacy issues (or put another way, there's no need to protect it as the
mac address is already available to others on the link).

There are actually applications where using this might come in handy.
For example, a Reconfigure message when the client has no "usable"
global address (perhaps because the global address is not reachable
directly from the DHCP server). While there's no disagreement that for a
Reconfigure a global address is better to be used, there's no reason to
prohibit relayed Reconfigure messages.

And, for Reconfigure messages, the Reconfigure Key Auth. Protocol should
prevent issues if the client has changed its link-local and a different
client is now using that link-local address.

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Aug 2007 10:35:50 -0700

> mac address is already available to others on the link).

Because of the DUID and IAID abstractions, it's entirely possible
that a client might change network devices (and thus hardware
addresses, and therefore link local addresses) without changing its
DUID or IAID.

So it's encouraged that if a system were to be given a new network
device (and therefore a new link-local), that it may still Confirm for
the same IAID,DUID pair with the old addresses (and possibly even
sessions) intact.

Since such a Confirm may reach one DHCPv6 server, but not another,
and either DHCPv6 server may answer, it's entirely possible that
the link local address would change without some servers being the
wiser.  Not to mention that I think many servers will not update
recorded information about clients on processing Confirms (I
certainly hope we never have to).

So in an infinite universe, there's at least one reason it may be so.

I think it's also possible, if highly improbable, that a client
may lose its addresses to another client on the network, normally
such as over a network disconnect, or abnormally such as when a
network partition is healed.

> client is now using that link-local address.

I agree that DHCPv6 Reconfigure is a fine place to use the link local
address and RFC3315 even gives guidance that the server could
synthesize a Relay-Reply using the client's previously known
peer-address field...I assume it can synthesize a full relay chain
based upon the most recent.  This also is dynamic information - the
server has no way of knowing whether or not the relay chain has been
changed, entire devices could be removed or replaced, resulting also
in changes in peer-address fields across the chain.

First, I think of this activity as being administrator-initiated
(directly or indirectly).  In many cases, a 'Reconfigure' tool will
probably let an operator specify the target address.  The operator can
and should be able to specify any address he knows - or thinks he
knows.  In the case of network administration systems that abstract
this - they should work well in whatever custom environments they're
tailored for.

But more importantly, Reconfigure is an operation that is accepted
to fail.  You don't need to rely on it to work - the client will
Renew eventually.  It's just an optimization.

I think it is problematic to rely upon the client's link local
address for any persistent operation where reliability is a
requirement.

For that sort of thing you really need a contract with the client
that they will continue to use an address for some length of time,
such as is implicit (and in the client's best interest) with an
addressed assigned via DHCPv6 IA_NA.

---

From: Bud Millwood <[email-masked]>
Date: Thu, 23 Aug 2007 20:15:05 +0200

> the same IAID,DUID pair with the old addresses (and possibly even

You're basically saying that a server should not use a previously recorded 
link-address during a client-initiated transaction, right? Under what 
circumstances *would* a server consider using a previously recorded link 
address for a client-initiated transaction?

- Bud

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Aug 2007 13:33:48 -0700

> link-address during a client-initiated transaction, right? Under what 

No...for uses totally external to DHCPv6 actually.  Any use in which
reliability beyond the current transaction is required.

The stipulation on [email-masked] was that "a DHCPv6 server 'knows'
the link-local addresses of all clients, because it can record the
'peer-address' field".  In context, they meant that this information
was reliable for a purpose that really couldn't be allowed to fail.

Where getting it wrong is substantially more expensive than failing a
Reconfigure; someone loses or can't get net.

I can find the mail in the archive if you like.  I'm really curious
if I'm missing something; the person's clarification was that the
server is always (reliably) updated in any event a link-local address
changes.

I haven't read that anywhere, so I'm wondering how we get from here
to there.

---

From: Bud Millwood <[email-masked]>
Date: Thu, 23 Aug 2007 22:17:06 +0200

On Thursday 23 August 2007 22:33, David W. Hankins wrote:
> > You're basically saying that a server should not use a previously
> > recorded link-address during a client-initiated transaction, right? Under
> > what
>

Aha, I see. I don't recall anything stating that the server *must* record the 
link-local address. And as far as I know there's no standard way to query a 
DHCPv6 server for a client's link-local address. But since the DHCP server 
seems the logical place to track them for a given DUID/IAID, why not store it 
and update it with CONFIRMS? If this information is needed by another 
protocol we could, for example, extend lease-query to support asking for this 
info.

- Bud

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Aug 2007 14:19:47 -0700

> protocol we could, for example, extend lease-query to support asking for this 

You sound certain that DHCPv6 servers are updated reliably...why?

This is 3 opinions for and one against, so I must be missing
something.

On the continuing subject of Confirm; a different server may answer
the Confirm without all servers seeing it, so if there's more than
one server there could be differing opinions of the client's address.
If the Confirm times out entirely (CNF_MAX_RD is 10 seconds), the
client may just continue to use their old addresses - and won't emit
more messages until t1.  So no server may have the up-to-date address.

That's even if you update your database on Confirms, which rather
ruins its lightweightness (a quality I rather like since operators
can manipulate t1, but they can't control how often boxes reboot).

---

From: Bud Millwood <[email-masked]>
Date: Thu, 23 Aug 2007 23:42:57 +0200

On Thursday 23 August 2007 23:19, David W. Hankins wrote:
> > Aha, I see. I don't recall anything stating that the server *must* record
> > the link-local address. And as far as I know there's no standard way to
> > query a DHCPv6 server for a client's link-local address. But since the
> > DHCP server seems the logical place to track them for a given DUID/IAID,
> > why not store it and update it with CONFIRMS? If this information is
> > needed by another protocol we could, for example, extend lease-query to
> > support asking for this info.
>

No, Ḯ'm just thinking out loud. Your argument against is a valid 
consideration, because it's true that multiple DHCP servers may have 
differing data for a client's LL address, and all servers may have stale 
data.

I see no way to guarantee that even one DHCP server has a LL address for a 
client that is *definitely* known to be valid. Having said that, it may be 
highly likely that it is valid. Is that useful for whoever needs the info?

Is there a better way to identify a client as being the same machine after it 
changes its LL address? That's exactly what DUID gives you.

So unless there's a mechanism that mimics DUID that I'm not aware of, I guess 
the conclusion is that you can't know for sure, but the DHCP server can give 
you a reasonable guess. <glad to be of service folks, we'll be here all 
week> :)

- Bud

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 28 Aug 2007 11:27:36 -0400

I fully agree that use of this peer-address information (beyond the original transaction) is problematic. It is more problematic than a client's addresses; after all, the client might have negotiated different addresses with a different DHCP server without having released the current addresses so they can't be relied on either. Any DHCPv6 related information is potentially stale; statefully assigned addresses or delegated prefixes less so than the link-local addresses (i.e., "peer-address" or source address).

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]] 
Sent: Thursday, August 23, 2007 5:43 PM
To: [email-masked]
Subject: Re: [dhcwg] lifetime of 'peer-address'

- Bud