Internet Engineering Task Force MboneD WG Internet Draft M. Handley draft-ietf-mboned-mzap-00.txt ISI December 15, 1997 Expires: June 1998 Multicast-Scope Zone Announcement Protocol (MZAP) STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby two common misconfigurations of administrative scope zones can be discovered. 1 Status This is a strawman proposal. It has not been subject to any peer review or implementation. 2 Introduction IP Multicast groups can be global scope, or they can be restricted in M. Handley [Page 1]
Internet Draft MZAP December 15, 1997 scope using a scoping mechanism. In this document, we only consider administrative scoping, as defined in [1]. An administrative scope zone is defined by a set of border routers to a region of the network. These border routers are configured to not pass multicast traffic destined for a particular range of multicast addresses to or from links leaving the scope zone. Administrative scope zones may be of any size, and a particular host may be within many administrative scope zones. The only zones a host can assume that it is within are the global zone, and local scope Local scope is defined as being the smallest administrative scope zone encompassing a host, and the border is configured for addresses in the range 239.255.0.0 to 239.255.255.255 inclusive. [1] specifies: 239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary. Further, a Local Scope must be completely contained within or equal to any larger scope. In the event that scope regions overlap in area, the area of overlap must be in its own local scope. This implies that any scope boundary is also a boundary for the Local Scope. Two problems make administrative scoping difficult to deploy and difficult to use: o Misconfiguration is easy. It is difficult to detect scope zones that have been configured so as to not be convex (the shortest path between two nodes within the zone passes outside the zone) or to leak (one or more border routers was not configured correctly). o Applications have no way to discover the scope zones that are relevant to them. This makes it difficult to use admin scope zones, and hence reduced the incentive to deploy them. This document defines the Multicast Scope Zone Announcement Protocol (MZAP) which will provide applications with information about the scope zones they are within, and also provide diagnostic information to detect misconfigured scope zones. 3 Specification A multicast scope Zone Border Router (ZBR) is a router that is configured to be a zone border on one or more of its interfaces. Any interface that is configured to be a border for any admin scope zone MUST also be a border for the local scope zone, as defined in [1]. M. Handley [Page 2]
Internet Draft MZAP December 15, 1997 Routers SHOULD be configured so as the router itself is within the scope zone. This is should in figure 1A, where router 1 is inside the scope zone and has the border configuration. It is possible for the first router outside the scope zone to be configured with the border, as illustrated in figure 1B where routers 2 and 3 are outside the zone and have the border configuration, but this is NOT RECOMMENDED. ............ ................ . . +O+--> . *O+--> . . / 2 . /. 2 . 1 * . 1 + . . <---+O*---+O+-> . <---+O+---*O+-> . + . 3 . + . 3 . / . . / . . zone X <-- . . zone X <-- . .............. .................. O - router * - border interface + - interface A. Correct zone border B. Incorrect zone border Figure 1: Correct admin scope zone border placement This rule does not apply for local scope borders, but applies for all other admin scope border routers. When a ZBR router is configured correctly, it can deduce which side of the boundary is inside the scope zone and which side is outside it. It can also send messages into the scope zone, which it SHOULD NOT be able to do if the router itself is considered outside the scope zone. Such a ZBR router should then send periodic Zone Announcement Messages (ZAMs) for the zone for which it is configured as a border from each of its interfaces that go into that scope zone. These messages are multicast to the address 239.255.255.254, which is a locally scoped address. Each ZBR router should also listen for ZAM messages from other ZBRs for the same border. The ZBR router with the lowest interface IP address within the zone from those ZBRs forming the zone border becomes the zone-id router for the zone. The combination of this IP address and the base address of the scoping range server to uniquely identify the scope zone. M. Handley [Page 3]
Internet Draft MZAP December 15, 1997 Every local scope ZBR that receives any ZAM for a scope zone other than local scope SHOULD then forward the ZAM out of all the other interfaces that are in different local scope zones except ones that form a border for the zone described in the ZAM. It adds the zone-id of the local scope zone that the message came from to the ZAM path list before doing so. A local scope ZBR receiving a ZAM with a non- null path list MUST NOT forward that ZAM back into a local scope zone that is contained in the path list. This process is illustrated in figure 2. in Figure 2: ZAM Message Flooding The packet also contains a Zones Traveled Limit. If the number of Local Zone IDs in the ZAM path becomes equal to the Zones Traveled Limit, the packet should be dropped. Zones Traveled Limit is set when the packet is first sent, and defaults to 32, but can be set to a lower value if a network administrator knows the expected size of the zone. Addition messages called Zone Convexity Messages (ZCM) SHOULD also be sent to the second highest address in the scope zone range itself (For example, if the scope zone border is for 239.1.0.0 to 239.1.0.255, then these messages should be sent to 239.1.0.254.) As these are not locally scoped packets, they are simply multicast across the scope zone itself, and require no path to be built up, or forwarding by local scope zone ZBRs. These messages are used to detect non-convex admin scope zones, as illustrated in figure 3. Here Router B and Router C originates ZCM messages, each reporting each other's presence. Router D cannot see Router B's messages, but sees Router C's report of Router B, and so concludes the zone is not convex. in Figure 3: ZAM Message Flooding 3.1 Packet Formats Zone Announcement Message (IPv4) The format of a Zone Announcement Message is shown in figure 4. M. Handley [Page 4]
Internet Draft MZAP December 15, 1997 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 |R| PTYPE | ZT | ZTL | IP | MLEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Base Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Origin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone ID Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Name | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Zone Announcement Message Format The fields are defined as follows: Version (V): 3 bits The version defined in this document is version 0. Respond (R): 1 bit When set to 1, this bit indicates that a router MAY generate a Zone Limit Exceeded message in response to this ZAM message. When set to zero, a router MUST NOT generate a Zone Limit Exceeded message in response to this message. Packet Type (PTYPE): 4 bits A Zone Announcement Message has PTYPE=0. Zone Traveled (ZT): 8 bits This gives the number of Local Zone IDs contained in this message path. Zones Traveled Limit (ZTL): 8 bits This gives the limit on number of local zones that the packet can traverse before it MUST be M. Handley [Page 5]
Internet Draft MZAP December 15, 1997 dropped. IP Protocol Version (IP): 3 bits This indicates the format of the following packet. The following values are defined: 0: IPv4 1: IPv6 Mask length (MLEN): 5 bits This gives the mask length which together with the zone base address defines the range of addresses that form the border to this zone. For example, if the zone is a border for 239.1.0.0 to 239.1.0.255, then MLEN has the value 24. A value of zero means all the bits are included in the mask, and the zone is a border for a single address. Zone Base Address: 32 bits This gives the base address for the scope zone border. For example, if the zone is a border for 239.1.0.0 to 239.1.0.255, then Zone Base Address is 239.1.0.0. Message Origin: 32 bits This gives the IP address of the interface that originated the ZAM message. Zone ID Address: 32 bits This gives the lowest IP address that has been observed in the zone sending ZAM messages. Together with Zone Base Address and MLEN it forms a unique ID for the zone. Zone Path: multiple of 64 bits The zone path is a list of 32 bit Local Zone ID Addresses (the Zone ID Address of a local zone) through which the ZAM message has passed, and 32 bit IP addresses of the router that forwarded the packet. Every local scope router that forwards the ZAM across a local scope boundary MUST add the Local Zone ID Address of the local zone that the packet was received from and its own IP address to the end of this list, and increments ZT accordingly. The zone path is empty which the ZAM message is first sent. Zone Name: multiple of 8 bits The Zone Name is an ISO 10646 character string in UTF-8 encoding indicating the name given to the scope zone (eg: "ISI-West Site"). It should be relatively short and MUST be less that 256 bytes in length. All the border routers to the same region SHOULD be configured to give the same Zone Name, or a zero length string MAY be given. A zero length string is taken to mean that another router is expected to be configured with the zone name. Having ALL the ZBR routers for a scope zone announce zero length names should be considered an error. 3.1.1 Zone Limit Exceeded (ZLE) M. Handley [Page 6]
Internet Draft MZAP December 15, 1997 This packet is sent by a local-zone border router that would have exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. It is only sent if the "Respond" bit in the ZAM packet is set, and it is unicast to the Message Origin given in the ZAM packet. The format is the same as a ZAM message, and is shown in figure 5: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 | PTYPE | ZT | ZTL | IP | MLEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Base Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Origin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone ID Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Name | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Zone Announcement Message Format All fields are copied from the ZAM message, except PTYPE which is set to one. A router receiving ZLE messages SHOULD log them and attempt to alert the network administrator that the scope zone is misconfigured. Zone Convexity Message Unlike Zone Announcement Messages which are sent to the locally scoped address 239.255.255.254, Zone Convexity Messages are sent to the second highest address in the scope zone itself. The format of a M. Handley [Page 7]
Internet Draft MZAP December 15, 1997 ZCM is shown in figure 6 and is similar to a ZAM, expect PTYPE take the value two. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 | PTYPE | ZNUM | unused | IP | MLEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Base Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Origin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone ID Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBR Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBR Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Name | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Zone Convexity Message Format The fields are as follows: Number of ZBR addresses (ZNUM): 8 bits This field gives the number of ZBR Addresses contained in this message. ZBR Address (32 bits) These fields give the addresses of ALL the other ZBR routers that the Message Origin ZBR has received ZCM messages from during the time that it has taken the Message Origin ZBR to send ten ZCM messages. 4 Using Zone Announcement Messages Any host or application may listen to Zone Announcement Messages to build up a list of the scope zones that are relevant locally. However, listening to Zone Announcement Messages is not the recommended method for regular applications to discover this M. Handley [Page 8]
Internet Draft MZAP December 15, 1997 information. These applications will normally query a local Multicast Address Allocation Server[2], which in turn will listen to Zone Announcement Messages. A ZBR can discover misconfiguration of scope boundaries in one of several ways: o It receives ZLE messages indicating that the scope zone is leaking. o It receives ZAM messages originating inside the scope boundary on an interface that points outside the zone boundary. Such a ZAM message must have escaped the zone through a leak, and flooded back around behind the boundary. This is illustrated in figure 7. o Other ZBR routers in the scope zone are announcing that they are seeing a different set of routers than our router observes from arriving ZCM messages. If this is a persistent condition, it indicates that the scope zone is probably not convex, as illustrated in figure 3. in Figure 7: ZAM Message Leaking All these conditions should be considered errors and the router should attempt to alert the network administrator to the nature of the misconfiguration. Zone Convexity Messages can also be sent and received by correctly configured ordinary hosts within a scope region, which may be a useful diagnostic facility that does not require privileged access. 5 Message Timing Each ZBR router should send a Zone Announcement Message for each scope zone for which it is a boundary every ZAM-INTERVAL seconds, +/- 30% of ZAM-INTERVAL each time to avoid message synchronisation. Each ZBR router should send a Zone Convexity Message for each scope zone for which it is a boundary every ZCM-INTERVAL seconds, +/- 30% of ZCM-INTERVAL each time to avoid message synchronisation. A router SHOULD NOT send more than one Zone Limit Exceeded message every ZLE-MIN-INTERVAL regardless of destination. M. Handley [Page 9]
Internet Draft MZAP December 15, 1997 Default values are: ZAM-INTERVAL 300 seconds. ZCM-INTERVAL 300 seconds. ZLE-MIN-INTERVAL 300 seconds. 6 Security Considerations MZAP does not include authentication in its messages. Thus it is open to misbehaving hosts sending spoof ZAM or ZCM messages. In the case of ZCM messages, these spoof messages can cause false logging of convexity problems. It is likely that is would be purely an annoyance, and not cause any significant problem. In the case of ZAM messages, spoof messages can also cause false logging of configuration problems. This is also considered to not be a significant problem. Spoof zone announcements however might cause applications to believe that a scope zone exists when it does not. If these were believed, then applications may choose to use this non-existent admin scope zone for their uses. Such applications would be able to communicate successfully, but would be unaware that their traffic may be traveling further than they expected. As a result, applications MUST only take scope names as a guideline, and SHOULD assume that their traffic sent to non-local scope zones might travel anywhere. The confidentiality of such traffic CANNOT be assumed from the fact that it was sent to a scoped address that was discovered using MZAP. 7 Bibliography [1] D. Meyer, "Administratively Scoped IP Multicast", Internet Draft, draft-ietf-mboned-admin-ip-space-04.txt [2] M. Handley, D. Thaler, D. Estrin, "The Internet Multicast Address Allocation Architecture", Internet Draft, Dec 1997. M. Handley [Page 10]
