Pekka, Pekka Savola wrote: > > Hello, > > A few comments. > > As stated before by others, this seems like a hack. But sometimes hacks > can be good. Anyway..
The original concept was based on the premise that group membership is similar in multicast and anycast. The hosts that are a member of a group need to report that fact to the routers. > > ==> The big picture: this deals with the situation where anycast members > are on the same link (and/or possibly even different links attached to the > same upstream router). > > This is probably the most difficult part of host anycast, but one should > also consider how one would turn these anycast MLD reports to something > usable in the routing system. This is IMO important as anycast/multicast > is very different in this sense (joining the multicast distribution tree > vs advertising one address). The routing issues are very important, but they are out of scope of reporting group membership information to the routers. The routing aspects should be covered in a separate draft. > > ==> Based on MLD, there may be implementations that check that the address > in MLD message is a multicast address and discard (probable)/send error on > such packets. Yes. And the MLD spec will need to be modified to remove that kind of check. > > ==> I think everyone agrees that security considerations is a bit of > handwaving :-) Group security in general needs more work. I am currently looking at draft-irtf-gsec-sgmv6-00.txt for help in that area. > > 4.2 Receiving Report Messages > > When a router receives an MLD Report message, an anycast Report > message is distinguished from a multicast Report message by the MLD > Multicast Address field. An anycast group address can be managed in > the same manner as a multicast group address. All of the timers and > state machines defined in RFC 2710 also apply to anycast group > management. > > ==> the router must keep track of the nodes reporting to a group, so that > packets to that anycast address can be delivered to it. Or does the > router use normal neighbour discovery and just record on which links there > may be potential anycast members for an address? Either method could be used. But given all the information that the router's group database needs to support for IGMPv3/MLDv2 anyway, it should be reasonable to keep a list of anycast members. > > 4.3 Receiving Leave Messages > > [...] The reception of an anycast Leave message must trigger > the transmission of an Address-Specific Query for the specified > anycast address. > > ==> This and some others may be more or less useless, as MLD for > multicast/anycast is different (which has only been implied in the draft, > AFAIR): the router must keep the addresses of nodes acting as (potential) > anycast group members anyway (which is not necessary for multicast). See response to the last comment. > > The receiving router must verify that: > > - The IPv6 Source Address is a link-local address > - The MLD checksum field is valid > > ==> In MLD, it is checked that the message is at least 24 bytes long too? Yep. That is covered in section 5 of RFC 2710. > > It seems to me that something like "Binding Updates" are a more natural > approach to host anycast membership problem (not counting using normal > routing system in a host). That is another possibility that has been mentioned on the list. If you look at the problem abstractly, Mobile IP is a close fit. The anycast address is the "home address" and the unicast addresses of the anycast group members are a set of "care-of addresses". Of course, if the care-of address changes, so does the machine you are talking to. 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] --------------------------------------------------------------------
