Hello,
A few comments.
As stated before by others, this seems like a hack. But sometimes hacks
can be good. Anyway..
==> 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).
==> 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.
==> I think everyone agrees that security considerations is a bit of
handwaving :-)
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?
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).
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?
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).
On Thu, 9 May 2002, Brian Haberman wrote:
> Just to give everyone the ability to review the draft, here is
> the announcement of the draft outlining changes to MLD to support
> hosts announcing their membership in anycast groups. Ideally, these
> changes will get incorporated into the MLDv2 spec at some point.
>
> Regards,
> Brian
>
> [EMAIL PROTECTED] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> > Title : Host-based Anycast using MLD
> > Author(s) : B. Haberman, D. Thaler
> > Filename : draft-haberman-ipngwg-host-anycast-01.txt
> > Pages : 5
> > Date : 08-May-02
> >
> > This specification defines extended uses of the Multicast Listener
> > Discovery protocol to support hosts participating in anycast groups.
> > The extensions presented in this document allow hosts to notify the
> > routing system of membership changes in an anycast group.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-host-anycast-01.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-haberman-ipngwg-host-anycast-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > [EMAIL PROTECTED]
> > In the body type:
> > "FILE /internet-drafts/draft-haberman-ipngwg-host-anycast-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> > ------------------------------------------------------------------------
> > Content-Type: text/plain
> > Content-ID: <[EMAIL PROTECTED]>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
