idnits 2.17.1 draft-ietf-mboned-mzap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. == There are 9 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 92: '... MUST also be a border for the local scope zone, as defined in [1]....' RFC 2119 keyword, line 94: '... Routers SHOULD be configured so as ...' RFC 2119 keyword, line 99: '...guration, but this is NOT RECOMMENDED....' RFC 2119 keyword, line 122: '...s into the scope zone, which it SHOULD...' RFC 2119 keyword, line 140: '...than local scope SHOULD then forward t...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 15, 1997) is 9600 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) -- Missing reference section? '1' on line 442 looks like a reference -- Missing reference section? '2' on line 443 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MboneD WG 2 Internet Draft M. Handley 3 draft-ietf-mboned-mzap-00.txt ISI 4 December 15, 1997 5 Expires: June 1998 7 Multicast-Scope Zone Announcement Protocol (MZAP) 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 ABSTRACT 31 This document defines a protocol, the Multicast-Scope 32 Zone Announcement Protocol (MZAP), for discovering the 33 multicast administrative scope zones that are relevant at 34 a particular location. MZAP also provides mechanisms 35 whereby two common misconfigurations of administrative 36 scope zones can be discovered. 38 1 Status 40 This is a strawman proposal. It has not been subject to any peer 41 review or implementation. 43 2 Introduction 45 IP Multicast groups can be global scope, or they can be restricted in 46 scope using a scoping mechanism. In this document, we only consider 47 administrative scoping, as defined in [1]. An administrative scope 48 zone is defined by a set of border routers to a region of the 49 network. These border routers are configured to not pass multicast 50 traffic destined for a particular range of multicast addresses to or 51 from links leaving the scope zone. 53 Administrative scope zones may be of any size, and a particular host 54 may be within many administrative scope zones. The only zones a host 55 can assume that it is within are the global zone, and local scope 56 Local scope is defined as being the smallest administrative scope 57 zone encompassing a host, and the border is configured for addresses 58 in the range 239.255.0.0 to 239.255.255.255 inclusive. [1] specifies: 59 239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope 60 is the minimal enclosing scope, and hence is not further divisible. 61 Although the exact extent of a Local Scope is site dependent, locally 62 scoped regions must obey certain topological constraints. In 63 particular, a Local Scope must not span any other scope boundary. 64 Further, a Local Scope must be completely contained within or equal 65 to any larger scope. In the event that scope regions overlap in area, 66 the area of overlap must be in its own local scope. This implies 67 that any scope boundary is also a boundary for the Local Scope. 69 Two problems make administrative scoping difficult to deploy and 70 difficult to use: 72 o Misconfiguration is easy. It is difficult to detect scope 73 zones that have been configured so as to not be convex (the 74 shortest path between two nodes within the zone passes outside 75 the zone) or to leak (one or more border routers was not 76 configured correctly). 78 o Applications have no way to discover the scope zones that are 79 relevant to them. This makes it difficult to use admin scope 80 zones, and hence reduced the incentive to deploy them. 82 This document defines the Multicast Scope Zone Announcement Protocol 83 (MZAP) which will provide applications with information about the 84 scope zones they are within, and also provide diagnostic information 85 to detect misconfigured scope zones. 87 3 Specification 89 A multicast scope Zone Border Router (ZBR) is a router that is 90 configured to be a zone border on one or more of its interfaces. Any 91 interface that is configured to be a border for any admin scope zone 92 MUST also be a border for the local scope zone, as defined in [1]. 94 Routers SHOULD be configured so as the router itself is within the 95 scope zone. This is should in figure 1A, where router 1 is inside the 96 scope zone and has the border configuration. It is possible for the 97 first router outside the scope zone to be configured with the border, 98 as illustrated in figure 1B where routers 2 and 3 are outside the 99 zone and have the border configuration, but this is NOT RECOMMENDED. 101 ............ ................ 102 . . +O+--> . *O+--> 103 . . / 2 . /. 2 104 . 1 * . 1 + . 105 . <---+O*---+O+-> . <---+O+---*O+-> 106 . + . 3 . + . 3 107 . / . . / . 108 . zone X <-- . . zone X <-- . 109 .............. .................. 111 O - router * - border interface + - interface 113 A. Correct zone border B. Incorrect zone border 115 Figure 1: Correct admin scope zone border placement 117 This rule does not apply for local scope borders, but applies for all 118 other admin scope border routers. 120 When a ZBR router is configured correctly, it can deduce which side 121 of the boundary is inside the scope zone and which side is outside 122 it. It can also send messages into the scope zone, which it SHOULD 123 NOT be able to do if the router itself is considered outside the 124 scope zone. 126 Such a ZBR router should then send periodic Zone Announcement 127 Messages (ZAMs) for the zone for which it is configured as a border 128 from each of its interfaces that go into that scope zone. These 129 messages are multicast to the address 239.255.255.254, which is a 130 locally scoped address. 132 Each ZBR router should also listen for ZAM messages from other ZBRs 133 for the same border. The ZBR router with the lowest interface IP 134 address within the zone from those ZBRs forming the zone border 135 becomes the zone-id router for the zone. The combination of this IP 136 address and the base address of the scoping range server to uniquely 137 identify the scope zone. 139 Every local scope ZBR that receives any ZAM for a scope zone other 140 than local scope SHOULD then forward the ZAM out of all the other 141 interfaces that are in different local scope zones except ones that 142 form a border for the zone described in the ZAM. It adds the zone-id 143 of the local scope zone that the message came from to the ZAM path 144 list before doing so. A local scope ZBR receiving a ZAM with a non- 145 null path list MUST NOT forward that ZAM back into a local scope zone 146 that is contained in the path list. This process is illustrated in 147 figure 2. 149 in 151 Figure 2: ZAM Message Flooding 153 The packet also contains a Zones Traveled Limit. If the number of 154 Local Zone IDs in the ZAM path becomes equal to the Zones Traveled 155 Limit, the packet should be dropped. Zones Traveled Limit is set when 156 the packet is first sent, and defaults to 32, but can be set to a 157 lower value if a network administrator knows the expected size of the 158 zone. 160 Addition messages called Zone Convexity Messages (ZCM) SHOULD also be 161 sent to the second highest address in the scope zone range itself 162 (For example, if the scope zone border is for 239.1.0.0 to 163 239.1.0.255, then these messages should be sent to 239.1.0.254.) As 164 these are not locally scoped packets, they are simply multicast 165 across the scope zone itself, and require no path to be built up, or 166 forwarding by local scope zone ZBRs. These messages are used to 167 detect non-convex admin scope zones, as illustrated in figure 3. Here 168 Router B and Router C originates ZCM messages, each reporting each 169 other's presence. Router D cannot see Router B's messages, but sees 170 Router C's report of Router B, and so concludes the zone is not 171 convex. 173 in 175 Figure 3: ZAM Message Flooding 177 3.1 Packet Formats 179 Zone Announcement Message (IPv4) 181 The format of a Zone Announcement Message is shown in figure 4. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | V=0 |R| PTYPE | ZT | ZTL | IP | MLEN | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Zone Base Address | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Message Origin | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Zone ID Address | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Local Zone ID Address 0 | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Router Address 0 | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 ..... 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Local Zone ID Address N | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Router Address N | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Zone Name | 205 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 4: Zone Announcement Message Format 211 The fields are defined as follows: 213 Version (V): 3 bits The version defined in this document is version 214 0. 216 Respond (R): 1 bit When set to 1, this bit indicates that a router 217 MAY generate a Zone Limit Exceeded message in response to this 218 ZAM message. When set to zero, a router MUST NOT generate a Zone 219 Limit Exceeded message in response to this message. 221 Packet Type (PTYPE): 4 bits A Zone Announcement Message has PTYPE=0. 223 Zone Traveled (ZT): 8 bits This gives the number of Local Zone IDs 224 contained in this message path. 226 Zones Traveled Limit (ZTL): 8 bits This gives the limit on number of 227 local zones that the packet can traverse before it MUST be 228 dropped. 230 IP Protocol Version (IP): 3 bits This indicates the format of the 231 following packet. The following values are defined: 233 0: IPv4 235 1: IPv6 237 Mask length (MLEN): 5 bits This gives the mask length which together 238 with the zone base address defines the range of addresses that 239 form the border to this zone. For example, if the zone is a 240 border for 239.1.0.0 to 239.1.0.255, then MLEN has the value 24. 241 A value of zero means all the bits are included in the mask, and 242 the zone is a border for a single address. 244 Zone Base Address: 32 bits This gives the base address for the scope 245 zone border. For example, if the zone is a border for 239.1.0.0 246 to 239.1.0.255, then Zone Base Address is 239.1.0.0. 248 Message Origin: 32 bits This gives the IP address of the interface 249 that originated the ZAM message. 251 Zone ID Address: 32 bits This gives the lowest IP address that has 252 been observed in the zone sending ZAM messages. Together with 253 Zone Base Address and MLEN it forms a unique ID for the zone. 255 Zone Path: multiple of 64 bits The zone path is a list of 32 bit 256 Local Zone ID Addresses (the Zone ID Address of a local zone) 257 through which the ZAM message has passed, and 32 bit IP 258 addresses of the router that forwarded the packet. Every local 259 scope router that forwards the ZAM across a local scope boundary 260 MUST add the Local Zone ID Address of the local zone that the 261 packet was received from and its own IP address to the end of 262 this list, and increments ZT accordingly. The zone path is 263 empty which the ZAM message is first sent. 265 Zone Name: multiple of 8 bits The Zone Name is an ISO 10646 character 266 string in UTF-8 encoding indicating the name given to the scope 267 zone (eg: "ISI-West Site"). It should be relatively short and 268 MUST be less that 256 bytes in length. All the border routers to 269 the same region SHOULD be configured to give the same Zone Name, 270 or a zero length string MAY be given. A zero length string is 271 taken to mean that another router is expected to be configured 272 with the zone name. Having ALL the ZBR routers for a scope zone 273 announce zero length names should be considered an error. 275 3.1.1 Zone Limit Exceeded (ZLE) 276 This packet is sent by a local-zone border router that would have 277 exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. It 278 is only sent if the "Respond" bit in the ZAM packet is set, and it is 279 unicast to the Message Origin given in the ZAM packet. 281 The format is the same as a ZAM message, and is shown in figure 5: 283 0 1 2 3 284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | V=0 | PTYPE | ZT | ZTL | IP | MLEN | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Zone Base Address | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Message Origin | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Zone ID Address | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Local Zone ID Address 0 | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 ..... 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Local Zone ID Address N | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Zone Name | 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 5: Zone Announcement Message Format 307 All fields are copied from the ZAM message, except PTYPE which is set 308 to one. 310 A router receiving ZLE messages SHOULD log them and attempt to alert 311 the network administrator that the scope zone is misconfigured. 313 Zone Convexity Message 315 Unlike Zone Announcement Messages which are sent to the locally 316 scoped address 239.255.255.254, Zone Convexity Messages are sent to 317 the second highest address in the scope zone itself. The format of a 318 ZCM is shown in figure 6 and is similar to a ZAM, expect PTYPE take 319 the value two. 321 0 1 2 3 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | V=0 | PTYPE | ZNUM | unused | IP | MLEN | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Zone Base Address | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Message Origin | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Zone ID Address | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | ZBR Address 0 | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 ..... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | ZBR Address N | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Zone Name | 339 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 6: Zone Convexity Message Format 345 The fields are as follows: 347 Number of ZBR addresses (ZNUM): 8 bits This field gives the number of 348 ZBR Addresses contained in this message. 350 ZBR Address (32 bits) These fields give the addresses of ALL the 351 other ZBR routers that the Message Origin ZBR has received ZCM 352 messages from during the time that it has taken the Message 353 Origin ZBR to send ten ZCM messages. 355 4 Using Zone Announcement Messages 357 Any host or application may listen to Zone Announcement Messages to 358 build up a list of the scope zones that are relevant locally. 359 However, listening to Zone Announcement Messages is not the 360 recommended method for regular applications to discover this 361 information. These applications will normally query a local Multicast 362 Address Allocation Server[2], which in turn will listen to Zone 363 Announcement Messages. 365 A ZBR can discover misconfiguration of scope boundaries in one of 366 several ways: 368 o It receives ZLE messages indicating that the scope zone is 369 leaking. 371 o It receives ZAM messages originating inside the scope boundary 372 on an interface that points outside the zone boundary. Such a 373 ZAM message must have escaped the zone through a leak, and 374 flooded back around behind the boundary. This is illustrated in 375 figure 7. 377 o Other ZBR routers in the scope zone are announcing that they 378 are seeing a different set of routers than our router observes 379 from arriving ZCM messages. If this is a persistent condition, 380 it indicates that the scope zone is probably not convex, as 381 illustrated in figure 3. 383 in 385 Figure 7: ZAM Message Leaking 387 All these conditions should be considered errors and the router 388 should attempt to alert the network administrator to the nature of 389 the misconfiguration. 391 Zone Convexity Messages can also be sent and received by correctly 392 configured ordinary hosts within a scope region, which may be a 393 useful diagnostic facility that does not require privileged access. 395 5 Message Timing 397 Each ZBR router should send a Zone Announcement Message for each 398 scope zone for which it is a boundary every ZAM-INTERVAL seconds, 399 +/- 30% of ZAM-INTERVAL each time to avoid message synchronisation. 401 Each ZBR router should send a Zone Convexity Message for each scope 402 zone for which it is a boundary every ZCM-INTERVAL seconds, +/- 30% 403 of ZCM-INTERVAL each time to avoid message synchronisation. 405 A router SHOULD NOT send more than one Zone Limit Exceeded message 406 every ZLE-MIN-INTERVAL regardless of destination. 408 Default values are: 410 ZAM-INTERVAL 300 seconds. 412 ZCM-INTERVAL 300 seconds. 414 ZLE-MIN-INTERVAL 300 seconds. 416 6 Security Considerations 418 MZAP does not include authentication in its messages. Thus it is open 419 to misbehaving hosts sending spoof ZAM or ZCM messages. 421 In the case of ZCM messages, these spoof messages can cause false 422 logging of convexity problems. It is likely that is would be purely 423 an annoyance, and not cause any significant problem. 425 In the case of ZAM messages, spoof messages can also cause false 426 logging of configuration problems. This is also considered to not be 427 a significant problem. 429 Spoof zone announcements however might cause applications to believe 430 that a scope zone exists when it does not. If these were believed, 431 then applications may choose to use this non-existent admin scope 432 zone for their uses. Such applications would be able to communicate 433 successfully, but would be unaware that their traffic may be 434 traveling further than they expected. As a result, applications MUST 435 only take scope names as a guideline, and SHOULD assume that their 436 traffic sent to non-local scope zones might travel anywhere. The 437 confidentiality of such traffic CANNOT be assumed from the fact that 438 it was sent to a scoped address that was discovered using MZAP. 440 7 Bibliography 442 [1] D. Meyer, "Administratively Scoped IP Multicast", Internet 443 Draft, draft-ietf-mboned-admin-ip-space-04.txt [2] M. Handley, D. 444 Thaler, D. Estrin, "The Internet Multicast Address Allocation 445 Architecture", Internet Draft, Dec 1997.