idnits 2.17.1 draft-haberman-ipngwg-host-anycast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7834 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual submission B. Haberman 2 Internet Draft 3 draft-haberman-ipngwg-host-anycast-01.txt D. Thaler 4 May 2002 Microsoft 5 Expires November 2002 7 Host-based Anycast using MLD 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [RFC 2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This specification defines extended uses of the Multicast Listener 31 Discovery protocol to support hosts participating in anycast groups. 32 The extensions presented in this document allow hosts to notify the 33 routing system of membership changes in an anycast group. 35 1. Introduction 37 This specification defines extended uses of the Multicast Listener 38 Discovery protocol [RFC 2710] to support hosts participating in 39 anycast groups. The extensions presented in this document allow 40 hosts to notify the routing system of membership changes in an 41 anycast group, just as MLD currently allows hosts to notify the 42 routing system of membership changes in a multicast group. 44 1.1 Terminology 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC 2119]. 50 Haberman, Thaler 1 51 2. Overview 53 Like multicast, hosts participating in an anycast group must be able 54 to notify the routing system of changes in their group membership 55 status (joins and leaves). Routers must be able to query hosts as 56 to their membership status. In fact, for multicast and anycast, the 57 host-to-router membership communications is the same. 59 For this reason, the existing MLD messages can be extended to 60 support the host-to-router membership exchanges for anycast groups. 61 The following sections will detail the modifications needed for both 62 hosts and routers. 64 3. Host Behavior 66 3.1 Joining An Anycast Group 68 A host will generate an MLD Report message when it wishes to join an 69 anycast group. The host will set the Multicast Address field of the 70 Report message to the anycast group address it wishes to join. All 71 other Report message fields are initialized as specified in RFC 72 2710. 74 The IPv6 Destination Address field is set to the link-local All- 75 Routers address (FF02::2). 77 A host must also join the Solicited Node multicast address for the 78 anycast address as specified in [RFC 2373]. 80 3.2 Leaving An Anycast Group 82 When a host wishes to leave an anycast group, it will generate an 83 MLD Leave message. The host will set the Multicast Address field of 84 the Leave message to the anycast group address it wishes to leave. 85 All other Leave message fields are initialized as specified in RFC 86 2710. 88 The IPv6 Destination Address field is set to the link-local All- 89 Routers address (FF02::2). 91 A host must also leave the Solicited Node multicast address that 92 corresponds to the anycast group address as specified in [RFC 2373]. 94 3.3 Responding to Query Messages 96 When a host receives a General Query, it must generate a Report 97 message for every anycast group in which it is a member. 99 Haberman, Thaler 2 100 When a host receives an Address-Specific Query, if it is listening 101 to the specified anycast group it must generate a Report message for 102 that anycast group. 104 4. Router Behavior 106 4.1 Generating Query Messages 108 A router supporting anycast groups must manage anycast group 109 membership in the same manner that it manages multicast group 110 membership. That is, all timers and databases used for multicast 111 are also used for anycast. 113 A router generating General Query messages will initialize the MLD 114 fields in the same manner described in RFC 2710. The goal is to 115 learn of all group members on an attached segment, both anycast and 116 multicast. 118 A router generating Address-Specific Query messages will initialize 119 the MLD fields as described in RFC 2710. The Multicast Address 120 field will be set to the anycast group to be queried. The Maximum 121 Response Delay field must be set to 0. The IPv6 Destination Address 122 must be set to the Solicited Node multicast address corresponding to 123 the anycast address. 125 4.2 Receiving Report Messages 127 When a router receives an MLD Report message, an anycast Report 128 message is distinguished from a multicast Report message by the MLD 129 Multicast Address field. An anycast group address can be managed in 130 the same manner as a multicast group address. All of the timers and 131 state machines defined in RFC 2710 also apply to anycast group 132 management. 134 The receiving router must verify that: 136 - The IPv6 Source Address is a link-local address 137 - The MLD checksum field is valid 139 4.3 Receiving Leave Messages 141 When a router receives an MLD Leave message, the anycast Leave 142 message is distinguishable from a multicast Leave message by the MLD 143 Multicast Address field. The router can manage the anycast group 144 information in the same manner as it does multicast group 145 information. The reception of an anycast Leave message must trigger 146 the transmission of an Address-Specific Query for the specified 147 anycast address. 149 Haberman, Thaler 3 150 The receiving router must verify that: 152 - The IPv6 Source Address is a link-local address 153 - The MLD checksum field is valid 155 5. Security 157 Unlike multicast, allowing nodes to join arbitrary anycast groups 158 can result in denial-of-service attacks. Whereas joining a 159 multicast group does not prevent other nodes from seeing the same 160 traffic, joining an anycast group can cause traffic previously seen 161 by another node to be redirected to the newly joining node instead. 163 To prevent such attacks, it is expected that routers will employ 164 some filtering mechanism when receiving a Report message containing 165 a non-multicast address. For example, one policy might be to deny 166 all anycast joins except those that match a configured list of 167 (source address, anycast address) pairs. 169 6. References 171 [RFC 2026] S. Bradner, "The Internet Standards Process -- 172 Revision 3", BCP 9, RFC 2026, October 1996. 174 [RFC 2710] S. Deering, W. Fenner, and B. Haberman, "Multicast 175 Listener Discovery (MLD) for IPv6", RFC 2710, October 176 1999. 178 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 179 Requirement Levels", RFC 2119, BCP14, March 1999. 181 [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing 182 Architecture, RFC 2373, July 1998. 184 Haberman, Thaler 4 185 Author's Address 187 Brian Haberman 188 1-919-949-4828 189 Email : bkhabs@nc.rr.com 191 Dave Thaler 192 Microsoft Corporation 193 One Microsoft Way 194 Redmond, WA 48105-6399 195 1-425-703-8835 196 Email: dthaler@microsoft.com 198 Haberman, Thaler 5