Re: [dhcwg] dhcpv6-24: use of anycast

Ralph Droms <rdroms@cisco.com> Wed, 08 May 2002 15:09 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11279 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:09:29 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04465 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:09:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04198; Wed, 8 May 2002 11:08:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04171 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:08:13 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11023 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:08:04 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (sjc-vpn1-877.cisco.com [10.21.99.109]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA24968; Wed, 8 May 2002 11:07:41 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020508110115.031eaab0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 08 May 2002 11:07:35 -0400
To: Thomas Narten <narten@us.ibm.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] dhcpv6-24: use of anycast
Cc: dhcwg@ietf.org
In-Reply-To: <200205081459.g48ExTa19129@rotala.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

Thomas - the use of anycast is to allow the use of DHCP on links that do 
not support multicast.  The intention is to use anycast just across the 
link to which the client is attached; a relay agent forward messages across 
the rest of the path to the server.

More comments in line.

At 10:59 AM 5/8/2002 -0400, Thomas Narten wrote:
>Seems to me that the anycast text is a bit underspecified. It's also
>not clear to me exactly what problem the anycast text is trying to
>address.
>
> > 13. Transmission of messages by a client
> >
> >    Unless otherwise specified, a client sends DHCP messages to the
> >    All_DHCP_Relay_Agents_and_Servers or the DHCP_Anycast address.
>
>This is ambiguous. What should clients actually implement by default?
>This document should make it clear what clients should implement. For
>example try one and if it doesn't work, try the other? Leaving when to
>use anycast to the implementor without guidelines will likely lead to
>interoperability problems, with different implementations doing
>different things.

Should read "send to All_DHCP_Relay_Agents_and_Servers unless link does not 
support multicast, in which case used DHCP_Anycast"


> >    If the client is attached to a link that supports multicast
> >    transmission, the client sends DHCP messages to the
> >    All_DHCP_Relay_Agents_and_Servers address.  If the client is
>
>My understanding is that all IPv6 links support multicast by
>definition. If the underlying network doesn't, it must be
>emulated. Note that multicast is needed for Neighbor Discovery, which
>all IPv6 nodes have to implement.

If all IPv6 links support multicast, then we don't need the anycast address
for DHCP.


> >    When a client sends a DHCP message to the DHCP_Anycast address, it
> >    MUST use an address assigned to the interface for which the client
> >    is interested in obtaining configuration, which is suitable for use
> >    by the server in responding to the client, as the source address in
> >    the header of the IP datagram.  See "Default Address Selection for
> >    IPv6" [4] for more details.
>
>Don't you also need to say that anycast can only be used if the client
>already has a properly scoped address? It seems to me that anycast
>isn't very useful for the *client*. I.e, let it always send to the
>relay agent and let the relay agent deal with anycast vs. mcast.

We're extending the use of anycast to include direct communication
with the server, which is parallel to the use of unicast (under the
control of the server).


>Or, is this specifically restricted to the information-request
>message? If so, might be good to say that.

No, it's not intended to be specific to Information-request.


>In private mail, Ralph asked:
>
> > Good question to ask...How about words to the effect of "if the link is
> > connected to an NBMA link, use anycast; otherwise, use multicast"?
>
>What is an NBMA link? Who defines what that is? I'm not sure there is
>a well-defined definition of NBMA link.
>
>Thomas
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg