Subject: [dhcwg] Address selection for Information-request/Reply messages

From: Ralph Droms <[email-masked]>
Date: Thu, 01 May 2003 09:52:19 -0400

At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:

>1. address selection of Information-request/Reply exchanges
>
>According to the DHCPv6 base spec, the client should send Information
>Request messages to the All_DHCP_Relay_Agents_and_Servers multicast
>address (FF02::1:2).  However, doesn't it make much sense to allow the
>client to send the requests to the All_DHCP_Servers multicast address
>FF05::1:3?  Since the stateless usage assumes the client has obtained
>its IPv6 addresses through some other mechanism, I don't see a reason
>that the client cannot do so.  If we allow this, the client can access
>an off-link server without relying on a relay agent, which would help
>the deployment.

On the other hand, we don't want to require deployment of multicast
to enable stateless DHCPv6.

One possibility would be to allow the use of All_DHCP_Servers, with
an explicit warning that a site that doesn't implement multicast
MUST use relay agents AND the relay agents must listen to
All_DHCP_Servers (which is a change from the current spec).  In
fact, it would be important to note that a site MUST NOT both
implement multicast and configure relay agents to listen on
All_DHCP_Servers, as such a configuration would result in the
servers receiving multiple copies of client messages.

- Ralph

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 01 May 2003 09:55:35 -0400

At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>2. how to invalidate stale configuration parameters
>
>The stateless usage does not have the notion of Renew or Rebind.  So,
>how the client can purge configuration parameters (e.g. DNS addresses)
>when they become invalidated?  I guess we need a some kind of
>"timeout" parameter, which suggests to the client that it refresh the
>parameters in a certain period.

Bernie responded to this issue:

>There are three mechanisms available: 
>
>a. Whenever the client would normally determine that its stateless addresses 
>are suspect, after confirming them or obtaining new addresses, it can use 
>Information-Request to obtain new parameters. Note that a client may also 
>use triggers such as existing address lifetimes expiring (if a prefix is 
>has expired, it likely means some changes to the networks configuration and 
>hence doing an Information-Request to obtain updated parameters may be in 
>order). 
>
>b. The server can send a Reconfigure provided the client has communicated it 
>is able/willing to support this in the Information-Request. 
>
>c. The client is free to do Information-Requests at times of its choosing 
>(there is no prohibition against doing this). Of course, the client 
>should not do this too frequently. 
>
>If someone feels these mechanisms are insufficient, they could always write 
>a draft that specifies an "Information Lifetime" or "Information Renewal Time" 
>at which point the client could refresh the information. This option could 
>specify T1 and T2 times - at T1 the client renews by including the server 
>identifier option of the server that gave it the configuration parameters, at 
>T2 it removes this option and any server may respond to the Information-Request. 

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 01 May 2003 09:58:56 -0400

At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>3. how to restart the stateless procedure
>
>It would be useful if we had a guideline where the client should
>restart the Information-request/Reply exchanges, particularly when the
>client is a nomadic host moving link to link.  Section 18.1.2 of the
>base specification can be a good example of this.

Good point.  I'll add text based on the text from 18.1.2
in dhcpv6-28.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 01 May 2003 10:07:10 -0400

The following comment was posted to the dhcwg mailing list
during the WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt
Because the issue touches on RFC 2461 and RFC 2462, I've
cross-posted to both the ipv6 and dhc WG mailing lists.  Please
respond to the [email-masked] mailing list - RD

At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:

>4. interaction/consistency with RFC 246[12]
>
>How the stateless usage is related to the "Other stateful
>configuration" of router advertisements defined in RFC 2461 and 2462?
>Is the client (host) expected to start the stateless DHCPv6 when it
>receives a router advertisement with the "Other stateful
>configuration" flag being set?  If so, how can we interpret the
>"inconsistency" between the "stateless" DHCPv6 usage and the
>"stateful" router advertisement flag?  Perhaps this is just a matter
>of wording.  But, if RFC 2461 really intended a "stateful" protocol
>(i.e., where a server maintains lease state for the other
>configuration parameters), we may need to consider the gap as a
>fundamental architecture issue.

Well, I guess we first need to agree that draft-ietf-dhc-dhcpv6-stateless-00.txt
meets the expectation of "Other stateful configuration" in RFC 2461.
I intended draft-ietf-dhc-dhcpv6-stateless-00.txt to be the
configuration protocol used when the "Other stateful configuration"
flag is set.  Is there any objection to explicitly specifying
draft-ietf-dhc-dhcpv6-stateless-00.txt for this use?

If there is no objection, we'll need to adjust the words
to make the connection explicit and avoid confusion...

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Fri, 02 May 2003 02:17:09 +0700

Date:        Thu, 01 May 2003 09:52:19 -0400
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | Infact, it would be important to note that a site MUST NOT both
  | implement multicast and configure relay agents to listen on
  | All_DHCP_Servers, as such a configuration would result in the
  | servers receiving multiple copies of client messages.

Surely that happens with relay agents anyway?   Any site with half a brain,
or more, configures multiple relay agents for redundancy (assuming it also
has multiple routers for redundancy of course).   If the protocol can't
handle multiple copies of messages being delivered to the servers, it badly
needs fixing (but I actually doubt it has that defect).

kre