idnits 2.17.1 draft-ietf-mboned-mzap-02.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 too long lines in the document, the longest one being 7 characters in excess of 72. == 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 (April 1999) is 9142 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 657 -- Looks like a reference, but probably isn't: 'ZAM-DUP-TIME' on line 729 -- Looks like a reference, but probably isn't: 'ZCM-RELATIVE-GROUP' on line 661 -- Looks like a reference, but probably isn't: 'ZCM-HOLDTIME' on line 681 -- Looks like a reference, but probably isn't: 'MZAP-PORT' on line 654 -- Looks like a reference, but probably isn't: 'ZAM-HOLDTIME' on line 668 -- Looks like a reference, but probably isn't: 'ZLE-MIN-INTERVAL' on line 689 -- Looks like a reference, but probably isn't: 'ZLE-SUPPRESSION-INTERVAL' on line 685 -- Looks like a reference, but probably isn't: 'MZAP-RELATIVE-GROUP' on line 556 -- Looks like a reference, but probably isn't: 'ZAM-INTERVAL' on line 669 -- Looks like a reference, but probably isn't: 'ZCM-INTERVAL' on line 682 -- 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' ** Obsolete normative reference: RFC 1766 (ref. '6') (Obsoleted by RFC 3066, RFC 3282) -- Unexpected draft version: The latest known version of draft-handley-aap is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '7' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 19 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 7 October 1998 Microsoft 6 Expires April 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 October 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 October 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 October 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 October 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, nor is it sent into any local 181 scope zone whose ID is known and appears in the path list). In each 182 such ZAM re-originated, the ZBR adds its own IP address to the path 183 list, as well as the Zone ID Address of the Local Scope Zone into 184 which the ZAM is being sent, or 0 if the ID is unknown. (For example, 185 if the other end of a point-to-point link also has a boundary on the 186 interface, then the link has no Local Scope Zone ID.) 188 ########################### 189 # Zone1 = Zone2 # ##### = large scope zone border 190 *E-----+--->A*-----+-x # 191 # | = v # ===== = Local Scope boundaries 192 # | ======*===*==# 193 # | = B F # ----> = path of ZAM origined by E 194 # +--->C*-> | ^ # 195 # v = <-+---+ # ABCDE = ZBRs 196 # D = Zone3 # 197 #######*################### * = border interface 199 Figure 2: ZAM Flooding Example 201 The packet also contains a Zones Traveled Limit. If the number of Local 202 Zone IDs in the ZAM path becomes equal to the Zones Traveled Limit, the 203 packet should be dropped. Zones Traveled Limit is set when the packet is 204 first sent, and defaults to 32, but can be set to a lower value if a 205 network administrator knows the expected size of the zone. 207 Additional messages called Zone Convexity Messages (ZCMs) SHOULD also be 208 sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. As these 209 are not locally scoped packets, they are simply multicast across the 210 scope zone itself, and require no path to be built up, nor any special 211 processing by Local Scope zone ZBRs. These messages are used to detect 212 non-convex admin scope zones, as illustrated in figure 3, where the path 213 between B and D goes outside the scope (through A and E). Here Router B 214 and Router C originates ZCMs, each reporting each other's presence. 215 Router D cannot see Router B's messages, but can see C's report of B, 216 and so can conclude the zone is not convex. 218 Draft MZAP October 1998 220 #####*####======== 221 # B # = ##### = non-convex scope boundary 222 # |->A* = 223 # | # = ===== = other scope boundaries 224 # | ####*#### 225 # | E # ----> = path of B's ZAM 226 # v D* 227 # C # * = border interface 228 #####*############ 230 Figure 3: Non-convexity detection 232 3. Usage 234 In this section, we summarize how to inform internal entities of scopes 235 in which they reside, as well as how to detect various error conditions. 236 If any error is detected, the router should attempt to alert a network 237 administrator to the nature of the misconfiguration. The means to do 238 this lies outside the scope of MZAP. 240 3.1. Zone IDs 242 When a border router first starts up, it uses its lowest IP address 243 which it considers to be inside a given zone as the Zone ID for that 244 zone, and schedules the ZCM and ZAM messages to be sent in the future 245 (it does not send them immedately). When a ZAM or ZCM is received for 246 the given scope, the sender is added to the local list of ZBRs 247 (including itself) for that scope, and the Zone ID is updated to be the 248 lowest IP address in the list. Entries in the list are eventually timed 249 out if no further messages are received from that ZBR, such that the 250 Zone ID will converge to the lowest address of any active ZBR for the 251 scope. 253 3.2. Informing internal entities of scopes 255 Any host or application may listen to Zone Announcement Messages to 256 build up a list of the scope zones that are relevant locally. However, 257 listening to Zone Announcement Messages is not the recommended method 258 for regular applications to discover this information. These 259 applications will normally query a local Multicast Address Allocation 260 Server [3], which in turn listens to Zone Announcement Messages to 261 Draft MZAP October 1998 263 maintain a list of scopes. 265 3.3. Detecting non-convex scope zones 267 Non-convex scope zones can be detected via two methods: 269 (1) If a ZBR is listed in ZCMs received, but the next-hop interface 270 (according to the multicast RIB) towards that ZBR is outside the 271 scope zone, or 273 (2) If a ZBR is listed in ZCMs received, but no ZCM is received from 274 that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in figure 3. 276 Zone Convexity Messages MAY also be sent and received by correctly 277 configured ordinary hosts within a scope region, which may be a useful 278 diagnostic facility that does not require privileged access. 280 3.4. Detecting leaky boundaries for non-local scopes 282 Leaky scope boundaries can be detected via two methods: 284 (1) If it receives ZAMs originating inside the scope boundary on an 285 interface that points outside the zone boundary. Such a ZAM 286 message must have escaped the zone through a leak, and flooded back 287 around behind the boundary. This is illustrated in figure 4. 289 =============#####*######## 290 = Zone1 # A Zone2 # C = misconfigured router 291 = +---->*E v # 292 = | # B # ##### = leaky scope boundary 293 =======*=====#====*=======# 294 = D # | # ===== = other scope boundaries 295 = ^-----*C<--+ # 296 = Zone4 # Zone3 # ----> = path of ZAMs 297 =============############## 299 Figure 4: ZAM Leaking 301 (2) If a ZLE message is received. 303 In either case, the misconfigured router will be either the message 304 origin, or one of the routers in the path list included in the message 305 Draft MZAP October 1998 307 received. 309 3.5. Detecting a leaky Local Scope zone 311 A local scope is leaky if a router has an admin scope boundary on some 312 interface, but does not have a Local Scope boundary on that interface as 313 specified in RFC 2365. This can be detected via the following method: 315 o If a ZAM for a given scope is received by a ZBR which is a border for 316 that scope, it compares the Origin's Scope Zone ID in the ZAM with 317 its own Zone ID for the given scope. If the two do not match, this 318 is evidence of a misconfiguration. Since a temporary mismatch may 319 result immediately after a recent change in the reachability of the 320 lowest-addressed ZBR, misconfiguration should be assumed only if the 321 mismatch is persistent. 323 The exact location of the problem can be found by doing an mtrace [5] 324 from the router detecting the problem, back to the ZAM origin, for any 325 group within the address range identified by the ZAM. The router at 326 fault will be the one reporting that a boundary was reached. 328 3.6. Detecting conflicting scope zones 330 Conflicting address ranges can be detected via the following method: 332 o If a ZBR receives a ZAM for a given scope, and the included start and 333 end addresses overlap with, but are not identical to, the start and 334 end addresses of a locally-configured scope. 336 Conflicting scope names can be detected via the following method: 338 o If a ZBR is configured with a non-empty scope name for a given scope, 339 and it receives a ZAM with a non-empty scope name for the same scope, 340 and the scope names do not match. 342 Detecting either type of conflict above indicates that either the local 343 router or router originating the message is misconfigured. 344 Configuration tools SHOULD strip white space from the beginning and end 345 of each name to avoid accidental misconfiguration. 347 Draft MZAP October 1998 349 3.7. Packet Formats 351 All MZAP messages are sent over UDP, with a destination port of [MZAP- 352 PORT]. The common MZAP message header (which follows the UDP header), 353 is shown below: 355 Draft MZAP October 1998 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Version |B| PTYPE |Address Family | NameCount | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Message Origin | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Zone ID Address | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Zone Start Address | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Zone End Address | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Encoded Zone Name-1 (variable length) | 371 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | . . . | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | . . . | Encoded Zone Name-N (variable length) | 375 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | Padding (if needed) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Version: 379 The version defined in this document is version 0. 381 "Big" scope bit (B): 382 If clear, indicates that the addresses in the scoped range are not 383 subdividable, and that address allocators may utilize the entire 384 range. If set, address allocators should not use the entire range, 385 but should learn an appropriate sub-range via another mechanism 386 (e.g., AAP [7]). 388 Packet Type (PTYPE): 389 The packet types defined in this document are: 390 0: Zone Announcement Message (ZAM) 391 1: Zone Limit Exceeded (ZLE) 392 2: Zone Convexity Message (ZCM) 394 Address Family: 395 The IANA-assigned address family number identifying the address 396 family for all addresses in the packet. The families defined for IP 397 are: 398 1: IPv4 399 2: IPv6 401 Name Count: 403 Draft MZAP October 1998 405 The number of encoded zone name blocks in this packet. The count may 406 be zero. 408 Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) 409 This gives the start address for the scope zone border. For example, 410 if the zone is a border for 239.1.0.0 to 239.1.0.255, then Zone Start 411 Address is 239.1.0.0. 413 Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) 414 This gives the ending address for the scope zone border. For 415 example, if the zone is a border for 239.1.0.0 to 239.1.0.255, then 416 Zone End Address is 239.1.0.255. 418 Message Origin: 32 bits (IPv4) or 128 bits (IPv6) 419 This gives the IP address of the interface that originated the 420 message. 422 Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6) 423 This gives the lowest IP address of a boundary router that has been 424 observed in the zone originating the message. Together with Zone 425 Start Address and Zone End Address, it forms a unique ID for the 426 zone. Note that this ID is NOT the ID of the Local Scope zone in 427 which the origin resides. 429 Encoded Zone Name: 430 +--------------------+ 431 |D| LangLen (7 bits) | 432 +--------------------+-----------+ 433 | Language Tag (variable size) | 434 +--------------------+-----------+ 435 | NameLen (1 byte) | 436 +--------------------+-----------+ 437 | Zone Name (variable size) | 438 +--------------------------------+ 440 "Default Language" (D) bit: 441 If set, indicates a preference that the name in the following language 442 should be used if no name is available in a desired language. 444 Language tag length (LangLen): 7 bits 445 The length, in bytes, of the language tag. 447 Language Tag: (variable size) 448 The language tag, such as "en-US", indicating the language of the zone name. 449 Language tags are described in [6]. 451 Draft MZAP October 1998 453 Name Len: 454 The length, in bytes, of the Zone Name field. 455 The length MUST NOT be zero. 457 Zone Name: multiple of 8 bits 458 The Zone Name is an ISO 10646 459 character string in UTF-8 encoding [4] indicating the name given to the 460 scope zone (eg: ``ISI-West Site''). It should be relatively short and 461 MUST be less than 256 bytes in length. All the border routers to the 462 same region SHOULD be configured to give the same Zone Name, or a zero 463 length string MAY be given. A zero length string is taken to mean 464 that another router is expected to be configured with the zone name. 465 Having ALL the ZBRs for a scope zone announce zero length names 466 should be considered an error. 468 Padding (if needed): 469 The end of the MZAP header is padded with null bytes until it is 470 4-byte aligned. 472 3.7.1. Zone Announcement Message 474 A Zone Announcement Message has PTYPE=0, and is periodically sent by a 475 ZBR for each scope for which it is a border, EXCEPT: 477 o the Global Scope 479 o the Local Scope 481 o the Link-local scope 483 The format of a Zone Announcement Message is shown below: 485 Draft MZAP October 1998 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 MZAP Header 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | ZT | ZTL | Hold Time | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Local Zone ID Address 0 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Router Address 1 | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Local Zone ID Address 1 | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 ..... 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Router Address N | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Local Zone ID Address N | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Authentication Block (optional) 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 The fields are defined as follows: 510 Zones Traveled (ZT): 8 bits 511 This gives the number of Local Zone IDs contained in this message 512 path. 514 Zones Traveled Limit (ZTL): 8 bits 515 This gives the limit on number of local zones that the packet can 516 traverse before it MUST be dropped. A value of 0 indicates that no 517 limit exists. 519 Hold Time: 520 The time, in seconds, after which the receiver may assume the scope 521 no longer exists, if no subsequent ZAM is received. This should be 522 set to [ZAM-HOLDTIME]. 524 Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) 525 The zone path is a list of Local Zone ID Addresses (the Zone ID 526 Address of a local zone) through which the ZAM has passed, and IP 527 addresses of the router that forwarded the packet. The origin router 528 fills in the "Local Zone ID Address 0" field when sending the ZAM. 529 Every Local Scope router that forwards the ZAM across a Local Scope 530 boundary MUST add the Local Zone ID Address of the local zone that 531 the packet of the zone into which the message is being forwarded, and 533 Draft MZAP October 1998 535 its own IP address to the end of this list, and increment ZT 536 accordingly. The zone path is empty which the ZAM is first sent. 538 Authentication Block: 539 If present, this provides information which can be used to 540 authenticate the sender of the ZAM (i.e. Router Address N, if ZT is 541 non-zero, or Message Origin, if ZT is zero). (TBD: any reason not to 542 re-use SAP's "Authentication Header" here?) 544 3.7.2. Zone Limit Exceeded (ZLE) 546 This packet is sent by a local-zone border router that would have 547 exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. To 548 avoid ZLE implosion, ZLEs are multicast with a random delay and 549 suppressed by other ZLEs. It is only scheduled if at least [ZLE-MIN- 550 INTERVAL] seconds have elapsed since it previously sent a ZLE to any 551 destination. To schedule a ZLE, the router sets a random delay timer 552 within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the 553 [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any 554 are received before the random delay timer expires, the timer is cleared 555 and the ZLE is not sent. If the timer expires, the router sends a ZLE 556 to the [MZAP-RELATIVE-GROUP] within the indicated scope. 558 The method used to choose a random delay (T) is as follows: 559 Choose a random value X from the uniform random interval [0:1] 560 Let C = 256 561 Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) 562 This method ensures that close to one ZBR will respond. 564 The format of a ZLE is shown below: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 MZAP Header 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | ZT | ZTL | unused | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Local Zone ID Address 0 | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Router Address 1 | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Local Zone ID Address 1 | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 ..... 580 Draft MZAP October 1998 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Router Address N | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Local Zone ID Address N | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 All fields are copied from the ZAM, except PTYPE which is set to one. 590 A router receiving ZLE messages SHOULD log them and attempt to alert the 591 network administrator that the scope zone is misconfigured. 593 3.7.3. Zone Convexity Message 595 A Zone Announcement Message has PTYPE=2, and is periodically sent by a 596 ZBR for each scope for which it is a border, EXCEPT: 598 o the Global Scope 600 o the Link-local scope 601 (Note that ZCM's ARE sent in the Local Scope.) 603 Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL- 604 GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP] in 605 the scope zone itself. The format of a ZCM is shown below: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 MZAP Header 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | ZNUM | unused | Hold Time | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | ZBR Address 1 | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 ..... 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | ZBR Address N | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 The fields are as follows: 621 Number of ZBR addresses (ZNUM): 8 bits 622 This field gives the number of ZBR Addresses contained in this 623 message. 624 Hold Time: 625 The time, in seconds, after which the receiver may assume the sender 627 Draft MZAP October 1998 629 is no longer reachable, if no subsequent ZCM is received. This 630 should be set to [ZCM-HOLDTIME]. 632 ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) 633 These fields give the addresses of the other ZBRs from which the 634 Message Origin ZBR has received ZCMs but whose hold time has not 635 expired. The router should include all such addresses which fit in 636 the packet, preferring those which it has not included recently if 637 all do not fit. 639 4. Message Timing 641 Each ZBR should send a Zone Announcement Message for each scope zone for 642 which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM- 643 INTERVAL] each time to avoid message synchronisation. 645 Each ZBR should send a Zone Convexity Message for each scope zone for 646 which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM- 647 INTERVAL] each time to avoid message synchronisation. 649 A router SHOULD NOT send more than one Zone Limit Exceeded message every 650 [ZLE-MIN-INTERVAL] regardless of destination. 652 5. Constants 654 [MZAP-PORT]: The well-known UDP port to which all MZAP messages are 655 sent. Value: TBD by IANA. 657 [MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which 658 ZAMs are sent. All Multicast Address Allocation servers and Zone Border 659 Routers listen to this group. Value: TBD by IANA. 661 [ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which 662 ZCMs are sent. A Zone Border Router listens to the relative group in 663 each scope for which it is a border. Value: TBD by IANA. 665 [ZAM-INTERVAL]: The interval at which a Zone Border Router originates 666 Zone Announcement Messages. Default value: 600 seconds (10 minutes). 668 [ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set 669 to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31 670 minutes). 672 Draft MZAP October 1998 674 [ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which 675 ZAMs for the same scope will not be forwarded. Default value: 30 676 seconds. 678 [ZCM-INTERVAL]: The interval at which a Zone Border Router originates 679 Zone Convexity Messages. Default value: 600 seconds (10 minutes). 681 [ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set 682 to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31 683 minutes). 685 [ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random 686 delay before sending a ZLE message. Default value: 300 seconds (5 687 minutes). 689 [ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, 690 regardless of destination. Default value: 300 seconds (5 minutes). 692 6. Security Considerations 694 MZAP does not include authentication in its messages. Thus it is open 695 to misbehaving hosts sending spoof ZAMs or ZCMs. 697 In the case of ZCMs, these spoof messages can cause false logging of 698 convexity problems. It is likely that is would be purely an annoyance, 699 and not cause any significant problem. 701 In the case of ZAMs, spoof messages can also cause false logging of 702 configuration problems. This is also considered to not be a significant 703 problem. 705 Spoof zone announcements however might cause applications to believe 706 that a scope zone exists when it does not. If these were believed, then 707 applications may choose to use this non-existent admin scope zone for 708 their uses. Such applications would be able to communicate 709 successfully, but would be unaware that their traffic may be traveling 710 further than they expected. As a result, applications MUST only take 711 scope names as a guideline, and SHOULD assume that their traffic sent to 712 non-local scope zones might travel anywhere. The confidentiality of 713 such traffic CANNOT be assumed from the fact that it was sent to a 714 scoped address that was discovered using MZAP. 716 In addition, ZAMs are used to inform Multicast Address Allocation 717 Servers of names of scopes, and spoofed ZAMs would result in false names 718 Draft MZAP October 1998 720 being presented to users. To counter this, ZAMs may be authenticated as 721 follows: 723 (1) A ZBR signs all ZAMs it originates. 725 (2) A ZBR signs a ZAM it forwards if and only if it can authenticate 726 the previous sender. A ZBR MUST still forward un-authenticated 727 ZAMs (to provide leak detection), but should propagate an 728 autheticated ZAM even if an un-authenticated one was received with 729 the last [ZAM-DUP-TIME] seconds. 731 (3) A MAAS SHOULD be configured with the public key of the local zone 732 in which it resides. A MAAS thus configured SHOULD ignore an 733 unauthenticated ZAM if an authenticated one for the same scope has 734 been received, and MAY ignore all unauthenticated ZAMs. 736 7. References 738 [1] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 739 1998. 741 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 742 Levels", RFC 2119, March 1997. 744 [3] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast 745 Address Allocation Architecture", Internet Draft, Dec 1997. 747 [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 748 2279, January 1998. 750 [5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP 751 Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft, 752 November 1997. 754 [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 755 1766, March 1995. 757 [7] Handley, M., "Multicast Address Allocation Protocol (AAP)", draft- 758 handley-aap-01.txt, Internet Draft, July 1998. 760 Draft MZAP October 1998 762 8. Full Copyright Statement 764 Copyright (C) The Internet Society (1998). All Rights Reserved. 766 This document and translations of it may be copied and furnished to 767 others, and derivative works that comment on or otherwise explain it or 768 assist in its implmentation may be prepared, copied, published and 769 distributed, in whole or in part, without restriction of any kind, 770 provided that the above copyright notice and this paragraph are included 771 on all such copies and derivative works. However, this document itself 772 may not be modified in any way, such as by removing the copyright notice 773 or references to the Internet Society or other Internet organizations, 774 except as needed for the purpose of developing Internet standards in 775 which case the procedures for copyrights defined in the Internet 776 languages other than English. 778 The limited permissions granted above are perpetual and will not be 779 revoked by the Internet Society or its successors or assigns. 781 This document and the information contained herein is provided on an "AS 782 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 783 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 784 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 785 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 786 FITNESS FOR A PARTICULAR PURPOSE." 788 Table of Contents 790 1 Introduction .................................................... 2 791 2 Overview ........................................................ 3 792 3 Usage ........................................................... 6 793 3.1 Zone IDs ...................................................... 6 794 3.2 Informing internal entities of scopes ......................... 6 795 3.3 Detecting non-convex scope zones .............................. 7 796 3.4 Detecting leaky boundaries for non-local scopes ............... 7 797 3.5 Detecting a leaky Local Scope zone ............................ 8 798 3.6 Detecting conflicting scope zones ............................. 8 799 3.7 Packet Formats ................................................ 9 800 3.7.1 Zone Announcement Message ................................... 12 801 3.7.2 Zone Limit Exceeded (ZLE) ................................... 14 802 3.7.3 Zone Convexity Message ...................................... 15 803 4 Message Timing .................................................. 16 804 5 Constants ....................................................... 16 805 Draft MZAP October 1998 807 6 Security Considerations ......................................... 17 808 7 References ...................................................... 18 809 8 Full Copyright Statement ........................................ 19