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

Thomas Narten <> Thu, 09 May 2002 13:26 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id JAA20184 for <>; Thu, 9 May 2002 09:26:15 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id JAA25442 for; Thu, 9 May 2002 09:26:23 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id JAA25275; Thu, 9 May 2002 09:24:24 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id JAA25244 for <>; Thu, 9 May 2002 09:24:22 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA19993 for <>; Thu, 9 May 2002 09:24:12 -0400 (EDT)
Received: from (narten@localhost) by (8.11.6/8.11.6) with ESMTP id g49DMwp05608; Thu, 9 May 2002 09:22:58 -0400
Message-Id: <>
To: "Bernie Volz (EUD)" <>
cc: Ole Troan <>, Ralph Droms <>,
Subject: Re: [dhcwg] dhcpv6-24: use of anycast
In-Reply-To: Message from "Bernie Volz (EUD)" <> of "Thu, 09 May 2002 08:07:49 CDT." <66F66129A77AD411B76200508B65AC69B4D3D6@EAMBUNT705>
Date: Thu, 09 May 2002 09:22:58 -0400
From: Thomas Narten <>
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

> The only issue with this is that DHCP usually runs as an application
> and is therefore only able to access that information which the
> lower layers (via APIs) make available.


> Determining whether multicast is supported or not is pretty standard
> from the socket API. However, determining that a particular
> interface is a specific media type may be difficult.


> Therefore, there is some value in providing a clear direction here
>  that is also relatively easy to implement.


> If all interface types provide multicast (either inherently or via
> some type of emulation), there is little need to ever use the
> anycast address and so what harm is there in specifying it.

The harm is that a) we may define something that isn't useful (which
may cause problems when deployed because some implementations choose
use the feature even if it doesn't work as intended). b) clients may
choose to send to anycast addresses, but if servers aren't configured
to deal with them, we don't get interoperability, so specifying that
clients MAY do something really implies (to me) that server SHOULD (or
maybe even MUST) be prepared to handle such packets from clients. If
the client  can't expect a server to handle something, there is little
point in clients implementing the feature either.

My general opinion: if its not clear something is useful, and it's not
obvious what the details should be, including the feature distracts
from the overall goal of getting the spec done. The more one can
remove, the fewer details that have to be gotten right. 

> What we probably should say is that the client MUST use the
> multicast address if the interface on which it is sending the
> message supports multicast. Otherwise, it may use the anycast
> address.

This is OK with me. Just so long as it's clear that the anycast usage
is only link-local and is only for reaching servers (and relay agents)
on the same link. This seems like a straightforward thing to get


dhcwg mailing list