idnits 2.17.1 draft-ietf-mboned-mzap-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 91 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'NAME-OF-CONSTANT' on line 205 -- Looks like a reference, but probably isn't: 'MZAP-LOCAL-GROUP' on line 1028 -- Looks like a reference, but probably isn't: 'ZCM-HOLDTIME' on line 1044 -- Looks like a reference, but probably isn't: 'MZAP-PORT' on line 1016 -- Looks like a reference, but probably isn't: 'ZAM-HOLDTIME' on line 1033 -- Looks like a reference, but probably isn't: 'ZCM-RELATIVE-GROUP' on line 1024 -- Looks like a reference, but probably isn't: 'NIM-HOLDTIME' on line 1060 -- Looks like a reference, but probably isn't: 'ZAM-INTERVAL' on line 1034 -- Looks like a reference, but probably isn't: 'ZAM-DUP-TIME' on line 1113 -- Looks like a reference, but probably isn't: 'ZLE-MIN-INTERVAL' on line 1052 -- Looks like a reference, but probably isn't: 'ZLE-SUPPRESSION-INTERVAL' on line 1048 -- Looks like a reference, but probably isn't: 'MZAP-RELATIVE-GROUP' on line 908 -- Looks like a reference, but probably isn't: 'ZCM-INTERVAL' on line 1045 -- Looks like a reference, but probably isn't: 'NIM-INTERVAL' on line 1061 -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2279 (ref. '4') (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1766 (ref. '6') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2402 (ref. '12') (Obsoleted by RFC 4302, RFC 4305) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBoneD Working Group Mark Handley 2 Internet Engineering Task Force ACIRI 3 INTERNET-DRAFT Dave Thaler 4 22 October 1999 Microsoft 5 Expires April 2000 Roger Kermode 6 Motorola 8 Multicast-Scope Zone Announcement Protocol (MZAP) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet Drafts are valid for a maximum of six months and may be 21 updated, replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet Drafts as reference material or to cite 23 them other than as a "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a protocol, the Multicast-Scope Zone Announcement 34 Protocol (MZAP), for discovering the multicast administrative scope 35 zones that are relevant at a particular location. MZAP also provides 36 mechanisms whereby common misconfigurations of administrative scope 37 zones can be discovered. 39 Copyright Notice 41 Copyright (C) The Internet Society (1999). All Rights Reserved. 43 Draft MZAP October 1999 45 1. Introduction 47 The use of administratively-scoped IP multicast, as defined in RFC 2365 48 [1], allows packets to be addressed to a specific range of multicast 49 addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the 50 packets will not cross configured administrative boundaries, and also 51 allows such addresses to be locally assigned and hence are not required 52 to be unique across administrative boundaries. This property of logical 53 naming both allows for address reuse, as well as provides the capability 54 for infrastructure services such as address allocation, session 55 advertisement, and service location to use well-known addresses which 56 are guaranteed to have local significance within every organization. 58 The range of administratively-scoped addresses can be subdivided by 59 administrators so that multiple levels of administrative boundaries can 60 be simultaneously supported. As a result, a "multicast scope" is 61 defined as a particular range of addresses which has been given some 62 topological meaning. 64 To support such usage, a router at an administrative boundary is 65 configured with one or more per-interface filters, or "multicast scope 66 boundaries". Having such a boundary on an interface means that it will 67 not forward packets matching a configured range of multicast addresses 68 in either direction on the interface. 70 A specific area of the network topology which is within a boundary for a 71 given scope is known as a "multicast scope zone". Since the same ranges 72 can be reused within disjoint areas of the network, there may be many 73 "multicast scope zones" for any given multicast scope. A scope zone may 74 have zero or more textual names (in different languages) for the scope, 75 for human convenience. For example, if the range 239.192/14 were 76 assigned to span an entire corporate network, it might be given 77 (internally) the name "BigCo Private Scope". 79 Administrative scope zones may be of any size, and a particular host may 80 be within many administrative scope zones (for different scopes, i.e., 81 for non-overlapping ranges of addresses) of various sizes, as long as 82 scope zones that intersect topologically do not intersect in address 83 range. 85 Applications and services are interested in various aspects of the 86 scopes within which they reside: 88 o Applications which present users with a choice of which scope in 89 which to operate (e.g., when creating a new session, whether it is 91 Draft MZAP October 1999 93 to be confined to a corporate intranet, or whether it should go out 94 over the public Internet) are interested in the textual names which 95 have significance to users. 97 o Services which use "relative" multicast addresses (as defined in 98 [1]) in every scope are interested in the range of addresses used 99 by each scope, so that they can apply a constant offset and compute 100 which address to use in each scope. 102 o Address allocators are interested in the address range, and whether 103 they are allowed to allocate addresses within the entire range or 104 not. 106 o Some applications and services may also be interested in the 107 nesting relationships among scopes. For example, knowledge of the 108 nesting relationships can be used to perform "expanding-scope" 109 searches in a similar, but better behaved, manner to the well-known 110 expanding ring search where the TTL of a query is steadily 111 increased until a replier can be found. Studies have also shown 112 that nested scopes can be useful in localizing multicast repair 113 traffic [8]. 115 Two barriers currently make administrative scoping difficult to deploy 116 and use: 118 o Applications have no way to dynamically discover information on 119 scopes that are relevant to them. This makes it difficult to use 120 administrative scope zones, and hence reduces the incentive to deploy 121 them. 123 o Misconfiguration is easy. It is difficult to detect scope zones that 124 have been configured so as to not be convex (the shortest path 125 between two nodes within the zone passes outside the zone), or to 126 leak (one or more boundary routers were not configured correctly), or 127 to intersect in both area and address range. 129 These two barriers are addressed by this document. In particular, this 130 document defines the Multicast Scope Zone Announcement Protocol (MZAP) 131 which allows an entity to learn what scope zones it is within. 132 Typically servers will cache the information learned from MZAP and can 133 then provide this information to applications in a timely fashion upon 134 request using other means, e.g., via MADCAP [9]. MZAP also provides 135 diagnostic information to the boundary routers themselves that enables 136 misconfigured scope zones to be detected. 138 Draft MZAP October 1999 140 2. Terminology 142 The "Local Scope" is defined in RFC 2365 [1] and represents the smallest 143 administrative scope larger than link-local, and the associated address 144 range is defined as 239.255.0.0 to 239.255.255.255 inclusive (for IPv4, 145 FF03::/16 for IPv6). RFC 2365 specifies: 146 "239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local 147 Scope is the minimal enclosing scope, and hence is not further 148 divisible. Although the exact extent of a Local Scope is site 149 dependent, locally scoped regions must obey certain topological 150 constraints. In particular, a Local Scope must not span any other 151 scope boundary. Further, a Local Scope must be completely contained 152 within or equal to any larger scope. In the event that scope regions 153 overlap in area, the area of overlap must be in its own Local Scope. 154 This implies that any scope boundary is also a boundary for the Local 155 Scope." 157 A multicast scope Zone Boundary Router (ZBR) is a router that is 158 configured with a boundary for a particular multicast scope on one or 159 more of its interfaces. Any interface that is configured with a 160 boundary for any administrative scope zone MUST also have a boundary for 161 the Local Scope zone, as described above. 163 Such routers SHOULD be configured so that the router itself is within 164 the scope zone. This is shown in Figure 1(a), where router A is inside 165 the scope zone and has the boundary configuration. 167 ............ ................ 168 . . +B+--> . *B+--> 169 . . / . / . 170 . * . + . 171 . <---+A*---+C+-> . <---+A+---*C+-> 172 . + . . + . 173 . / . . / . 174 . zone X <-- . . zone X <-- . 175 .............. .................. 177 A,B,C - routers * - boundary interface + - interface 179 (a) Correct zone boundary (b) Incorrect zone boundary 181 Figure 1: Administrative scope zone boundary placement 183 It is possible for the first router outside the scope zone to be 184 configured with the boundary, as illustrated in Figure 1(b) where 186 Draft MZAP October 1999 188 routers B and C are outside the zone and have the boundary 189 configuration, whereas A does not, but this is NOT RECOMMENDED. This 190 rule does not apply for Local Scope boundaries, but applies for all 191 other boundary routers. 193 We next define the term "Zone ID" to mean the lowest IP address used by 194 any ZBR for a particular zone for sourcing MZAP messages into that scope 195 zone. The combination of this IP address and the first multicast 196 address in the scope range serve to uniquely identify the scope zone. 197 Each ZBR listens for messages from other ZBRs for the same boundary, and 198 can determine the Zone ID based on the source addresses seen. The Zone 199 ID may change over time as ZBRs come up and down. 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [2]. 205 Constants used by this protocol are shown as [NAME-OF-CONSTANT], and 206 summarized in section 7. 208 3. Overview 210 When a ZBR is configured correctly, it can deduce which side of the 211 boundary is inside the scope zone and which side is outside it. 213 Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for 214 each zone for which it is configured as a boundary into that scope zone, 215 containing information on the scope zone's address range, Zone ID, and 216 textual names. These messages are multicast to the well-known address 217 [MZAP-LOCAL-GROUP] in the Local Scope, and are relayed across Local 218 Scope boundaries into all Local Scope zones within the scope zone 219 referred to by the ZAM message, as shown in Figure 2. 221 Draft MZAP October 1999 223 ########################### 224 # Zone1 = Zone2 # ##### = large scope zone boundary 225 *E-----+--->A*-----+-x # 226 # | = v # ===== = Local Scope boundaries 227 # | ======*===*==# 228 # | = B F # ----> = path of ZAM originated by E 229 G*<-----+--->C*-> | ^ # 230 # v = <-+---+ # ABCDE = ZBRs 231 # D = Zone3 # 232 #######*################### * = boundary interface 234 Figure 2: ZAM Flooding Example 236 Any entity can thus listen on a single well-known group address and 237 learn about all scopes in which it resides. 239 3.1. Scope Nesting 241 MZAP also provides the ability to discover the nesting relationships 242 between scope zones. Two zones are nested if one is comprised of a 243 subset of the routers in the other, as shown in Figure 3. 245 +-----------+ +-----------+ +-------------+ 246 | Zone 1 | | Zone 3 | | Zone 5 | 247 | +------+| | +------+ | .........|.. 248 | |Zone 2|| | |Zone 4| | : Zone 6 | : 249 | +--A---+| | C | | D | : 250 +-----------+ +----+--B---+ +--------E----+ : 251 :..........: 253 (a) "Contained" (b) "Common Border" (c) "Overlap" 254 Zone 2 nests Zone 4 nests Zones 5 and 6 255 inside Zone 1 inside Zone 3 do not nest 257 Figure 3: Zone nesting examples 259 A ZBR cannot independently determine whether one zone is nested inside 260 another. However, it can determine that one zone does NOT nest inside 261 another. For example, in Figure 3: 263 o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2 264 from leaving zone 2. When ZBR A first receives a ZAM for zone 1, it 266 Draft MZAP October 1999 268 then knows that zone 1 does not nest within zone 2, but it cannot, 269 however, determine whether zone 2 nests within zone 1. 271 o ZBR B acts as ZBR for both zones 3 and 4, and hence cannot determine 272 if one is nested inside the other. However, ZBR C can determine that 273 zone 3 does not nest inside zone 4 when it receives a ZAM for zone 3, 274 since it is a ZBR for zone 4 but not zone 3. 276 o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that 277 zone 5 does not nest inside zone 6 upon hearing a ZAM for zone 5. 278 Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence ZBR E can 279 deduce that zone 6 does not nest inside zone 5 upon hearing a ZAM for 280 zone 6. 282 The fact that ZBRs can determine that one zone does not nest inside 283 another, but not that a zone does nest inside another, means that 284 nesting must be determined in a distributed fashion. This is done by 285 sending Not-Inside Messages (NIMs) which express the fact that a zone X 286 is not inside a zone Y. Such messages are sent to the well-known [MZAP- 287 LOCAL-GROUP] and are thus seen by the same entities listening to ZAM 288 messages (e.g., MADCAP servers). Such entities can then determine the 289 nesting relationship between two scopes based on a sustained absence of 290 any evidence to the contrary. 292 3.2. Other Messages 294 Two other message types, Zone Convexity Messages (ZCMs) and Zone Limit 295 Exceeded (ZLE) messages, are used only by routers, and enable them to 296 compare their configurations for consistency and detect 297 misconfigurations. These messages are sent to MZAP's relative address 298 within the scope range associated with the scope zone to which they 299 refer, and hence are typically not seen by entities other than routers. 300 Their use in detecting specific misconfiguration scenarios will be 301 covered in the next section. 303 Packet formats for all messages are described in Section 5. 305 3.3. Zone IDs 307 When a boundary router first starts up, it uses its lowest IP address 308 which it considers to be inside a given zone, and which is routable 309 everywhere within the zone (for example, not a link-local address), as 310 the Zone ID for that zone. It then schedules ZCM (and ZAM) messages to 312 Draft MZAP October 1999 314 be sent in the future (it does not send them immediately). When a ZCM 315 is received for the given scope, the sender is added to the local list 316 of ZBRs (including itself) for that scope, and the Zone ID is updated to 317 be the lowest IP address in the list. Entries in the list are 318 eventually timed out if no further messages are received from that ZBR, 319 such that the Zone ID will converge to the lowest address of any active 320 ZBR for the scope. 322 Note that the sender of ZAM messages MUST NOT be used in this way. This 323 is because the procedure for detecting a leaky Local scope described in 324 Section 4.3 below relies on two disjoint zones for the same scope range 325 having different Zone IDs. If ZAMs are used to compute Zone IDs, then 326 ZAMs leaking across a Local Scope boundary will cause the two zones to 327 converge to the same Zone ID. 329 4. Detecting Router Misconfigurations 331 In this section, we cover how to detect various error conditions. If 332 any error is detected, the router should attempt to alert a network 333 administrator to the nature of the misconfiguration. The means to do 334 this lies outside the scope of MZAP. 336 4.1. Detecting non-convex scope zones 338 Zone Convexity Messages (ZCMs) are used by routers to detect non-convex 339 administrative scope zones, which are one possible misconfiguration. 340 Non-convex scope zones can cause problems for applications since a 341 receiver may never see administratively-scoped packets from a sender 342 within the same scope zone, since packets travelling between them may be 343 dropped at the boundary. 345 In the example illustrated in Figure 4, the path between B and D goes 346 outside the scope (through A and E). Here, Router B and Router C send 347 ZCMs within a given scope zone for which they each have a boundary, with 348 each reporting the other boundary routers of the zone from which they 349 have heard. In Figure 4, Router D cannot see Router B's messages, but 350 can see C's report of B, and so can conclude the zone is not convex. 352 Draft MZAP October 1999 354 #####*####======== 355 # B # = ##### = non-convex scope boundary 356 # |->A* = 357 # | # = ===== = other scope boundaries 358 # | ####*#### 359 # | E # ----> = path of B's ZCM 360 # v D* 361 # C # * = boundary interface 362 #####*############ 364 Figure 4: Non-convexity detection 366 Non-convex scope zones can be detected via three methods: 368 (1) If a ZBR is listed in ZCMs received, but the next-hop interface 369 (according to the multicast RIB) towards that ZBR is outside the 370 scope zone, 372 (2) If a ZBR is listed in ZCMs received, but no ZCM is received from 373 that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 4, 374 or 376 (3) ZAM messages can also be used in a manner similar to that for 377 ZCMs in (1) above, as follows: if a ZAM is received from a ZBR on 378 an interface inside a given scope zone, and the next-hop 379 interface (according to the multicast RIB) towards that ZBR is 380 outside the scope zone. 382 Zone Convexity Messages MAY also be sent and received by correctly 383 configured ordinary hosts within a scope region, which may be a useful 384 diagnostic facility that does not require privileged access. 386 4.2. Detecting leaky boundaries for non-local scopes 388 A "leaky" boundary is one which logically has a "hole" due to some 389 router not having a boundary applied on an interface where one ought to 390 exist. Hence, the boundary does not completely surround a piece of the 391 network, resulting in scoped data leaking outside. 393 Leaky scope boundaries can be detected via two methods: 395 (1) If it receives ZAMs originating inside the scope boundary on an 396 interface that points outside the zone boundary. Such a ZAM 397 message must have escaped the zone through a leak, and flooded 399 Draft MZAP October 1999 401 back around behind the boundary. This is illustrated in Figure 402 5. 403 =============#####*######## 404 = Zone1 # A Zone2 # C = misconfigured router 405 = +---->*E v # 406 = | # B # ##### = leaky scope boundary 407 =======*=====#====*=======# 408 = D # | # ===== = other scope boundaries 409 = ^-----*C<--+ # 410 = Zone4 # Zone3 # ----> = path of ZAMs 411 =============############## 413 Figure 5: ZAM Leaking 415 (2) If a Zone Length Exceeded (ZLE) message is received. The ZAM 416 packet also contains a Zones Traveled Limit. If the number of 417 Local Scope zones traversed becomes equal to the Zones Traveled 418 Limit, a ZLE message is generated (the suppression mechanism for 419 preventing implosion is described later in the Processing Rules 420 section). ZLEs detect leaks where packets do not return to 421 another part of the same scope zone, but instead reach other 422 Local Scope zones far away from the ZAM originator. 424 In either case, the misconfigured router will be either the message 425 origin, or one of the routers in the ZBR path list which is included in 426 the message received (or perhaps a router on the path between two such 427 ZBRs which ought to have been a ZBR itself). 429 4.3. Detecting a leaky Local Scope zone 431 A local scope is leaky if a router has an administrative scope boundary 432 on some interface, but does not have a Local Scope boundary on that 433 interface as specified in RFC 2365. This can be detected via the 434 following method: 436 o If a ZAM for a given scope is received by a ZBR which is a boundary 437 for that scope, it compares the Origin's Scope Zone ID in the ZAM 438 with its own Zone ID for the given scope. If the two do not match, 439 this is evidence of a misconfiguration. Since a temporary mismatch 440 may result immediately after a recent change in the reachability of 441 the lowest-addressed ZBR, misconfiguration should be assumed only if 442 the mismatch is persistent. 444 Draft MZAP October 1999 446 The exact location of the problem can be found by doing an mtrace [5] 447 from the router detecting the problem, back to the ZAM origin, for any 448 group within the address range identified by the ZAM. The router at 449 fault will be the one reporting that a boundary was reached. 451 4.4. Detecting conflicting scope zones 453 Conflicting address ranges can be detected via the following method: 455 o If a ZBR receives a ZAM for a given scope, and the included start and 456 end addresses overlap with, but are not identical to, the start and 457 end addresses of a locally-configured scope. 459 Conflicting scope names can be detected via the following method: 461 o If a ZBR is configured with a textual name for a given scope and 462 language, and it receives a ZAM or ZCM with a name for the same scope 463 and language, but the scope names do not match. 465 Detecting either type of conflict above indicates that either the local 466 router or the router originating the message is misconfigured. 467 Configuration tools SHOULD strip white space from the beginning and end 468 of each name to avoid accidental misconfiguration. 470 5. Packet Formats 472 All MZAP messages are sent over UDP, with a destination port of [MZAP- 473 PORT] and an IPv4 TTL or IPv6 Hop Limit of 255. 475 When sending an MZAP message referring to a given scope zone, a ZBR MUST 476 use a source address which will have significance everywhere within the 477 scope zone to which the message refers. For example, link-local 478 addresses MUST NOT be used. 480 The common MZAP message header (which follows the UDP header), is shown 481 below: 483 Draft MZAP October 1999 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Version |B| PTYPE |Address Family | NameCount | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Message Origin | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Zone ID Address | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Zone Start Address | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Zone End Address | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Encoded Zone Name-1 (variable length) | 499 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | . . . | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | . . . | Encoded Zone Name-N (variable length) | 503 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | | Padding (if needed) | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Version: 508 The version defined in this document is version 0. 510 "Big" scope bit (B): 511 If clear, indicates that the addresses in the scoped range are not 512 subdividable, and that address allocators may utilize the entire 513 range. If set, address allocators should not use the entire range, 514 but should learn an appropriate sub-range via another mechanism 515 (e.g., AAP [7]). 517 Packet Type (PTYPE): 518 The packet types defined in this document are: 519 0: Zone Announcement Message (ZAM) 520 1: Zone Limit Exceeded (ZLE) 521 2: Zone Convexity Message (ZCM) 522 3: Not-Inside Message (NIM) 524 Address Family: 525 The IANA-assigned address family number [10,11] identifying the 526 address family for all addresses in the packet. The families defined 527 for IP are: 528 1: IPv4 529 2: IPv6 531 Draft MZAP October 1999 533 Name Count: 534 The number of encoded zone name blocks in this packet. The count may 535 be zero. 537 Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) 538 This gives the start address for the scope zone boundary. For 539 example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then 540 Zone Start Address is 239.1.0.0. 542 Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) 543 This gives the ending address for the scope zone boundary. For 544 example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then 545 Zone End Address is 239.1.0.255. 547 Message Origin: 32 bits (IPv4) or 128 bits (IPv6) 548 This gives the IP address of the interface that originated the 549 message. 551 Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6) 552 This gives the lowest IP address of a boundary router that has been 553 observed in the zone originating the message. Together with Zone 554 Start Address and Zone End Address, it forms a unique ID for the 555 zone. Note that this ID is usually different from the ID of the 556 Local Scope zone in which the origin resides. 558 Encoded Zone Name: 559 +--------------------+ 560 |D| Reserved (7 bits)| 561 +--------------------+ 562 | LangLen (1 byte) | 563 +--------------------+-----------+ 564 | Language Tag (variable size) | 565 +--------------------+-----------+ 566 | NameLen (1 byte) | 567 +--------------------+-----------+ 568 | Zone Name (variable size) | 569 +--------------------------------+ 571 The first byte contains flags, of which only the high bit is defined. 572 The other bits are reserved (sent as 0, ignored on receipt). 573 "Default Language" (D) bit: 574 If set, indicates a preference that the name in the following 575 language should be used if no name is available in a desired 576 language. 578 Draft MZAP October 1999 580 Language tag length (LangLen): 1 byte 581 The length, in bytes, of the language tag. 583 Language Tag: (variable size) 584 The language tag, such as "en-US", indicating the language of the 585 zone name. Language tags are described in [6]. 587 Name Len: 588 The length, in bytes, of the Zone Name field. The length MUST NOT be 589 zero. 591 Zone Name: multiple of 8 bits 592 The Zone Name is an ISO 10646 character string in UTF-8 encoding [4] 593 indicating the name given to the scope zone (eg: ``ISI-West Site''). 594 It should be relatively short and MUST be less than 256 bytes in 595 length. White space SHOULD be stripped from the beginning and end of 596 each name before encoding, to avoid accidental conflicts. 598 Padding (if needed): 599 The end of the MZAP header is padded with null bytes until it is 600 4-byte aligned. 602 5.1. Zone Announcement Message 604 A Zone Announcement Message has PTYPE=0, and is periodically sent by a 605 ZBR for each scope for which it is a boundary, EXCEPT: 607 o the Local Scope 609 o the Link-local scope 611 The format of a Zone Announcement Message is shown below: 613 Draft MZAP October 1999 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 MZAP Header 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | ZT | ZTL | Hold Time | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Local Zone ID Address 0 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Router Address 1 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Local Zone ID Address 1 | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 ..... 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Router Address N | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Local Zone ID Address N | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 The fields are defined as follows: 636 Zones Traveled (ZT): 8 bits 637 This gives the number of Local Zone IDs contained in this message 638 path. 640 Zones Traveled Limit (ZTL): 8 bits 641 This gives the limit on number of local zones that the packet can 642 traverse before it MUST be dropped. A value of 0 indicates that no 643 limit exists. 645 Hold Time: 646 The time, in seconds, after which the receiver may assume the scope 647 no longer exists, if no subsequent ZAM is received. This should be 648 set to [ZAM-HOLDTIME]. 650 Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) 651 The zone path is a list of Local Zone ID Addresses (the Zone ID 652 Address of a local zone) through which the ZAM has passed, and IP 653 addresses of the router that forwarded the packet. The origin router 654 fills in the "Local Zone ID Address 0" field when sending the ZAM. 655 Every Local Scope router that forwards the ZAM across a Local Scope 656 boundary MUST add the Local Zone ID Address of the local zone that 657 the packet of the zone into which the message is being forwarded, and 658 its own IP address to the end of this list, and increment ZT 659 accordingly. The zone path is empty which the ZAM is first sent. 661 Draft MZAP October 1999 663 5.2. Zone Limit Exceeded (ZLE) 665 The format of a ZLE is shown below: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 MZAP Header 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | ZT | ZTL | Hold Time | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Local Zone ID Address 0 | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Router Address 1 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Local Zone ID Address 1 | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 ..... 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Router Address N | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Local Zone ID Address N | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 All fields are copied from the ZAM, except PTYPE which is set to one. 688 5.3. Zone Convexity Message 690 A Zone Announcement Message has PTYPE=2, and is periodically sent by a 691 ZBR for each scope for which it is a boundary (except the Link-local 692 scope). Note that ZCM's ARE sent in the Local Scope. 694 Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL- 695 GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP] in 696 the scope zone itself. The format of a ZCM is shown below: 698 Draft MZAP October 1999 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 MZAP Header 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | ZNUM | unused | Hold Time | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | ZBR Address 1 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 ..... 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | ZBR Address N | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 The fields are as follows: 715 Number of ZBR addresses (ZNUM): 8 bits 716 This field gives the number of ZBR Addresses contained in this 717 message. 719 Hold Time: 720 The time, in seconds, after which the receiver may assume the sender 721 is no longer reachable, if no subsequent ZCM is received. This 722 should be set to [ZCM-HOLDTIME]. 724 ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) 725 These fields give the addresses of the other ZBRs from which the 726 Message Origin ZBR has received ZCMs but whose hold time has not 727 expired. The router should include all such addresses which fit in 728 the packet, preferring those which it has not included recently if 729 all do not fit. 731 5.4. Not-Inside Message 733 A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a 734 ZBR which knows that a scope X does not nest within another scope Y ("X 735 not inside Y"): 737 The format of a Not-Inside Message is shown below: 739 Draft MZAP October 1999 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 MZAP Header 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Not-Inside Zone Start Address | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 The fields are as follows: 750 MZAP Header: 751 Header fields identifying the scope X. The Name Count may be 0. 753 Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) 754 This gives the start address for the scope Y. 756 6. Message Processing Rules 758 6.1. Internal entities listening to MZAP messages 760 Any host or application may join the [MZAP-LOCAL-GROUP] to listen for 761 Zone Announcement Messages to build up a list of the scope zones that 762 are relevant locally, and for Not-Inside Messages if it wishes to learn 763 nesting information. However, listening to such messages is not the 764 recommended method for regular applications to discover this 765 information. These applications will normally query a local Multicast 766 Address Allocation Server (MAAS) [3], which in turn listens to Zone 767 Announcement Messages and Not-Inside Messages to maintain scope 768 information, and can be queried by clients via MADCAP messages. 770 An entity (including a MAAS) lacking any such information can only 771 assume that it is within the Global Scope, and the Local Scope, both of 772 which have well-known address ranges defined in [1]. 774 An internal entity (e.g., an MAAS) receiving a ZAM will parse the 775 information that is relevant to it, such as the address range, and the 776 names. An address allocator receiving such information MUST also use 777 the "B" bit to determine whether it can add the address range to the set 778 of ranges from which it may allocate addresses (specifically, it may add 779 them only if the bit is zero). Even if the bit is zero, an MAAS SHOULD 780 still store the range information so that clients who use relative- 781 addresses can still obtain the ranges by requesting them from the MAAS. 783 An internal entity (e.g., an MAAS) may assume that X nests within Y if: 785 Draft MZAP October 1999 787 a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME] 788 seconds ago, AND 790 b) it has not heard a NIM indicating that "X not inside Y" for at 791 least [NIM-HOLDTIME] seconds. 793 6.2. Sending ZAMs 795 Each ZBR should send a Zone Announcement Message for each scope zone for 796 which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM- 797 INTERVAL] each time to avoid message synchronisation. 799 The ZAM packet also contains a Zones Traveled Limit (ZTL). If the 800 number of Local Zone IDs in the ZAM path becomes equal to the Zones 801 Traveled Limit, the packet will be dropped. The ZTL field is set when 802 the packet is first sent, and defaults to 32, but can be set to a lower 803 value if a network administrator knows the expected size of the zone. 805 6.3. Receiving ZAMs 807 When a ZBR receives a ZAM for some scope zone X, it uses the following 808 rules. 810 If the local ZBR does NOT have any configuration for scope X: 812 (1) Check to see if the included start and end addresses overlap with, 813 but are not identical to, the start and end addresses of any 814 locally-configured scope Y, and if so, signal an address range 815 conflict to a local administrator. 817 (2) Create a local "X not inside" state entry, if such an entry does 818 not already exist. The ZBR then restarts the entry's timer at 819 [ZAM-HOLDTIME]. Existence of this state indicates that the ZBR 820 knows that X does not nest inside any scope for which it is a 821 boundary. If the entry's timer expires (because no more ZAMs for X 822 are heard for [ZAM-HOLDTIME]), the entry is deleted. 824 If the local ZBR does have configuration for scope X: 826 (1) If the ZAM originated from OUTSIDE the scope (i.e., received over a 827 boundary interface for scope X): 829 Draft MZAP October 1999 831 a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope Zone 832 ID, then signal a leaky scope misconfiguration. 834 b) Drop the ZAM (perform no further processing below). For 835 example, router G in Figure 2 will not forward the ZAM. This 836 rule is primarily a safety measure, since the placement of G in 837 Figure 2 is not a recommended configuration, as discussed 838 earlier. 840 (2) If the ZAM originated from INSIDE the scope: 842 a) If the next-hop interface (according to the multicast RIB) 843 towards the Origin is outside the scope zone, then signal a non- 844 convexity problem. 846 b) If the Origin's Scope Zone ID in the ZAM does not match the 847 Scope Zone ID kept by the local ZBR, and this mismatch continues 848 to occur, then signal a possible leaky scope warning. 850 c) For each textual name in the ZAM, see if a name for the same 851 scope and language is locally-configured; if so, but the scope 852 names do not match, signal a scope name conflict to a local 853 administrator. 855 d) If the ZAM was received on an interface which is NOT a Local 856 Scope boundary, and the last Local Zone ID Address in the path 857 list is 0, the ZBR fills in the Local Zone ID Address of the 858 local zone from which the ZAM was received. 860 If a ZAM for the same scope (as identified by the origin Zone ID and 861 first multicast address) was received in the last [ZAM-DUP-TIME] 862 seconds, the ZAM is then discarded. Otherwise, the ZAM is cached for at 863 least [ZAM-DUP-TIME] seconds. For example, when router C in Figure 2 864 receives the ZAM via B, it will not be forwarded, since it has just 865 forwarded the ZAM from E. 867 The Zones Travelled count in the message is then incremented, and if the 868 updated count is equal to or greater than the ZTL field, schedule a ZLE 869 to be sent as described in the next subsection and perform no further 870 processing below. 872 If the Zone ID of the Local Scope zone in which the ZBR resides is not 873 already in the ZAM's path list, then the ZAM is immediately re- 874 originated within the Local Scope zone. It adds its own address and the 875 Zone ID of the Local Scope zone into which the message is being 877 Draft MZAP October 1999 879 forwarded to the ZAM path list before doing so. A ZBR receiving a ZAM 880 with a non-null path list MUST NOT forward that ZAM back into a Local 881 Scope zone that is contained in the path list. For example, in Figure 882 2, router F, which did not get the ZAM via A due to packet loss, will 883 not forward the ZAM from B back into Zone 2 since the path list has { 884 (E,1), (A,2), (B,3) } and hence Zone 2 already appears. 886 In addition, the ZBR re-originates the ZAM out each interface with a 887 Local Scope boundary (except that it is not sent back out the interface 888 over which it was received, nor is it sent into any local scope zone 889 whose ID is known and appears in the path list). In each such ZAM re- 890 originated, the ZBR adds its own IP address to the path list, as well as 891 the Zone ID Address of the Local Scope Zone into which the ZAM is being 892 sent, or 0 if the ID is unknown. (For example, if the other end of a 893 point-to-point link also has a boundary on the interface, then the link 894 has no Local Scope Zone ID.) 896 6.4. Sending ZLEs 898 This packet is sent by a local-zone boundary router that would have 899 exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. To 900 avoid ZLE implosion, ZLEs are multicast with a random delay and 901 suppressed by other ZLEs. It is only scheduled if at least [ZLE-MIN- 902 INTERVAL] seconds have elapsed since it previously sent a ZLE to any 903 destination. To schedule a ZLE, the router sets a random delay timer 904 within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the 905 [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any 906 are received before the random delay timer expires, the timer is cleared 907 and the ZLE is not sent. If the timer expires, the router sends a ZLE 908 to the [MZAP-RELATIVE-GROUP] within the indicated scope. 910 The method used to choose a random delay (T) is as follows: 911 Choose a random value X from the uniform random interval [0:1] 912 Let C = 256 913 Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) 914 This equation results in an exponential random distribution which 915 ensures that close to one ZBR will respond. Using a purely uniform 916 distribution would begin to exhibit scaling problems as the number of 917 ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE arrives 918 before the time chosen, two routers choosing delays which differ by an 919 amount less than the propagation delay between them will both send 920 messages, consuming excess bandwidth. Hence it is desirable to minimize 921 the number of routers choosing a delay close to the lowest delay chosen, 922 and an exponential distribution is suitable for this purpose. 924 Draft MZAP October 1999 926 A router SHOULD NOT send more than one Zone Limit Exceeded message every 927 [ZLE-MIN-INTERVAL] regardless of destination. 929 6.5. Receiving ZLEs 931 When a router receives a ZLE, it performs the following actions: 933 (1) If the router has a duplicate ZLE message scheduled to be sent, 934 it unschedules its own message so another one will not be sent. 936 (2) If the ZLE contains the router's own address in the Origin field, 937 it signals a leaky scope misconfiguration. 939 6.6. Sending ZCMs 941 Each ZBR should send a Zone Convexity Message (ZCM) for each scope zone 942 for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of 943 [ZCM-INTERVAL] each time to avoid message synchronisation. 945 ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. 946 (For example, if the scope range is 239.1.0.0 to 239.1.0.255, then these 947 messages should be sent to 239.1.0.252.) As these are not Locally- 948 Scoped packets, they are simply multicast across the scope zone itself, 949 and require no path to be built up, nor any special processing by 950 intermediate Local Scope ZBRs. 952 6.7. Receiving ZCMs 954 When a ZCM is received for a given scope X, on an interface which is 955 inside the scope, it follows the rules below: 957 (1) The Origin is added to the local list of ZBRs (including itself) 958 for that scope, and the Zone ID is updated to be the lowest IP 959 address in the list. The new entry is scheduled to be timed out 960 after [ZCM-HOLDTIME] if no further messages are received from 961 that ZBR, so that the Zone ID will converge to the lowest address 962 of any active ZBR for the scope. 964 (2) If a ZBR is listed in ZCMs received, but the next-hop interface 965 (according to the multicast RIB) towards that ZBR is outside the 966 scope zone, or if no ZCM is received from that ZBR for [ZCM- 967 HOLDTIME] seconds, as in the example in Figure 4, then signal a 969 Draft MZAP October 1999 971 non-convexity problem. 973 (3) For each textual name in the ZCM, see if a name for the same 974 scope and language is locally-configured; if so, but the scope 975 names do not match, signal a scope name conflict to a local 976 administrator. 978 6.8. Sending NIMs 980 Periodically, for each scope zone Y for which it is a boundary, a router 981 originates a Not-Inside Message (NIM) for each "X not inside" entry it 982 has created when receiving ZAMs. Like a ZAM, this message is multicast 983 to the address [MZAP-LOCAL-GROUP] from one of its interfaces inside Y. 985 Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL] 986 seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization. 988 6.9. Receiving NIMs 990 When a ZBR receives a NIM saying that "X is not inside Y", it is 991 forwarded, unmodified, in a manner similar to ZAMs: 993 (1) If the NIM was received on an interface with a boundary for 994 either X or Y, the NIM is discarded. 996 (2) Unlike ZAMs, if the NIM was not received on the interface towards 997 the message origin (according to the Multicast RIB), the NIM is 998 discarded. 1000 (3) If a NIM for the same X and Y (where each is identified by its 1001 first multicast address) was received in the last [ZAM-DUP-TIME] 1002 seconds, the NIM is not forwarded. 1004 (4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds. 1006 (5) The ZBR then re-originates the NIM (i.e., with the original UDP 1007 payload) into each local scope zone in which it has interfaces, 1008 except that it is not sent back into the local scope zone from 1009 which the message was received, nor is it sent out any interface 1010 with a boundary for either X or Y. 1012 Draft MZAP October 1999 1014 7. Constants 1016 [MZAP-PORT]: The well-known UDP port to which all MZAP messages are 1017 sent. Value: 2106. 1019 [MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which 1020 ZAMs are sent. All Multicast Address Allocation servers and Zone 1021 Boundary Routers listen to this group. Value: 239.255.255.252 for IPv4; 1022 FF03:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFC for IPv6. 1024 [ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which 1025 ZCMs are sent. A Zone Boundary Router listens to the relative group in 1026 each scope for which it is a boundary. Value: (last IP address in scope 1027 range) - 3. For example, in the Local Scope, the relative group is the 1028 same as the [MZAP-LOCAL-GROUP] address. 1030 [ZAM-INTERVAL]: The interval at which a Zone Boundary Router originates 1031 Zone Announcement Messages. Default value: 600 seconds (10 minutes). 1033 [ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set 1034 to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31 1035 minutes). 1037 [ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which 1038 ZAMs for the same scope will not be forwarded. Default value: 30 1039 seconds. 1041 [ZCM-INTERVAL]: The interval at which a Zone Boundary Router originates 1042 Zone Convexity Messages. Default value: 600 seconds (10 minutes). 1044 [ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set 1045 to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31 1046 minutes). 1048 [ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random 1049 delay before sending a ZLE message. Default value: 300 seconds (5 1050 minutes). 1052 [ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, 1053 regardless of destination. Default value: 300 seconds (5 minutes). 1055 [NIM-INTERVAL]: The interval at which a Zone Boundary Router originates 1056 Not-Inside Messages. Default value: 1800 seconds (30 minutes). 1058 Draft MZAP October 1999 1060 [NIM-HOLDTIME]: The holdtime to include the state within a NIM. This 1061 SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value: 5460 (91 1062 minutes) 1064 8. Security Considerations 1066 While unauthorized reading of MZAP messages is relatively innocuous (so 1067 encryption is generally not an issue), accepting unauthenticated MZAP 1068 messages can be problematic. Authentication of MZAP messages can be 1069 provided by using the IPsec Authentication Header (AH) [12]. 1071 In the case of ZCMs and ZLEs, an attacker can cause false logging of 1072 convexity and leakage problems. It is likely that is would be purely an 1073 annoyance, and not cause any significant problem. (Such messages could 1074 be authenticated, but since they may be sent within large scopes, the 1075 receiver may not be able to authenticate a non-malicious sender.) 1077 ZAMs and NIMs, on the other hand, are sent within the Local Scope, where 1078 assuming a security relationship between senders and receivers is more 1079 practical. 1081 In the case of NIMs, accepting unauthenticated messages can cause the 1082 false cancellation of nesting relationships. This would cause a section 1083 of the hierarchy of zones to flatten. Such a flattening would lessen 1084 the efficiency benefits afforded by the hierarchy but would not cause it 1085 to become unusable. 1087 Accepting unauthenticated ZAM messages, however, could cause 1088 applications to believe that a scope zone exists when it does not. If 1089 these were believed, then applications may choose to use this non- 1090 existent administrative scope for their uses. Such applications would 1091 be able to communicate successfully, but would be unaware that their 1092 traffic may be traveling further than they expected. As a result, any 1093 application accepting unauthenticated ZAMs MUST only take scope names as 1094 a guideline, and SHOULD assume that their traffic sent to non-local 1095 scope zones might travel anywhere. The confidentiality of such traffic 1096 CANNOT be assumed from the fact that it was sent to a scoped address 1097 that was discovered using MZAP. 1099 In addition, ZAMs are used to inform Multicast Address Allocation 1100 Servers (MAASs) of names and address ranges of scopes, and accepting 1101 unauthenticated ZAMs could result in false names being presented to 1102 users, and in wrong addresses being allocated to users. To counter 1103 this, MAAS's authenticate ZAMs as follows: 1105 Draft MZAP October 1999 1107 (1) A ZBR signs all ZAMs it originates (using an AH). 1109 (2) A ZBR signs a ZAM it relays if and only if it can authenticate 1110 the previous sender. A ZBR MUST still forward un-authenticated 1111 ZAMs (to provide leak detection), but should propagate an 1112 authenticated ZAM even if an un-authenticated one was received 1113 with the last [ZAM-DUP-TIME] seconds. 1115 (3) A MAAS SHOULD be configured with the public key of the local zone 1116 in which it resides. A MAAS thus configured SHOULD ignore an 1117 unauthenticated ZAM if an authenticated one for the same scope 1118 has been received, and MAY ignore all unauthenticated ZAMs. 1120 9. Acknowledgements 1122 This document is a product of the MBone Deployment Working Group, whose 1123 members provided many helpful comments and suggestions, Van Jacobson 1124 provided some of the original ideas that led to this protocol. The 1125 Multicast Address Allocation Working Group also provided useful feedback 1126 regarding scope names and interactions with applications. 1128 10. References 1130 [1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 1131 2365, July 1998. 1133 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1134 Levels", BCP 14, RFC 2119, March 1997. 1136 [3] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast 1137 Address Allocation Architecture", Work in Progress, October 1999. 1139 [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1140 2279, January 1998. 1142 [5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP 1143 Multicast", Work in Progress, November 1997. 1145 [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1146 1766, March 1995. 1148 [7] Handley, M., and S. Hanna. "Multicast Address Allocation Protocol 1149 (AAP)", Work in Progress, October 1999. 1151 Draft MZAP October 1999 1153 [8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward 1154 Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998, 1155 Vancouver, Canada. 1157 [9] Patel, B., Shah, M., and S. Hanna. "Multicast Address Dynamic 1158 Client Allocation Protocol (MADCAP)", Work in progress, May 1999. 1160 [10] J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994. 1162 [11] IANA, "Address Family Numbers", http://www.isi.edu/in- 1163 notes/iana/assignments/address-family-numbers 1165 [12] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, 1166 November 1998. 1168 11. Authors' Addresses 1170 Mark Handley 1171 AT&T Center for Internet Research at ICSI 1172 1947 Center St, Suite 600 1173 Berkely, CA 94704 1174 USA 1175 Email: mjh@aciri.org 1177 David Thaler 1178 Microsoft 1179 One Microsoft Way 1180 Redmond, WA 98052 1181 USA 1182 Email: dthaler@microsoft.com 1184 Roger Kermode 1185 Motorola Australian Research Centre 1186 12 Lord St, 1187 Botany, NSW 2019 1188 Australia 1189 Email: Roger_Kermode@email.mot.com 1191 12. Full Copyright Statement 1193 Copyright (C) The Internet Society (1999). All Rights Reserved. 1195 Draft MZAP October 1999 1197 This document and translations of it may be copied and furnished to 1198 others, and derivative works that comment on or otherwise explain it or 1199 assist in its implementation may be prepared, copied, published and 1200 distributed, in whole or in part, without restriction of any kind, 1201 provided that the above copyright notice and this paragraph are included 1202 on all such copies and derivative works. However, this document itself 1203 may not be modified in any way, such as by removing the copyright notice 1204 or references to the Internet Society or other Internet organizations, 1205 except as needed for the purpose of developing Internet standards in 1206 which case the procedures for copyrights defined in the Internet 1207 languages other than English. 1209 The limited permissions granted above are perpetual and will not be 1210 revoked by the Internet Society or its successors or assigns. 1212 This document and the information contained herein is provided on an "AS 1213 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1214 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1215 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1216 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1217 FITNESS FOR A PARTICULAR PURPOSE. 1219 Table of Contents 1221 1 Introduction .................................................... 2 1222 2 Terminology ..................................................... 4 1223 3 Overview ........................................................ 5 1224 3.1 Scope Nesting ................................................. 6 1225 3.2 Other Messages ................................................ 7 1226 3.3 Zone IDs ...................................................... 7 1227 4 Detecting Router Misconfigurations .............................. 8 1228 4.1 Detecting non-convex scope zones .............................. 8 1229 4.2 Detecting leaky boundaries for non-local scopes ............... 9 1230 4.3 Detecting a leaky Local Scope zone ............................ 10 1231 4.4 Detecting conflicting scope zones ............................. 11 1232 5 Packet Formats .................................................. 11 1233 5.1 Zone Announcement Message ..................................... 14 1234 5.2 Zone Limit Exceeded (ZLE) ..................................... 16 1235 5.3 Zone Convexity Message ........................................ 16 1236 5.4 Not-Inside Message ............................................ 17 1237 6 Message Processing Rules ........................................ 18 1238 6.1 Internal entities listening to MZAP messages .................. 18 1239 6.2 Sending ZAMs .................................................. 19 1241 Draft MZAP October 1999 1243 6.3 Receiving ZAMs ................................................ 19 1244 6.4 Sending ZLEs .................................................. 21 1245 6.5 Receiving ZLEs ................................................ 22 1246 6.6 Sending ZCMs .................................................. 22 1247 6.7 Receiving ZCMs ................................................ 22 1248 6.8 Sending NIMs .................................................. 23 1249 6.9 Receiving NIMs ................................................ 23 1250 7 Constants ....................................................... 24 1251 8 Security Considerations ......................................... 25 1252 9 Acknowledgements ................................................ 26 1253 10 References ..................................................... 26 1254 11 Authors' Addresses ............................................. 27 1255 12 Full Copyright Statement ....................................... 27