RE: [dhcwg] dhcpv6-24: use of anycast
Ralph Droms <rdroms@cisco.com> Sun, 12 May 2002 16:50 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 MAA21180 for <dhcwg-archive@odin.ietf.org>; Sun, 12 May 2002 12:50:46 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27046 for dhcwg-archive@odin.ietf.org; Sun, 12 May 2002 12:50:58 -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 MAA26951; Sun, 12 May 2002 12:45:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26926 for <dhcwg@optimus.ietf.org>; Sun, 12 May 2002 12:45:44 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21021 for <dhcwg@ietf.org>; Sun, 12 May 2002 12:45:31 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4CGiqHU010167; Sun, 12 May 2002 09:44:52 -0700 (PDT)
Date: Sun, 12 May 2002 12:44:52 -0400
From: Ralph Droms <rdroms@cisco.com>
To: "Bound, Jim" <Jim.Bound@hp.com>
cc: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, Thomas Narten <narten@us.ibm.com>, Ole Troan <ot@cisco.com>, dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: use of anycast
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5F@tayexc13.americas.cpqcorp.net>
Message-ID: <Pine.GSO.4.44.0205121211280.19938-100000@funnel.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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
Jim makes a good good point about anycast. Given the current discussion about anycast addresses and hosts on the ipngwg mailing list, it would be premature to specify site-local anycast for DHCPv6. What about link-local only "anycast" - perhaps that's not really "anycast" because there's no routing? Instead of an anycast address, suppose we request the reservation of a link-scoped unicast address for DHCP? If we use a unicast address, only one relay agent or server on a link can be listening on that address, right? For point-to-point links that's not a problem - there can only be one relay agent or server at the other end of the point-to-point link. I'm still not clear about multiple-access links and multicast - are there any multiple access link technologies that don't provide or emulate multicast? Is there a precedent for the reservation of a link-scoped, well-known unicast address? Using a link-scoped unicast address, the first relay agent or server to bind to the address gets to use it. I'm not familiar with the IPv6 API; I assume that an application (with sufficient privilege) can make a request to assign a specific address to an interface. I guess the stack does DAD on the requested address and the request fails if the address is already in use? I'm not thrilled with my idea - it sounds fairly ugly. Does it break or bend fewer existing standards, or require the definition of fewer new standards than the use of an anycast address? Does the assignment of a well-known link-scoped unicast address for DHCP set a precedent we'd rather not set? The use of the unicast address could be further discouraged by including a restriction that relay agents and servers MUST NOT listen on the unicast address and clients MUST NOT send messages to the unicast address on a link that supports multicast. - Ralph On Sun, 12 May 2002, Bound, Jim wrote: > Thomas, > > I am fine with this too. But what we are permitting the server to have an anycast address and the addr arch says don't do this? Will it not be kicked back again by the IESG because we did that? > > thanks > /jim > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Thursday, May 09, 2002 9:27 AM > To: 'Thomas Narten'; Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > > >> 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 > >right. > Sounds fine to me. > - Bernie > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 9:23 AM > To: Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > 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. > Understood. > > 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. > OK. > > Therefore, there is some value in providing a clear direction here > > that is also relatively easy to implement. > Agreed. > > 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 > right. > Thomas > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Ralph Droms
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Ole Troan
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- RE: [dhcwg] dhcpv6-24: use of anycast Bernie Volz (EUD)
- RE: [dhcwg] dhcpv6-24: use of anycast Bernie Volz (EUD)
- RE: [dhcwg] dhcpv6-24: use of anycast Bernie Volz (EUD)
- RE: [dhcwg] dhcpv6-24: use of anycast Bound, Jim
- Re: [dhcwg] dhcpv6-24: use of anycast Ted Lemon
- RE: [dhcwg] dhcpv6-24: use of anycast Ralph Droms
- RE: [dhcwg] dhcpv6-24: use of anycast Bernie Volz (EUD)
- RE: [dhcwg] dhcpv6-24: use of anycast Bound, Jim
- RE: [dhcwg] dhcpv6-24: use of anycast Bound, Jim
- RE: [dhcwg] dhcpv6-24: use of anycast Bound, Jim
- RE: [dhcwg] dhcpv6-24: use of anycast Ralph Droms
- RE: [dhcwg] dhcpv6-24: use of anycast Bernie Volz (EUD)