Subject: RE: 15.2.1, Creation & Sending of Reconfigure-init messages

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 12:57:31 -0500

Ralph:

I was not intending to specify an order - I should have made it a bulleted list,
not a numbered list.

Perhaps it is best that the draft does not specify an order? Though I guess stating
that a server SHOULD use a configured address over any other mechanism would
be good?

- Bernie

-----Original Message-----
From: Droms Ralph [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 1:43 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: RE: 15.2.1, Creation & Sending of Reconfigure-init messages

I agree that the server may be able to use an address obtained through some 
other mechanism to contact the client.  I think that behavior should be 
captured explicitly in the list of alternatives.

Bernie - is your list intended to imply a priority ordering or should we 
tweak the text a little to indicate that the server can use, according to 
local policy, any of the alternatives?

- Ralph

At 09:04 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote:

>Jim:
>
>Agreed that if a server has been pre-configured with an address (or
>learns of it some other way), it can communicate. I'm just talking
>about the general case here - where the server has not been pre-configured
>with that information. The server *HAS* talked to the client in the past
>since otherwise it would not care to reconfigure it (again, if some
>configuration information is present, it can talk to *ANY* client).
>
>- Bernie
>
>-----Original Message-----
>From: Jim Bound [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Thursday, July 19, 2001 9:29 PM
>To: DHCPv6 discussion list
>Subject: Re: 15.2.1, Creation & Sending of Reconfigure-init messages
>
>I don't agree with number 3.  A server who never gave the client its
>address or even talkd to it can send a reconfigure-init to it.  How it
>knew the clients address is implementation defined.  This behavior is
>important.
>
>/jim
>
>On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote:
>
> > I believe Section 15.2.1 of -19 needs some edits.
> >
> > It says:
> >
> >    The server unicasts the Reconfigure-init message to one client.  The
> >    server may unicast Reconfigure-init messages to more than one client
> >    concurrently; for example, to reliably reconfigure all known clients,
> >    the server will unicast a Reconfigure-init message to each client.
> >
> > Can we specify this a bit more tightly. What does "server unicasts"
> > mean? Does that mean directly to the client?
> >
> > Well, consider that the server may not be able to do this. Why?
> > 1) If the server did not assign any addresses to the client (just gave
> > it configuration information), how does it know how to contact the
> > client directly? All it may have is the client's link local address
> > (and the relay's address if relayed).
> > 2) If the server did assign addresses, it may be that those addresses
> > are not of sufficient scope for the server to use to reach the client
> > directly. Even if they are, which address should it use (this may be
> > less of an issue but what if the preferred lifetimes have all elapsed
> > and the client may have removed the address - or *MUST* a client retain
> > the address until the valid lifetime expires?).
> >
> > Therefore, I would suggest that the text be revised to indicate HOW
> > the server unicasts.
> >
> > I suggest the following text:
> >
> >   The server unicasts to the client by using one of the following
> >   methods:
> >   1) If the client is on one of the server's interfaces, the clients
> >   link local address is used. (The client's link local address must
> >   have been saved from a previous communication from the client.)
> >   2) If the client has been assigned an address of sufficient scope
> >   for the server to use in communicating with it and that address
> >   is still preferred, this address MAY be used.
> >   3) Otherwise, the Reconfigure-Init should be unicast to a relay
> >   agent (as a Relay-reply) and that relay will unicast it to the
> >   client's link local address. (The client's link local address and
> >   the relay's address must have been saved from a previous communication
> >   from the client; or a suiteable relay agent's address is known by
> >   some mechanism by the server.)
> >
> > BTW, there may be 4 (or more correctly, it should be 2.5) ... if the
> > client has unicast a packet directly to the server (because of the
> > Server Unicast Option, Section 18.10), the server could save that
> > address and use it. However, if the server did not assign this address,
> > it may have no information about the validity of that address and
> > therefore I did not include it.
> >
> > > Bernie Volz
> > > Chief Technical Officer - DNS & DHCP Development Unit
> > > Ericsson, Inc.
> > > Tel: +1-508-875-3162
> > > Fax: +1-508-875-3018
> > > Mobile: +1-617-513-9060
> > > <mailto:[email-masked]>mailto:[email-masked]
> > >
> > >
> >

---

From: Droms Ralph <[email-masked]>
Date: Thu, 26 Jul 2001 13:42:49 -0400

- Ralph