[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
   Individual submission                                       B. Haberman
   Internet Draft                                          Nortel Networks
   draft-haberman-ipngwg-host-anycast-00.txt                     D. Thaler
   February 2001                                                 Microsoft
   Expires August 2001


                      Host-based Anycast using MLD


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC 2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   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.


1. Introduction

   This specification defines extended uses of the Multicast Listener
   Discovery protocol [RFC 2710] 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, just as MLD currently allows hosts to notify the
   routing system of membership changes in a multicast group.


  1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC 2119].


Haberman, Thaler                                                     1



Internet Draft     Using MLD for Anycast Membership        August 2001



2. Overview

   Like multicast, hosts participating in an anycast group must be able
   to notify the routing system of changes in their group membership
   status (joins and leaves).  Routers must be able to query hosts as
   to their membership status.  In fact, for multicast and anycast, the
   host-to-router membership communications is the same.

   For this reason, the existing MLD messages can be extended to
   support the host-to-router membership exchanges for anycast groups.
   The following sections will detail the modifications needed for both
   hosts and routers.


3. Host Behavior

  3.1  Joining An Anycast Group

   A host will generate an MLD Report message when it wishes to join an
   anycast group.  The host will set the Multicast Address field of the
   Report message to the anycast group address it wishes to join.  All
   other Report message fields are initialized as specified in RFC
   2710.

   The IPv6 Destination Address field is set to the link-local All-
   Routers address (FF02::2).

   A host must also join the Solicited Node multicast address for the
   anycast address as specified in [RFC 2373].


  3.2  Leaving An Anycast Group

   When a host wishes to leave an anycast group, it will generate an
   MLD Leave message.  The host will set the Multicast Address field of
   the Leave message to the anycast group address it wishes to leave.
   All other Leave message fields are initialized as specified in RFC
   2710.

   The IPv6 Destination Address field is set to the link-local All-
   Routers address (FF02::2).

   A host must also leave the Solicited Node multicast address that
   corresponds to the anycast group address as specified in [RFC 2373].


  3.3  Responding to Query Messages

   When a host receives a General Query, it must generate a Report
   message for every anycast group in which it is a member.


Haberman, Thaler                                                     2



Internet Draft     Using MLD for Anycast Membership        August 2001


   When a host receives an Address-Specific Query, if it is listening
   to the specified anycast group it must generate a Report message for
   that anycast group.


4. Router Behavior

  4.1  Generating Query Messages

   A router supporting anycast groups must manage anycast group
   membership in the same manner that it manages multicast group
   membership.  That is, all timers and databases used for multicast
   are also used for anycast.

   A router generating General Query messages will initialize the MLD
   fields in the same manner described in RFC 2710.  The goal is to
   learn of all group members on an attached segment, both anycast and
   multicast.

   A router generating Address-Specific Query messages will initialize
   the MLD fields as described in RFC 2710.  The Multicast Address
   field will be set to the anycast group to be queried.  The Maximum
   Response Delay field must be set to 0.  The IPv6 Destination Address
   must be set to the Solicited Node multicast address corresponding to
   the anycast address.


  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 receiving router must verify that:

           - The IPv6 Source Address is a link-local address
           - The MLD checksum field is valid


  4.3  Receiving Leave Messages

   When a router receives an MLD Leave message, the anycast Leave
   message is distinguishable from a multicast Leave message by the MLD
   Multicast Address field.  The router can manage the anycast group
   information in the same manner as it does multicast group
   information.  The reception of an anycast Leave message must trigger
   the transmission of an Address-Specific Query for the specified
   anycast address.


Haberman, Thaler                                                     3



Internet Draft     Using MLD for Anycast Membership        August 2001


   The receiving router must verify that:

           - The IPv6 Source Address is a link-local address
           - The MLD checksum field is valid


5. Security

   Unlike multicast, allowing nodes to join arbitrary anycast groups
   can result in denial-of-service attacks.  Whereas joining a
   multicast group does not prevent other nodes from seeing the same
   traffic, joining an anycast group can cause traffic previously seen
   by another node to be redirected to the newly joining node instead.

   To prevent such attacks, it is expected that routers will employ
   some filtering mechanism when receiving a Report message containing
   a non-multicast address.  For example, one policy might be to deny
   all anycast joins except those that match a configured list of
   (source address, anycast address) pairs.

6. References

   [RFC 2026] S. Bradner, "The Internet Standards Process --
              Revision 3", BCP 9, RFC 2026, October 1996.

   [RFC 2710] S. Deering, W. Fenner, and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710, October
              1999.

   [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP14, March 1999.

   [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing
              Architecture, RFC 2373, July 1998.



















Haberman, Thaler                                                     4





AuthorÆs Address

   Brian Haberman
   Nortel Networks
   4309 Emperor Blvd.
   Suite 200
   Durham, NC  27703
   1-919-992-4439
   Email : haberman@nortelnetworks.com

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  48105-6399
   1-425-703-8835
   Email: dthaler@microsoft.com






































Haberman, Thaler                                                     5