idnits 2.17.1 draft-haberman-ipngwg-host-anycast-00.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 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 (August 2001) is 8289 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission B. Haberman 3 Internet Draft Nortel Networks 4 draft-haberman-ipngwg-host-anycast-00.txt D. Thaler 5 February 2001 Microsoft 6 Expires August 2001 8 Host-based Anycast using MLD 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC 2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This specification defines extended uses of the Multicast Listener 32 Discovery protocol to support hosts participating in anycast groups. 33 The extensions presented in this document allow hosts to notify the 34 routing system of membership changes in an anycast group. 36 1. Introduction 38 This specification defines extended uses of the Multicast Listener 39 Discovery protocol [RFC 2710] to support hosts participating in 40 anycast groups. The extensions presented in this document allow 41 hosts to notify the routing system of membership changes in an 42 anycast group, just as MLD currently allows hosts to notify the 43 routing system of membership changes in a multicast group. 45 1.1 Terminology 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC 2119]. 51 Haberman, Thaler 1 52 2. Overview 54 Like multicast, hosts participating in an anycast group must be able 55 to notify the routing system of changes in their group membership 56 status (joins and leaves). Routers must be able to query hosts as 57 to their membership status. In fact, for multicast and anycast, the 58 host-to-router membership communications is the same. 60 For this reason, the existing MLD messages can be extended to 61 support the host-to-router membership exchanges for anycast groups. 62 The following sections will detail the modifications needed for both 63 hosts and routers. 65 3. Host Behavior 67 3.1 Joining An Anycast Group 69 A host will generate an MLD Report message when it wishes to join an 70 anycast group. The host will set the Multicast Address field of the 71 Report message to the anycast group address it wishes to join. All 72 other Report message fields are initialized as specified in RFC 73 2710. 75 The IPv6 Destination Address field is set to the link-local All- 76 Routers address (FF02::2). 78 A host must also join the Solicited Node multicast address for the 79 anycast address as specified in [RFC 2373]. 81 3.2 Leaving An Anycast Group 83 When a host wishes to leave an anycast group, it will generate an 84 MLD Leave message. The host will set the Multicast Address field of 85 the Leave message to the anycast group address it wishes to leave. 86 All other Leave message fields are initialized as specified in RFC 87 2710. 89 The IPv6 Destination Address field is set to the link-local All- 90 Routers address (FF02::2). 92 A host must also leave the Solicited Node multicast address that 93 corresponds to the anycast group address as specified in [RFC 2373]. 95 3.3 Responding to Query Messages 97 When a host receives a General Query, it must generate a Report 98 message for every anycast group in which it is a member. 100 Haberman, Thaler 2 101 When a host receives an Address-Specific Query, if it is listening 102 to the specified anycast group it must generate a Report message for 103 that anycast group. 105 4. Router Behavior 107 4.1 Generating Query Messages 109 A router supporting anycast groups must manage anycast group 110 membership in the same manner that it manages multicast group 111 membership. That is, all timers and databases used for multicast 112 are also used for anycast. 114 A router generating General Query messages will initialize the MLD 115 fields in the same manner described in RFC 2710. The goal is to 116 learn of all group members on an attached segment, both anycast and 117 multicast. 119 A router generating Address-Specific Query messages will initialize 120 the MLD fields as described in RFC 2710. The Multicast Address 121 field will be set to the anycast group to be queried. The Maximum 122 Response Delay field must be set to 0. The IPv6 Destination Address 123 must be set to the Solicited Node multicast address corresponding to 124 the anycast address. 126 4.2 Receiving Report Messages 128 When a router receives an MLD Report message, an anycast Report 129 message is distinguished from a multicast Report message by the MLD 130 Multicast Address field. An anycast group address can be managed in 131 the same manner as a multicast group address. All of the timers and 132 state machines defined in RFC 2710 also apply to anycast group 133 management. 135 The receiving router must verify that: 137 - The IPv6 Source Address is a link-local address 138 - The MLD checksum field is valid 140 4.3 Receiving Leave Messages 142 When a router receives an MLD Leave message, the anycast Leave 143 message is distinguishable from a multicast Leave message by the MLD 144 Multicast Address field. The router can manage the anycast group 145 information in the same manner as it does multicast group 146 information. The reception of an anycast Leave message must trigger 147 the transmission of an Address-Specific Query for the specified 148 anycast address. 150 Haberman, Thaler 3 151 The receiving router must verify that: 153 - The IPv6 Source Address is a link-local address 154 - The MLD checksum field is valid 156 5. Security 158 Unlike multicast, allowing nodes to join arbitrary anycast groups 159 can result in denial-of-service attacks. Whereas joining a 160 multicast group does not prevent other nodes from seeing the same 161 traffic, joining an anycast group can cause traffic previously seen 162 by another node to be redirected to the newly joining node instead. 164 To prevent such attacks, it is expected that routers will employ 165 some filtering mechanism when receiving a Report message containing 166 a non-multicast address. For example, one policy might be to deny 167 all anycast joins except those that match a configured list of 168 (source address, anycast address) pairs. 170 6. References 172 [RFC 2026] S. Bradner, "The Internet Standards Process -- 173 Revision 3", BCP 9, RFC 2026, October 1996. 175 [RFC 2710] S. Deering, W. Fenner, and B. Haberman, "Multicast 176 Listener Discovery (MLD) for IPv6", RFC 2710, October 177 1999. 179 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 180 Requirement Levels", RFC 2119, BCP14, March 1999. 182 [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing 183 Architecture, RFC 2373, July 1998. 185 Haberman, Thaler 4 186 Author�s Address 188 Brian Haberman 189 Nortel Networks 190 4309 Emperor Blvd. 191 Suite 200 192 Durham, NC 27703 193 1-919-992-4439 194 Email : haberman@nortelnetworks.com 196 Dave Thaler 197 Microsoft Corporation 198 One Microsoft Way 199 Redmond, WA 48105-6399 200 1-425-703-8835 201 Email: dthaler@microsoft.com 203 Haberman, Thaler 5