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

Ralph Droms <rdroms@cisco.com> Thu, 01 May 2003 14:45 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14663 for <dhcwg-archive@odin.ietf.org>; Thu, 1 May 2003 10:45:27 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41EpWC15399 for dhcwg-archive@odin.ietf.org; Thu, 1 May 2003 10:51:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EpV815396 for <dhcwg-web-archive@optimus.ietf.org>; Thu, 1 May 2003 10:51:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14623 for <dhcwg-web-archive@ietf.org>; Thu, 1 May 2003 10:44:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFKr-0002Bx-00 for dhcwg-web-archive@ietf.org; Thu, 01 May 2003 10:46:57 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BFKr-0002Bu-00 for dhcwg-web-archive@ietf.org; Thu, 01 May 2003 10:46:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EnV814970; Thu, 1 May 2003 10:49:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EfD812612 for <dhcwg@optimus.ietf.org>; Thu, 1 May 2003 10:41:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13913 for <dhcwg@ietf.org>; Thu, 1 May 2003 10:34:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFB3-00020g-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:49 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BFAy-00020O-00 for dhcwg@ietf.org; Thu, 01 May 2003 10:36:44 -0400
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41EahWS018366 for <dhcwg@ietf.org>; Thu, 1 May 2003 10:36:44 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (rtp-vpn2-797.cisco.com [10.82.243.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01095 for <dhcwg@ietf.org>; Thu, 1 May 2003 10:36:43 -0400 (EDT)
Message-Id: <4.3.2.7.2.20030501094136.00b8f828@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 01 May 2003 09:52:19 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
In-Reply-To: <y7vptnpktc9.wl@ocean.jinmei.org>
References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [dhcwg] Address selection for Information-request/Reply messages
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg