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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 19 Jul 2001 21:04:15 -0500

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]]
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]
> > 
> > 
>

---

From: Jim Bound <[email-masked]>
Date: Fri, 20 Jul 2001 00:04:07 -0400 (EDT)

ack bernie...sorry I was being anal...(plus I want to build one of those
for IPv6 transition :----))

/jim