idnits 2.17.1 draft-ietf-mboned-mzap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 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 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.) -- The document date (February 1999) is 9195 days in the past. Is this intentional? -- 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 92 -- Looks like a reference, but probably isn't: 'MZAP-LOCAL-GROUP' on line 607 -- Looks like a reference, but probably isn't: 'ZAM-DUP-TIME' on line 679 -- Looks like a reference, but probably isn't: 'ZCM-RELATIVE-GROUP' on line 611 -- Looks like a reference, but probably isn't: 'ZCM-HOLDTIME' on line 631 -- Looks like a reference, but probably isn't: 'MZAP-PORT' on line 604 -- Looks like a reference, but probably isn't: 'ZAM-HOLDTIME' on line 618 -- Looks like a reference, but probably isn't: 'ZLE-MIN-INTERVAL' on line 639 -- Looks like a reference, but probably isn't: 'ZLE-SUPPRESSION-INTERVAL' on line 635 -- Looks like a reference, but probably isn't: 'MZAP-RELATIVE-GROUP' on line 506 -- Looks like a reference, but probably isn't: 'ZAM-INTERVAL' on line 619 -- Looks like a reference, but probably isn't: 'ZCM-INTERVAL' on line 632 -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2279 (ref. '4') (Obsoleted by RFC 3629) == Outdated reference: A later version (-07) exists of draft-ietf-idmr-traceroute-ipm-02 -- Possible downref: Normative reference to a draft: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBoneD Working Group Mark Handley 3 Internet Engineering Task Force ISI 4 INTERNET-DRAFT Dave Thaler 5 3 August 1998 Microsoft 6 Expires February 1999 8 Multicast-Scope Zone Announcement Protocol (MZAP) 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute working 16 documents as Internet Drafts. 18 Internet Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet Drafts as reference material or to cite 21 them other than as a "work in progress". 23 Abstract 25 This document defines a protocol, the Multicast-Scope Zone Announcement 26 Protocol (MZAP), for discovering the multicast administrative scope 27 zones that are relevant at a particular location. MZAP also provides 28 mechanisms whereby two common misconfigurations of administrative scope 29 zones can be discovered. 31 Copyright Notice 33 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 Draft MZAP August 1998 37 1. Introduction 39 IP Multicast groups can be of global scope, or they can be restricted in 40 scope using a scoping mechanism. In this document, we only consider 41 administrative scoping, as defined in RFC 2365 [1]. An administrative 42 scope zone is defined by a set of routers surrounding a region of the 43 network. These "border routers" are configured to not pass multicast 44 traffic destined for a particular range of multicast addresses to or 45 from links leaving the scope zone. 47 Administrative scope zones may be of any size, and a particular host may 48 be within many administrative scope zones of various sizes. The only 49 zones a host can assume that it is within are the global zone, and a 50 "Local Scope". A Local Scope is defined as being the smallest 51 administrative scope zone encompassing a host, and the border is 52 configured for addresses in the range 239.255.0.0 to 239.255.255.255 53 inclusive. RFC 2365 specifies: 54 "239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local 55 Scope is the minimal enclosing scope, and hence is not further 56 divisible. Although the exact extent of a Local Scope is site 57 dependent, locally scoped regions must obey certain topological 58 constraints. In particular, a Local Scope must not span any other 59 scope boundary. Further, a Local Scope must be completely contained 60 within or equal to any larger scope. In the event that scope regions 61 overlap in area, the area of overlap must be in its own Local Scope. 62 This implies that any scope boundary is also a boundary for the Local 63 Scope." 64 as well as: 65 "administrative scopes that intersect topologically should not 66 intersect in address range." 68 Two problems make administrative scoping difficult to deploy and 69 difficult to use: 71 o Misconfiguration is easy. It is difficult to detect scope zones that 72 have been configured so as to not be convex (the shortest path 73 between two nodes within the zone passes outside the zone), or to 74 leak (one or more border routers were not configured correctly), or 75 to intersect in both area and address range. 77 o Applications have no way to discover the scope zones that are 78 relevant to them. This makes it difficult to use admin scope zones, 79 and hence reduces the incentive to deploy them. 81 This document defines the Multicast Scope Zone Announcement Protocol 82 Draft MZAP August 1998 84 (MZAP) which will provide applications with information about the scope 85 zones they are within, and also provide diagnostic information to detect 86 misconfigured scope zones. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [2]. 92 Constants used by this protocol are shown as [NAME-OF-CONSTANT], and 93 summarized in section 5. 95 2. Overview 97 A multicast scope Zone Border Router (ZBR) is a router that is 98 configured to be a zone border on one or more of its interfaces. Any 99 interface that is configured to be a border for any admin scope zone 100 MUST also be a border for the Local Scope zone, as defined in [1]. 102 Routers SHOULD be configured so that the router itself is within the 103 scope zone. This is should in figure 1(a), where router A is inside the 104 scope zone and has the border configuration. It is possible for the 105 first router outside the scope zone to be configured with the border, as 106 illustrated in figure 1(b) where routers B and C are outside the zone 107 and have the border configuration, but this is NOT RECOMMENDED. 109 ............ ................ 110 . . +B+--> . *B+--> 111 . . / . /. 112 . * . + . 113 . <---+A*---+C+-> . <---+A+---*C+-> 114 . + . . + . 115 . / . . / . 116 . zone X <-- . . zone X <-- . 117 .............. .................. 119 A,B,C - routers * - border interface + - interface 121 (a) Correct zone border (b) Incorrect zone border 123 Figure 1: Admin scope zone border placement 125 This rule does not apply for Local Scope borders, but applies for all 126 other admin scope border routers. 128 Draft MZAP August 1998 130 When a ZBR is configured correctly, it can deduce which side of the 131 boundary is inside the scope zone and which side is outside it. It can 132 also send messages into the scope zone, which it SHOULD NOT be able to 133 do if the router itself is considered outside the scope zone. 135 Such a ZBR should then send periodic Zone Announcement Messages (ZAMs) 136 for the zone for which it is configured as a border from one of its 137 interfaces that go into that scope zone. These messages are multicast 138 to the address [MZAP-LOCAL-GROUP] in the Local Scope. 140 Each ZBR also listens for messages from other ZBRs for the same border. 141 The ZBR with the lowest interface IP address within the zone from those 142 ZBRs forming the zone border becomes the zone-id router for the zone. 143 The combination of this IP address and the first multicast address in 144 the scoped range serve to uniquely identify the scope zone. 146 When a ZBR receives a ZAM for some scope zone: 148 o If the ZAM was received on an interface with a boundary for the given 149 scope, the ZAM is not forwarded. For example, router D in figure 2 150 will not forward the ZAM. 152 o If the ZAM was received on an interface which is NOT a Local Scope 153 boundary, and the last Local Zone ID Address in the path list is 0, 154 the ZBR fills in the Local Zone ID Address of the local zone from 155 which the ZAM was received. 157 o If a ZAM for the same scope (as identified by the origin Zone ID and 158 first multicast address) was received in the last [ZAM-DUP-TIME] 159 seconds, the ZAM is not forwarded. For example, when router C in 160 figure 2 receives the ZAM via B, it will not be forwarded, since it 161 has just forwarded the ZAM from E. 163 o Otherwise, the ZAM is cached for at least [ZAM-DUP-TIME] seconds. 165 o If the Zone ID of the Local Scope zone in which the ZBR resides is 166 not already in the ZAM's path list, then the ZAM is immediately re- 167 originated within the Local Scope zone. It adds its own address and 168 the zone-id of the Local Scope zone into which the message is being 169 forwarded to the ZAM path list before doing so. A ZBR receiving a ZAM 170 with a non-null path list MUST NOT forward that ZAM back into a Local 171 Scope zone that is contained in the path list. For example, in 172 figure 2, router F, which did not get the ZAM via A due to packet 173 loss, will not forward the ZAM from B back into Zone 2 since the path 174 list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears. 176 Draft MZAP August 1998 178 o In addition, the ZBR re-originates the ZAM out each interface with a 179 Local Scope boundary (except that it is not sent back out the 180 interface over which it was received), with its own IP address added 181 to the path list, as well as the Zone ID Address of the Local Scope 182 Zone into which the ZAM is being sent, or 0 if the ID is unknown. 183 (For example, if the other end of a point-to-point link also has a 184 boundary on the interface, then the link has no Local Scope Zone ID.) 186 ########################### 187 # Zone1 = Zone2 # ##### = large scope zone border 188 *E-----+--->A*-----+-x # 189 # | = v # ===== = Local Scope boundaries 190 # | ======*===*==# 191 # | = B F # ----> = path of ZAM origined by E 192 # +--->C*-> | ^ # 193 # v = <-+---+ # ABCDE = ZBRs 194 # D = Zone3 # 195 #######*################### * = border interface 197 Figure 2: ZAM Flooding Example 199 The packet also contains a Zones Traveled Limit. If the number of Local 200 Zone IDs in the ZAM path becomes equal to the Zones Traveled Limit, the 201 packet should be dropped. Zones Traveled Limit is set when the packet is 202 first sent, and defaults to 32, but can be set to a lower value if a 203 network administrator knows the expected size of the zone. 205 Additional messages called Zone Convexity Messages (ZCMs) SHOULD also be 206 sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. As these 207 are not locally scoped packets, they are simply multicast across the 208 scope zone itself, and require no path to be built up, nor any special 209 processing by Local Scope zone ZBRs. These messages are used to detect 210 non-convex admin scope zones, as illustrated in figure 3, where the path 211 between B and D goes outside the scope (through A and E). Here Router B 212 and Router C originates ZCMs, each reporting each other's presence. 213 Router D cannot see Router B's messages, but can see C's report of B, 214 and so can conclude the zone is not convex. 216 Draft MZAP August 1998 218 #####*####======== 219 # B # = ##### = non-convex scope boundary 220 # |->A* = 221 # | # = ===== = other scope boundaries 222 # | ####*#### 223 # | E # ----> = path of B's ZAM 224 # v D* 225 # C # * = border interface 226 #####*############ 228 Figure 3: Non-convexity detection 230 3. Usage 232 In this section, we summarize how to inform internal entities of scopes 233 in which they reside, as well as how to detect various error conditions. 234 If any error is detected, the router should attempt to alert a network 235 administrator to the nature of the misconfiguration. The means to do 236 this lies outside the scope of MZAP. 238 3.1. Zone IDs 240 When a border router first starts up, it uses its lowest IP address 241 which it considers to be inside a given zone as the Zone ID for that 242 zone, and schedules the ZCM and ZAM messages to be sent in the future 243 (it does not send them immedately). When a ZAM or ZCM is received for 244 the given scope, the sender is added to the local list of ZBRs 245 (including itself) for that scope, and the Zone ID is updated to be the 246 lowest IP address in the list. Entries in the list are eventually timed 247 out if no further messages are received from that ZBR, such that the 248 Zone ID will converge to the lowest address of any active ZBR for the 249 scope. 251 3.2. Informing internal entities of scopes 253 Any host or application may listen to Zone Announcement Messages to 254 build up a list of the scope zones that are relevant locally. However, 255 listening to Zone Announcement Messages is not the recommended method 256 for regular applications to discover this information. These 257 applications will normally query a local Multicast Address Allocation 258 Server [3], which in turn listens to Zone Announcement Messages to 259 Draft MZAP August 1998 261 maintain a list of scopes. 263 3.3. Detecting non-convex scope zones 265 Non-convex scope zones can be detected via two methods: 267 (1) If a ZBR is listed in ZCMs received, but the next-hop interface 268 (according to the multicast RIB) towards that ZBR is outside the 269 scope zone, or 271 (2) If a ZBR is listed in ZCMs received, but no ZCM is received from 272 that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in figure 3. 274 Zone Convexity Messages MAY also be sent and received by correctly 275 configured ordinary hosts within a scope region, which may be a useful 276 diagnostic facility that does not require privileged access. 278 3.4. Detecting leaky boundaries for non-local scopes 280 Leaky scope boundaries can be detected via two methods: 282 (1) If it receives ZAMs originating inside the scope boundary on an 283 interface that points outside the zone boundary. Such a ZAM 284 message must have escaped the zone through a leak, and flooded back 285 around behind the boundary. This is illustrated in figure 4. 287 =============#####*######## 288 = Zone1 # A Zone2 # C = misconfigured router 289 = +---->*E v # 290 = | # B # ##### = leaky scope boundary 291 =======*=====#====*=======# 292 = D # | # ===== = other scope boundaries 293 = ^-----*C<--+ # 294 = Zone4 # Zone3 # ----> = path of ZAMs 295 =============############## 297 Figure 4: ZAM Leaking 299 (2) If a ZLE message is received. 301 In either case, the misconfigured router will be one of the routers in 302 the path list included in the message received. 304 Draft MZAP August 1998 306 3.5. Detecting a leaky Local Scope zone 308 A local scope is leaky if a router has an admin scope boundary on some 309 interface, but does not have a Local Scope boundary on that interface as 310 specified in RFC 2365. This can be detected via the following method: 312 o If a ZAM for a given scope is received by a ZBR which is a border for 313 that scope, it compares the Origin's Scope Zone ID in the ZAM with 314 its own Zone ID for the given scope. If the two do not match, this 315 is evidence of a misconfiguration. Since a temporary mismatch may 316 result immediately after a recent change in the reachability of the 317 lowest-addressed ZBR, misconfiguration should be assumed only if the 318 mismatch is persistent. 320 The exact location of the problem can be found by doing an mtrace [5] 321 from the router detecting the problem, back to the ZAM origin, for any 322 group within the address range identified by the ZAM. The router at 323 fault will be the one reporting that a boundary was reached. 325 3.6. Detecting conflicting scope zones 327 Conflicting address ranges can be detected via the following method: 329 o If a ZBR receives a ZAM for a given scope, and the included start and 330 end addresses overlap with, but are not identical to, the start and 331 end addresses of a locally-configured scope. 333 Conflicting scope names can be detected via the following method: 335 o If a ZBR is configured with a non-empty scope name for a given scope, 336 and it receives a ZAM with a non-empty scope name for the same scope, 337 and the scope names do not match. 339 Detecting either type of conflict above indicates that either the local 340 router or router originating the message is misconfigured. 342 3.7. Packet Formats 344 All MZAP messages are sent over UDP, with a destination port of [MZAP- 345 PORT]. The common MZAP message header (which follows the UDP header), 346 is show below: 348 Draft MZAP August 1998 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Version | PTYPE |Address Family | NameLen | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Message Origin | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Zone ID Address | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Zone Start Address | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Zone End Address | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Zone Name | 364 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | Padding (if needed) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Version: 368 The version defined in this document is version 0. 370 Packet Type (PTYPE): 371 The packet types defined in this document are: 372 0: Zone Announcement Message (ZAM) 373 1: Zone Limit Exceeded (ZLE) 374 2: Zone Convexity Message (ZCM) 376 Address Family: 377 This indicates the format of the following packet. The following 378 values are defined by this document: 379 0: IPv4 380 1: IPv6 382 Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) 383 This gives the start address for the scope zone border. For example, 384 if the zone is a border for 239.1.0.0 to 239.1.0.255, then Zone Start 385 Address is 239.1.0.0. 387 Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) 388 This gives the ending address for the scope zone border. For 389 example, if the zone is a border for 239.1.0.0 to 239.1.0.255, then 390 Zone End Address is 239.1.0.255. 392 Message Origin: 32 bits (IPv4) or 128 bits (IPv6) 393 This gives the IP address of the interface that originated the 394 message. 396 Draft MZAP August 1998 398 Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6) 399 This gives the lowest IP address of a boundary router that has been 400 observed in the zone originating the message. Together with Zone 401 Start Address and Zone End Address, it forms a unique ID for the 402 zone. Note that this ID is NOT the ID of the Local Scope zone in 403 which the origin resides. 405 Name Len: 406 The length, in bytes, of the Zone Name field. 408 Zone Name: multiple of 8 bits 409 The Zone Name is an ISO 10646 character string in UTF-8 encoding [4] 410 indicating the name given to the scope zone (eg: ``ISI-West Site''). 411 It should be relatively short and MUST be less than 256 bytes in 412 length. All the border routers to the same region SHOULD be 413 configured to give the same Zone Name, or a zero length string MAY be 414 given. A zero length string is taken to mean that another router is 415 expected to be configured with the zone name. Having ALL the ZBRs 416 for a scope zone announce zero length names should be considered an 417 error. 419 Padding (if needed): 420 The MZAP header is padded with null bytes until it is 4-byte aligned. 422 3.7.1. Zone Announcement Message 424 A Zone Announcement Message has PTYPE=0, and is periodically sent by a 425 ZBR for each scope for which it is a border, EXCEPT: 427 o the Global Scope 429 o the Local Scope 431 o the Link-local scope 433 The format of a Zone Announcement Message is shown below: 435 Draft MZAP August 1998 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 MZAP Header 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | ZT | ZTL | Hold Time | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Local Zone ID Address 0 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Router Address 1 | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Local Zone ID Address 1 | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 ..... 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Router Address N | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Local Zone ID Address N | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Authentication Block (optional) 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 The fields are defined as follows: 460 Zones Traveled (ZT): 8 bits 461 This gives the number of Local Zone IDs contained in this message 462 path. 464 Zones Traveled Limit (ZTL): 8 bits 465 This gives the limit on number of local zones that the packet can 466 traverse before it MUST be dropped. A value of 0 indicates that no 467 limit exists. 469 Hold Time: 470 The time, in seconds, after which the receiver may assume the scope 471 no longer exists, if no subsequent ZAM is received. This should be 472 set to [ZAM-HOLDTIME]. 474 Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) 475 The zone path is a list of Local Zone ID Addresses (the Zone ID 476 Address of a local zone) through which the ZAM has passed, and IP 477 addresses of the router that forwarded the packet. The origin router 478 fills in the "Local Zone ID Address 0" field when sending the ZAM. 479 Every Local Scope router that forwards the ZAM across a Local Scope 480 boundary MUST add the Local Zone ID Address of the local zone that 481 the packet of the zone into which the message is being forwarded, and 483 Draft MZAP August 1998 485 its own IP address to the end of this list, and increment ZT 486 accordingly. The zone path is empty which the ZAM is first sent. 488 Authentication Block: 489 If present, this provides information which can be used to 490 authenticate the sender of the ZAM (i.e. Router Address N, if ZT is 491 non-zero, or Message Origin, if ZT is zero). (TBD: any reason not to 492 re-use SAP's "Authentication Header" here?) 494 3.7.2. Zone Limit Exceeded (ZLE) 496 This packet is sent by a local-zone border router that would have 497 exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. To 498 avoid ZLE implosion, ZLEs are multicast with a random delay and 499 suppressed by other ZLEs. It is only scheduled if at least [ZLE-MIN- 500 INTERVAL] seconds have elapsed since it previously sent a ZLE to any 501 destination. To schedule a ZLE, the router sets a random delay timer 502 within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the 503 [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any 504 are received before the random delay timer expires, the timer is cleared 505 and the ZLE is not sent. If the timer expires, the router sends a ZLE 506 to the [MZAP-RELATIVE-GROUP] within the indicated scope. 508 The method used to choose a random delay (T) is as follows: 509 Choose a random value X from the uniform random interval [0:1] 510 Let C = 256 511 Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) 512 This method ensures that close to one ZBR will respond. 514 The format of a ZLE is shown below: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 MZAP Header 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | ZT | ZTL | unused | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Local Zone ID Address 0 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Router Address 1 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Local Zone ID Address 1 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 ..... 530 Draft MZAP August 1998 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Router Address N | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Local Zone ID Address N | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 All fields are copied from the ZAM, except PTYPE which is set to one. 540 A router receiving ZLE messages SHOULD log them and attempt to alert the 541 network administrator that the scope zone is misconfigured. 543 3.7.3. Zone Convexity Message 545 A Zone Announcement Message has PTYPE=2, and is periodically sent by a 546 ZBR for each scope for which it is a border, EXCEPT: 548 o the Global Scope 550 o the Link-local scope 551 (Note that ZCM's ARE sent in the Local Scope.) 553 Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL- 554 GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP] in 555 the scope zone itself. The format of a ZCM is shown below: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 MZAP Header 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | ZNUM | unused | Hold Time | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | ZBR Address 1 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 ..... 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | ZBR Address N | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 The fields are as follows: 571 Number of ZBR addresses (ZNUM): 8 bits 572 This field gives the number of ZBR Addresses contained in this 573 message. 574 Hold Time: 575 The time, in seconds, after which the receiver may assume the sender 577 Draft MZAP August 1998 579 is no longer reachable, if no subsequent ZCM is received. This 580 should be set to [ZCM-HOLDTIME]. 582 ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) 583 These fields give the addresses of the other ZBRs from which the 584 Message Origin ZBR has received ZCMs but whose hold time has not 585 expired. The router should include all such addresses which fit in 586 the packet, preferring those which it has not included recently if 587 all do not fit. 589 4. Message Timing 591 Each ZBR should send a Zone Announcement Message for each scope zone for 592 which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM- 593 INTERVAL] each time to avoid message synchronisation. 595 Each ZBR should send a Zone Convexity Message for each scope zone for 596 which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM- 597 INTERVAL] each time to avoid message synchronisation. 599 A router SHOULD NOT send more than one Zone Limit Exceeded message every 600 [ZLE-MIN-INTERVAL] regardless of destination. 602 5. Constants 604 [MZAP-PORT]: The well-known UDP port to which all MZAP messages are 605 sent. Value: TBD by IANA. 607 [MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which 608 ZAMs are sent. All Multicast Address Allocation servers and Zone Border 609 Routers listen to this group. Value: TBD by IANA. 611 [ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which 612 ZCMs are sent. A Zone Border Router listens to the relative group in 613 each scope for which it is a border. Value: TBD by IANA. 615 [ZAM-INTERVAL]: The interval at which a Zone Border Router originates 616 Zone Announcement Messages. Default value: 600 seconds (10 minutes). 618 [ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set 619 to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31 620 minutes). 622 Draft MZAP August 1998 624 [ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which 625 ZAMs for the same scope will not be forwarded. Default value: 30 626 seconds. 628 [ZCM-INTERVAL]: The interval at which a Zone Border Router originates 629 Zone Convexity Messages. Default value: 600 seconds (10 minutes). 631 [ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set 632 to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31 633 minutes). 635 [ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random 636 delay before sending a ZLE message. Default value: 300 seconds (5 637 minutes). 639 [ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, 640 regardless of destination. Default value: 300 seconds (5 minutes). 642 6. Security Considerations 644 MZAP does not include authentication in its messages. Thus it is open 645 to misbehaving hosts sending spoof ZAMs or ZCMs. 647 In the case of ZCMs, these spoof messages can cause false logging of 648 convexity problems. It is likely that is would be purely an annoyance, 649 and not cause any significant problem. 651 In the case of ZAMs, spoof messages can also cause false logging of 652 configuration problems. This is also considered to not be a significant 653 problem. 655 Spoof zone announcements however might cause applications to believe 656 that a scope zone exists when it does not. If these were believed, then 657 applications may choose to use this non-existent admin scope zone for 658 their uses. Such applications would be able to communicate 659 successfully, but would be unaware that their traffic may be traveling 660 further than they expected. As a result, applications MUST only take 661 scope names as a guideline, and SHOULD assume that their traffic sent to 662 non-local scope zones might travel anywhere. The confidentiality of 663 such traffic CANNOT be assumed from the fact that it was sent to a 664 scoped address that was discovered using MZAP. 666 In addition, ZAMs are used to inform Multicast Address Allocation 667 Servers of names of scopes, and spoofed ZAMs would result in false names 668 Draft MZAP August 1998 670 being presented to users. To counter this, ZAMs may be authenticated as 671 follows: 673 (1) A ZBR signs all ZAMs it originates. 675 (2) A ZBR signs a ZAM it forwards if and only if it can authenticate 676 the previous sender. A ZBR MUST still forward un-authenticated 677 ZAMs (to provide leak detection), but should propagate an 678 autheticated ZAM even if an un-authenticated one was received with 679 the last [ZAM-DUP-TIME] seconds. 681 (3) A MAAS SHOULD be configured with the public key of the local zone 682 in which it resides. A MAAS thus configured SHOULD ignore an 683 unauthenticated ZAM if an authenticated one for the same scope has 684 been received, and MAY ignore all unauthenticated ZAMs. 686 7. References 688 [1] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 689 1998. 691 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 692 Levels", RFC 2119, March 1997. 694 [3] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast 695 Address Allocation Architecture", Internet Draft, Dec 1997. 697 [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 698 2279, January 1998. 700 [5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP 701 Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft, 702 November 1997. 704 8. Full Copyright Statement 706 Copyright (C) The Internet Society (1998). All Rights Reserved. 708 This document and translations of it may be copied and furnished to 709 others, and derivative works that comment on or otherwise explain it or 710 assist in its implmentation may be prepared, copied, published and 711 distributed, in whole or in part, without restriction of any kind, 712 provided that the above copyright notice and this paragraph are included 713 Draft MZAP August 1998 715 on all such copies and derivative works. However, this document itself 716 may not be modified in any way, such as by removing the copyright notice 717 or references to the Internet Society or other Internet organizations, 718 except as needed for the purpose of developing Internet standards in 719 which case the procedures for copyrights defined in the Internet 720 languages other than English. 722 The limited permissions granted above are perpetual and will not be 723 revoked by the Internet Society or its successors or assigns. 725 This document and the information contained herein is provided on an "AS 726 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 727 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 728 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 729 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 730 FITNESS FOR A PARTICULAR PURPOSE." 732 Table of Contents 734 1 Introduction .................................................... 2 735 2 Overview ........................................................ 3 736 3 Usage ........................................................... 6 737 3.1 Zone IDs ...................................................... 6 738 3.2 Informing internal entities of scopes ......................... 6 739 3.3 Detecting non-convex scope zones .............................. 7 740 3.4 Detecting leaky boundaries for non-local scopes ............... 7 741 3.5 Detecting a leaky Local Scope zone ............................ 8 742 3.6 Detecting conflicting scope zones ............................. 8 743 3.7 Packet Formats ................................................ 8 744 3.7.1 Zone Announcement Message ................................... 10 745 3.7.2 Zone Limit Exceeded (ZLE) ................................... 12 746 3.7.3 Zone Convexity Message ...................................... 13 747 4 Message Timing .................................................. 14 748 5 Constants ....................................................... 14 749 6 Security Considerations ......................................... 15 750 7 References ...................................................... 16 751 8 Full Copyright Statement ........................................ 16