Erik, Erik Nordmark wrote: > > Brian, > > > 1. Host-to-router notification protocol (this is taken care of by > > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > > > 2. Security: at a minimum some form of authentication to allow > > routers to determine if hosts are allowed to join an anycast > > group > > > > 3. An Anycast Architecture doc that pulls all the pieces together > > and concretely describes how pieces interact, the pros and cons > > of anycast usage for intra-domain and inter-domain > > > > 4. Possibly a draft that documents any impacts on any existing > > protocols (routing protocols, TCP, etc.) > > > > Now, I have not spent time on the subject in the last 4-5 months, so I > > have not gotten much past this list. It is crucial that most of the > > issues raised by Itojun's anycast analysis draft be addressed. > > I wonder if it would also be useful to add a "anycast binding protocol" to > the above list. > Certain protocols (be it TCP or DNS resolvers wanting to verify the IP > addresses in the responses) coupled with the technical issues (such as > path MTU discovery) and operational issues (such as how to debug) of > using anycast as a source address, I think would benefit from such > a protocol with reasonable security.
Actually, I will have to let on to a little secret. I have been looking at an option for anycast that looks strikingly similar to the Home Address option in MIPv6. The idea is that a server responding to an anycast query will put the anycast address in this option and its own unicast address in the source address field. The option can be protected with an AH header, thus allowing the sender to authenticate that the response is coming from a member of the anycast group. This option would also allow for TCP connections to an anycast address. A TCP implementation could allow a connection to an anycast address as long as it recognizes the option containing the anycast address. The option would also preserve the use of RPF filtering on source addresses. > > By "reasonable security" I mean that for delivering packets to an anycast > address we depend on the routing system not being compromised (and your item #2 > above needs to preserve that). Wouldn't it be possible to use this trust in > the routing system to get a binding between an anycast address and one current > member of that address one would ask. > > I think the MIPv6 Binding Update has reuseable elements for such a protocol. > > But this is still a bit of a solution looking for a problem. I believe that there may be useful pieces in MIP that could help make anycast work. I freely admit that the anycast option is based on the home address option from MIP. I just hope that I can spend some time on the topic soon. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
