At Mon, 29 Apr 2002 12:54:51 -0700, Steve Deering wrote: > > No more so than the use of DHCP relays does. We're talking about the > IGP within a site, and taking advantage of what it already can do.
Nope, you're storing new information in the IGP that wasn't there before. But back up and take it one step at a time. In the abstract, DHCP is a multicast query, unicast response protocol. A client yells "yo, anybody got a foo server?" and gets back zero or more responses, from which it picks whichever response(s) it likes (yes, I'm oversimplifying slightly, and am completely skipping over stateful address assignment, which isn't relevant here, but in principle that's how post-address-config works using DHCP). Relay agents (again ignoring stateful address assignment) are basicly a tool for getting DHCP to work in environments that (for whatever reason) don't suport multicast in its fully glory. The key difference between the DHCP model and the anycast model is that in the case of the DHCP model it's at least possible to set things up so that the entity that's telling you where the DNS server is actually -is- the same entity as the DNS server. Thus, if the DNS servers you're using have stopped responding, you can re-ask "where's there a DNS server?" and find out who's available now. Similarly, you can keep track of which addresses you've been talking to and how well they worked (a DNS server can be up and running and still be useless due to misconfiguration, bugs, system load, network load, acts of malice, ...). In the anycast model, you're at the mercy of the system that's maintaining the anycast route: you can't query directly to find out where the DNS server is, you have to wait for the routing system to figure it out, and the routing system doesn't tell you when it change the binding between a particular anycast address and the server behind it, so you can't usefully keep track of which DNS servers have been misbehaving recently. So I stand by my previous statement that the anycast proposal moves data and functionality from the edge into the core of the network. I suspect that further discussion on this particular point would be more suitable for a beer BOF in Yokohama than for this mailing list. > (Now that I mention it, perhaps DHCP relays ought also to be replaced > by the use of a well-known, site-local anycast address.) That'd be another step towards centralization, since it assumes an environment in which there's only one[*] DHCP server that your client might want to talk to, and completely loses the capability to send the same question to whatever DHCP servers are in range. [*] Or two, or three, or whatever small fixed number of anycast addresses you choose to allocate, and to date I haven't seen an explanation of how servers anycast::1, anycast::2, and anycast::3 are supposed to sort out which one gets which anycast address without some kind of coordination mechanism that either involves yet another new protocol or something that quacks like manual configuration. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
