MBoneD Working Group Mark Handley Internet Engineering Task ForceMboneD WG Internet Draft M. Handley draft-ietf-mboned-mzap-00.txtISIDecember 15, 1997 Expires: JuneINTERNET-DRAFT Dave Thaler 3 August 1998 Microsoft Expires February 1999 Multicast-Scope Zone Announcement Protocol (MZAP)STATUS OF THIS MEMO<draft-ietf-mboned-mzap-01.txt> Status of this Memo This document is anInternet-Draft. Internet-DraftsInternet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), itsareas,Areas, and itsworking groups.Working Groups. Note that other groups may also distribute working documents asInternet-Drafts. Internet-DraftsInternet Drafts. Internet Drafts aredraft documentsvalid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to useInternet-DraftsInternet 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 containeda "work inthe 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. ABSTRACTprogress". 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. 2Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Draft MZAP August 1998 1. Introduction IP Multicast groups can be of global scope, or they can be restricted in scope using a scoping mechanism. In this document, we only consider administrative scoping, as defined in RFC 2365 [1]. An administrative scope zone is defined by a set ofborderrouterstosurrounding a region of the network. Theseborder routers"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 scopezones.zones of various sizes. The only zones a host can assume that it is within are the global zone, andlocal scopea "Local Scope". A LocalscopeScope 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]RFC 2365 specifies:239.255.0.0/16"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 ownlocal scope.Local Scope. This implies that any scope boundary is also a boundary for the LocalScope.Scope." as well as: "administrative scopes that intersect topologically should not intersect in address range." 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 thezone)zone), or to leak (one or more border routerswaswere not configuredcorrectly).correctly), or to intersect in both area and address range. 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 hencereducedreduces the incentive to deploy them. This document defines the Multicast Scope Zone Announcement Protocol Draft MZAP August 1998 (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 SpecificationThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in section 5. 2. Overview 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 thelocal scopeLocal Scope zone, as defined in [1]. Routers SHOULD be configured soasthat the router itself is within the scope zone. This is should in figure1A,1(a), where router1A 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 figure1B1(b) where routers2B and3C are outside the zone and have the border configuration, but this is NOT RECOMMENDED. ............ ................ . .+O+-->+B+--> .*O+-->*B+--> . . /2. /.2.1* .1+ . .<---+O*---+O+-><---+A*---+C+-> .<---+O+---*O+-><---+A+---*C+-> . + .3. + .3. / . . / . . zone X <-- . . zone X <-- . .............. ..................OA,B,C -routerrouters * - border interface + - interfaceA.(a) Correct zone borderB.(b) Incorrect zone border Figure 1:Correct adminAdmin scope zone border placement This rule does not apply forlocal scopeLocal Scope borders, but applies for all other admin scope border routers. Draft MZAP August 1998 When a ZBRrouteris 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 ZBRroutershould then send periodic Zone Announcement Messages (ZAMs) for the zone for which it is configured as a border fromeachone of its interfaces that go into that scope zone. These messages are multicast to the address239.255.255.254, which is a locally scoped address.[MZAP-LOCAL-GROUP] in the Local Scope. Each ZBRrouter shouldalsolistenlistens forZAMmessages from other ZBRs for the same border. The ZBRrouterwith 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 thebasefirst multicast addressofin thescopingscoped rangeserverserve to uniquely identify the scope zone.Every local scopeWhen a ZBRthatreceivesanya ZAM fora scope zone other than localsome scopeSHOULD then forwardzone: o If the ZAMout of all the other interfaces that are in different local scope zones except ones that formwas received on an interface with aborderboundary for thezone describedgiven scope, the ZAM is not forwarded. For example, router D in figure 2 will not forward the ZAM.It adds the zone-id ofo If thelocal scope zone thatZAM was received on an interface which is NOT a Local Scope boundary, and themessage came from tolast Local Zone ID Address in theZAMpath listbefore doing so. Ais 0, the ZBR fills in the Local Zone ID Address of the local zone from which the ZAM was received. o If a ZAM for the same scope (as identified by the origin Zone ID and first multicast address) was received in the last [ZAM-DUP-TIME] seconds, the ZAM is not forwarded. For example, when router C in figure 2 receives the ZAM via B, it will not be forwarded, since it has just forwarded the ZAM from E. o Otherwise, the ZAM is cached for at least [ZAM-DUP-TIME] seconds. o If the Zone ID of the Local Scope zone in which the ZBR resides is not already in the ZAM's path list, then the ZAM is immediately re- originated within the Local Scope zone. It adds its own address and the zone-id of the Local Scope zone into which the message is being forwarded to the ZAM path list before doing so. A ZBR receiving a ZAM with anon- nullnon-null path list MUST NOT forward that ZAM back into alocal scopeLocal Scope zone that is contained in the path list.This process is illustratedFor example, in figure2. in Figure 2:2, router F, which did not get the ZAMMessage Flooding Thevia A due to packetalso contains a Zones Traveled Limit. Ifloss, will not forward thenumber of LocalZAM from B back into ZoneIDs in2 since theZAMpathbecomes equal tolist has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears. Draft MZAP August 1998 o In addition, theZones Traveled Limit,ZBR re-originates thepacket should be dropped. Zones Traveled LimitZAM out each interface with a Local Scope boundary (except that it isset whennot sent back out thepacket is first sent, and defaults to 32, but can be setinterface over which it was received), with its own IP address added toa lower value if a network administrator knowstheexpected size ofpath list, as well as thezone. Addition messages calledZoneConvexity Messages (ZCM) SHOULD also be sent toID Address of thesecond highest address inLocal Scope Zone into which thescope zone range itselfZAM is being sent, or 0 if the ID is unknown. (For example, if the other end of a point-to-point link also has a boundary on the interface, then the link has no Local Scope Zone ID.) ########################### # Zone1 = Zone2 # ##### = large scope zone border *E-----+--->A*-----+-x # # | = v # ===== = Local Scope boundaries # | ======*===*==# # | = B F # ----> = path of ZAM origined by E # +--->C*-> | ^ # # v = <-+---+ # ABCDE = ZBRs # D = Zone3 # #######*################### * = border interface Figure 2: ZAM Flooding Example 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 isfor 239.1.0.0set when the packet is first sent, and defaults to239.1.0.255, then these32, but can be set to a lower value if a network administrator knows the expected size of the zone. Additional messagesshouldcalled Zone Convexity Messages (ZCMs) SHOULD also be sent to239.1.0.254.)the [ZCM-RELATIVE-GROUP] in the scoped range itself. 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 forwardingnor any special processing bylocal scopeLocal Scope zone ZBRs. These messages are used to detect non-convex admin scope zones, as illustrated in figure3.3, where the path between B and D goes outside the scope (through A and E). Here Router B and Router C originatesZCM messages,ZCMs, each reporting each other's presence. Router D cannot see Router B's messages, butsees Routercan see C's report ofRouterB, and soconcludescan conclude the zone is not convex.inDraft MZAP August 1998 #####*####======== # B # = ##### = non-convex scope boundary # |->A* = # | # = ===== = other scope boundaries # | ####*#### # | E # ----> = path of B's ZAM # v D* # C # * = border interface #####*############ Figure 3:ZAM Message Flooding 3.1 Packet Formats Zone Announcement Message (IPv4) The formatNon-convexity detection 3. Usage In this section, we summarize how to inform internal entities of scopes in which they reside, as well as how to detect various error conditions. If any error is detected, the router should attempt to alert a network administrator to the nature of the misconfiguration. The means to do this lies outside the scope of MZAP. 3.1. ZoneAnnouncement Message is shown in figure 4. 0 1 2IDs When a border router first starts up, it uses its lowest IP address which it considers to be inside a given zone as the Zone ID for that zone, and schedules the ZCM and ZAM messages to be sent in the future (it does not send them immedately). When a ZAM or ZCM is received for the given scope, the sender is added to the local list of ZBRs (including itself) for that scope, and the Zone ID is updated to be the lowest IP address in the list. Entries in the list are eventually timed out if no further messages are received from that ZBR, such that the Zone ID will converge to the lowest address of any active ZBR for the scope. 3.2. Informing internal entities of scopes 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 information. These applications will normally query a local Multicast Address Allocation Server [3], which in turn listens to Zone Announcement Messages to Draft MZAP August 1998 maintain a list of scopes. 3.3. Detecting non-convex scope zones Non-convex scope zones can be detected via two methods: (1) If a ZBR is listed in ZCMs received, but the next-hop interface (according to the multicast RIB) towards that ZBR is outside the scope zone, or (2) If a ZBR is listed in ZCMs received, but no ZCM is received from that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in figure 3. Zone Convexity Messages MAY 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. 3.4. Detecting leaky boundaries for non-local scopes Leaky scope boundaries can be detected via two methods: (1) If it receives ZAMs 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 4. =============#####*######## = Zone1 # A Zone2 # C = misconfigured router = +---->*E v # = | # B # ##### = leaky scope boundary =======*=====#====*=======# = D # | # ===== = other scope boundaries = ^-----*C<--+ # = Zone4 # Zone3 # ----> = path of ZAMs =============############## Figure 4: ZAM Leaking (2) If a ZLE message is received. In either case, the misconfigured router will be one of the routers in the path list included in the message received. Draft MZAP August 1998 3.5. Detecting a leaky Local Scope zone A local scope is leaky if a router has an admin scope boundary on some interface, but does not have a Local Scope boundary on that interface as specified in RFC 2365. This can be detected via the following method: o If a ZAM for a given scope is received by a ZBR which is a border for that scope, it compares the Origin's Scope Zone ID in the ZAM with its own Zone ID for the given scope. If the two do not match, this is evidence of a misconfiguration. Since a temporary mismatch may result immediately after a recent change in the reachability of the lowest-addressed ZBR, misconfiguration should be assumed only if the mismatch is persistent. The exact location of the problem can be found by doing an mtrace [5] from the router detecting the problem, back to the ZAM origin, for any group within the address range identified by the ZAM. The router at fault will be the one reporting that a boundary was reached. 3.6. Detecting conflicting scope zones Conflicting address ranges can be detected via the following method: o If a ZBR receives a ZAM for a given scope, and the included start and end addresses overlap with, but are not identical to, the start and end addresses of a locally-configured scope. Conflicting scope names can be detected via the following method: o If a ZBR is configured with a non-empty scope name for a given scope, and it receives a ZAM with a non-empty scope name for the same scope, and the scope names do not match. Detecting either type of conflict above indicates that either the local router or router originating the message is misconfigured. 3.7. Packet Formats All MZAP messages are sent over UDP, with a destination port of [MZAP- PORT]. The common MZAP message header (which follows the UDP header), is show below: Draft MZAP August 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | PTYPE |Address Family | NameLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Origin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone ID Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Start Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone End Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Name | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (if needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: The version defined in this document is version 0. Packet Type (PTYPE): The packet types defined in this document are: 0: Zone Announcement Message (ZAM) 1: Zone Limit Exceeded (ZLE) 2: Zone Convexity Message (ZCM) Address Family: This indicates the format of the following packet. The following values are defined by this document: 0: IPv4 1: IPv6 Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the start 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 Start Address is 239.1.0.0. Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the ending 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 End Address is 239.1.0.255. Message Origin: 32 bits (IPv4) or 128 bits (IPv6) This gives the IP address of the interface that originated the message. Draft MZAP August 1998 Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the lowest IP address of a boundary router that has been observed in the zone originating the message. Together with Zone Start Address and Zone End Address, it forms a unique ID for the zone. Note that this ID is NOT the ID of the Local Scope zone in which the origin resides. Name Len: The length, in bytes, of the Zone Name field. Zone Name: multiple of 8 bits The Zone Name is an ISO 10646 character string in UTF-8 encoding [4] indicating the name given to the scope zone (eg: ``ISI-West Site''). It should be relatively short and MUST be less than 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 ZBRs for a scope zone announce zero length names should be considered an error. Padding (if needed): The MZAP header is padded with null bytes until it is 4-byte aligned. 3.7.1. Zone Announcement Message A Zone Announcement Message has PTYPE=0, and is periodically sent by a ZBR for each scope for which it is a border, EXCEPT: o the Global Scope o the Local Scope o the Link-local scope The format of a Zone Announcement Message is shown below: Draft MZAP August 1998 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 89 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 |R| PTYPE | ZT | ZTL | IP | MLEN |9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Zone Base Address |MZAP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Message OriginZT |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ZTL |Zone ID AddressHold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Local Zone ID AddressN1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 ofLocal ZoneIDs 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 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 BaseID Addressis 239.1.0.0. Message Origin: 32N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication Block (optional) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are defined as follows: Zones Traveled (ZT): 8 bits This gives theIP addressnumber ofthe interface that originated the ZAM message.Local ZoneID Address: 32IDs contained in this message path. Zones Traveled Limit (ZTL): 8 bits This gives thelowest IP addresslimit on number of local zones thathas been observed inthezone sending ZAM messages. Together with Zone Base Address and MLENpacket can traverse before itforms a unique ID forMUST be dropped. A value of 0 indicates that no limit exists. Hold Time: The time, in seconds, after which thezone.receiver may assume the scope no longer exists, if no subsequent ZAM is received. This should be set to [ZAM-HOLDTIME]. Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) The zone path is a list of32 bitLocal Zone ID Addresses (the Zone ID Address of a local zone) through which the ZAMmessagehas passed, and32 bitIP addresses of the router that forwarded the packet. The origin router fills in the "Local Zone ID Address 0" field when sending the ZAM. Everylocal scopeLocal Scope router that forwards the ZAM across alocal scopeLocal Scope boundary MUST add the Local Zone ID Address of the local zone that the packetwas received fromof the zone into which the message is being forwarded, and Draft MZAP August 1998 its own IP address to the end of this list, andincrementsincrement ZT accordingly. The zone path is empty which the ZAMmessageis 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 MUSTAuthentication Block: If present, this provides information which can beless that 256 bytes in length. All the border routersused to authenticate thesame region SHOULD be configured to givesender of thesame Zone Name, or a zero length string MAY be given. A zero length string is taken to mean that another routerZAM (i.e. Router Address N, if ZT isexpected 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.1non-zero, or Message Origin, if ZT is zero). (TBD: any reason not to re-use SAP's "Authentication Header" here?) 3.7.2. Zone Limit Exceeded (ZLE) 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. To avoid ZLE implosion, ZLEs are multicast with a random delay and suppressed by other ZLEs. It is onlysentscheduled if at least [ZLE-MIN- INTERVAL] seconds have elapsed since it previously sent a ZLE to any destination. To schedule a ZLE, the"Respond" bit inrouter sets a random delay timer within theZAM packet is set,interval [ZLE-SUPPRESSION-INTERVAL], andit is unicastlistens to theMessage Origin given in[MZAP-RELATIVE-GROUP] within theZAM packet. The format isincluded scope for other ZLEs. If any are received before thesame as a ZAM message, andrandom delay timer expires, the timer isshown 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 fromcleared and theZAM message, except PTYPE whichZLE isset to one. Anot sent. If the timer expires, the routerreceivingsends a ZLEmessages SHOULD log them and attempttoalertthenetwork administrator that[MZAP-RELATIVE-GROUP] within thescope zone is misconfigured. Zone Convexity Message Unlike Zone Announcement Messages which are sentindicated scope. The method used to choose a random delay (T) is as follows: Choose a random value X from thelocally scoped address 239.255.255.254, Zone Convexity Messages are sentuniform random interval [0:1] Let C = 256 Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) This method ensures that close tothe second highest address in the scope zone itself.one ZBR will respond. The format of aZCM is shown in figure 6 and is similar to a ZAM, expect PTYPE take the value two.ZLE is shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MZAP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0 | PTYPEZT |ZNUMZTL | unused |IP | MLEN |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ZoneBaseID Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Message OriginRouter Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBR Address 01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... Draft MZAP August 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ZBRRouter Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ZoneName | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ID Address N |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Zone Convexity Message Format The+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields areas 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 messagescopied fromduring 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 nottherecommended method for regular applications to discover this information. These applications will normally query a local Multicast Address Allocation Server[2],ZAM, except PTYPE whichin turn will listenis set toZone Announcement Messages.one. AZBR can discover misconfiguration of scope boundaries in one of several ways: o It receivesrouter receiving ZLE messagesindicating 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,SHOULD log them andflooded back around behindattempt to alert theboundary. This is illustrated in figure 7. o Other ZBR routers innetwork administrator that the scope zoneare announcing that they are seeing a different set of routers than our router observes from arriving ZCM messages. If thisis misconfigured. 3.7.3. Zone Convexity Message A Zone Announcement Message has PTYPE=2, and is periodically sent by apersistent condition,ZBR for each scope for which itindicatesis a border, EXCEPT: o the Global Scope o the Link-local scope (Note that ZCM's ARE sent in the Local Scope.) Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL- GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP] in the scope zone itself. The format of a ZCM isprobably not convex,shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MZAP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZNUM | unused | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBR Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBR Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are asillustratedfollows: Number of ZBR addresses (ZNUM): 8 bits This field gives the number of ZBR Addresses contained infigure 3.this message. Hold Time: The time, inFigure 7: ZAM Message Leaking All these conditions should be considered errors andseconds, after which therouter should attempt to alertreceiver may assume thenetwork administratorsender Draft MZAP August 1998 is no longer reachable, if no subsequent ZCM is received. This should be set to [ZCM-HOLDTIME]. ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) These fields give thenatureaddresses of themisconfiguration. Zone Convexity Messages can also be sent andother ZBRs from which the Message Origin ZBR has receivedby correctly configured ordinary hosts within a scope region,ZCMs but whose hold time has not expired. The router should include all such addresses whichmay be a useful diagnostic facility that doesfit in the packet, preferring those which it has notrequire privileged access. 5included recently if all do not fit. 4. Message Timing Each ZBRroutershould send a Zone Announcement Message for each scope zone for which it is a boundary everyZAM-INTERVAL[ZAM-INTERVAL] seconds, +/- 30% ofZAM-INTERVAL[ZAM- INTERVAL] each time to avoid message synchronisation. Each ZBRroutershould send a Zone Convexity Message for each scope zone for which it is a boundary everyZCM-INTERVAL[ZCM-INTERVAL] seconds, +/- 30% ofZCM-INTERVAL[ZCM- INTERVAL] each time to avoid message synchronisation. A router SHOULD NOT send more than one Zone Limit Exceeded message everyZLE-MIN-INTERVAL[ZLE-MIN-INTERVAL] regardless of destination. 5. Constants [MZAP-PORT]: The well-known UDP port to which all MZAP messages are sent. Value: TBD by IANA. [MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which ZAMs are sent. All Multicast Address Allocation servers and Zone Border Routers listen to this group. Value: TBD by IANA. [ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which ZCMs are sent. A Zone Border Router listens to the relative group in each scope for which it is a border. Value: TBD by IANA. [ZAM-INTERVAL]: The interval at which a Zone Border Router originates Zone Announcement Messages. Defaultvalues are: ZAM-INTERVAL 300value: 600 seconds (10 minutes). [ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31 minutes). Draft MZAP August 1998 [ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which ZAMs for the same scope will not be forwarded. Default value: 30 seconds.ZCM-INTERVAL[ZCM-INTERVAL]: The interval at which a Zone Border Router originates Zone Convexity Messages. Default value: 600 seconds (10 minutes). [ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31 minutes). [ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random delay before sending a ZLE message. Default value: 300seconds. ZLE-MIN-INTERVALseconds (5 minutes). [ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, regardless of destination. Default value: 300seconds. 6seconds (5 minutes). 6. Security Considerations MZAP does not include authentication in its messages. Thus it is open to misbehaving hosts sending spoofZAMZAMs orZCM messages.ZCMs. In the case ofZCM messages,ZCMs, 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 ofZAM messages,ZAMs, 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 SHOULDassume that their traffic sent to non-local scope zones might travel anywhere. The confidentiality of such traffic CANNOTassume 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. In addition, ZAMs are used to inform Multicast Address Allocation Servers of names of scopes, and spoofed ZAMs would result in false names Draft MZAP August 1998 being presented to users. To counter this, ZAMs may be authenticated as follows: (1) A ZBR signs all ZAMs it originates. (2) A ZBR signs a ZAM it forwards if and only if it can authenticate the previous sender. A ZBR MUST still forward un-authenticated ZAMs (to provide leak detection), but should propagate an autheticated ZAM even if an un-authenticated one was received with the last [ZAM-DUP-TIME] seconds. (3) A MAAS SHOULD beassumed fromconfigured with thefact thatpublic key of the local zone in which itwas sent to a scoped address that was discovered using MZAP. 7 Bibliographyresides. A MAAS thus configured SHOULD ignore an unauthenticated ZAM if an authenticated one for the same scope has been received, and MAY ignore all unauthenticated ZAMs. 7. References [1]D.Meyer, D., "Administratively Scoped IP Multicast",Internet Draft, draft-ietf-mboned-admin-ip-space-04.txtRFC 2365, July 1998. [2]M.Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] Handley,D.M., Thaler, D., and D. Estrin, "The Internet Multicast Address Allocation Architecture", Internet Draft, Dec 1997. [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft, November 1997. 8. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included Draft MZAP August 1998 on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Table of Contents 1 Introduction .................................................... 2 2 Overview ........................................................ 3 3 Usage ........................................................... 6 3.1 Zone IDs ...................................................... 6 3.2 Informing internal entities of scopes ......................... 6 3.3 Detecting non-convex scope zones .............................. 7 3.4 Detecting leaky boundaries for non-local scopes ............... 7 3.5 Detecting a leaky Local Scope zone ............................ 8 3.6 Detecting conflicting scope zones ............................. 8 3.7 Packet Formats ................................................ 8 3.7.1 Zone Announcement Message ................................... 10 3.7.2 Zone Limit Exceeded (ZLE) ................................... 12 3.7.3 Zone Convexity Message ...................................... 13 4 Message Timing .................................................. 14 5 Constants ....................................................... 14 6 Security Considerations ......................................... 15 7 References ...................................................... 16 8 Full Copyright Statement ........................................ 16