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. 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. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
