Charlie, "Charles E. Perkins" wrote: > > Hello Brian, > > Your points are very well taken. My main suggestion for the > immediate term was to relax some restrictions on well-known > anycast addresses located in their subnets. It is really > easier if there's just one host, too. The other things > will take more work. > > >From that context, I'll just add a few more comments inline: > > Brian Haberman wrote: > > 1. Host-to-router notification protocol (this is taken care of by > > changes to mld proposed in draft-haberman-ipngwg-host-anycast) > > What happens if you have a host on a link responding to an anycast > address on that link? Then other hosts on that link won't be able > to easily discern whether the router "liked" the anycast addressable > host or not. I can imagine some very nasty ways to avoid even this > scenario, but I can't believe we'd really want to enforce them.
I haven't thought it all through, but perhaps there is a way to handle the on-link case with ND. > > > 2. Security: at a minimum some form of authentication to allow > > routers to determine if hosts are allowed to join an anycast > > group > > Similar comment to the on-link case for (1). Furthermore, the > security requirements for an anycast group depend on the nature > of the anycast group, don't they? It might typically be quite > unimportant to securely restrict participation in an anycast > group geared towards local broadcast of streaming audio of classical > guitar music, or a webcam of the cows in the pasture. Definitely, the nature of the group will help determine the security requirements of that group. However, I would not advocate the use of anycast for some of your examples. :) The security requirements of membership in an anycast group, I believe, is much more important than multicast security requirements. The primary reason is that a rogue node can launch a very effective DoS attack by joining an anycast group. Since the packet goes to one member of the group, a rogue can easily blackhole traffic to the group for portions of a network. > > > 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 > > Right! But the latter is often true for any service. The anycast nature > of the addressability of inter-domain isn't appreciably harder, otherwise, > than handling anycast groups in general, is it? It is harder in the fact that the current mechanism of anycast routing requires host routes. In the intra-domain case, anycast routes may still aggregate, but that may not be true inter-domain. Especially when members of the same anycast group span multiple, independent networks. > > > 4. Possibly a draft that documents any impacts on any existing > > protocols (routing protocols, TCP, etc.) > > This would be very important. > > > It should also be noted that this is probably way too much work to do > > in the IPv6 WG. > > It's way too much work for me too :-) I'm not really suggesting that > the general case be made completely open prior to this work getting > done. I was more suggesting that there are useful special cases that > do not present any appreciable downside. Regards, 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] --------------------------------------------------------------------
