--- 1/draft-ietf-mboned-mzap-00.txt 2006-02-05 00:20:37.000000000 +0100 +++ 2/draft-ietf-mboned-mzap-01.txt 2006-02-05 00:20:37.000000000 +0100 @@ -1,446 +1,755 @@ -Internet Engineering Task Force MboneD WG -Internet Draft M. Handley -draft-ietf-mboned-mzap-00.txt ISI -December 15, 1997 -Expires: June 1998 +MBoneD Working Group Mark Handley +Internet Engineering Task Force ISI +INTERNET-DRAFT Dave Thaler +3 August 1998 Microsoft +Expires February 1999 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. + Status of this Memo - 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''. +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. - 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). +Internet Drafts are 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 a "work in progress". - Distribution of this document is unlimited. +Abstract - 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. - 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. +Copyright Notice -1 Status +Copyright (C) The Internet Society (1998). All Rights Reserved. - This is a strawman proposal. It has not been subject to any peer - review or implementation. +Draft MZAP August 1998 -2 Introduction +1. Introduction - IP Multicast groups can be global scope, or they can be restricted in +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 [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 +administrative scoping, as defined in RFC 2365 [1]. An administrative +scope zone is defined by a set of routers surrounding 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. +Administrative scope zones may be of any size, and a particular host may +be within many administrative scope zones of various sizes. The only +zones a host can assume that it is within are the global zone, and a +"Local Scope". A 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. RFC 2365 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." +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 - the zone) or to leak (one or more border routers was not - configured correctly). +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 were not configured 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 hence reduced the incentive to deploy them. + relevant to them. This makes it difficult to use admin scope zones, + and hence reduces 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 +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. + +The 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 the local scope zone, as defined in [1]. +MUST also be a border for the Local Scope zone, as defined in [1]. - 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 +Routers SHOULD be configured so that the router itself is within the +scope zone. This is should in figure 1(a), where router A 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. +first router outside the scope zone to be configured with the border, as +illustrated in figure 1(b) where routers B and C 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 + . . +B+--> . *B+--> + . . / . /. + . * . + . + . <---+A*---+C+-> . <---+A+---*C+-> + . + . . + . . / . . / . . zone X <-- . . zone X <-- . .............. .................. - O - router * - border interface + - interface + A,B,C - routers * - border interface + - interface - A. Correct zone border B. Incorrect zone border + (a) Correct zone border (b) Incorrect zone border - Figure 1: Correct admin scope zone border placement + Figure 1: Admin scope zone border placement - This rule does not apply for local scope borders, but applies for all +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. +Draft MZAP August 1998 - 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. +When a ZBR 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. - 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. +Such a ZBR should then send periodic Zone Announcement Messages (ZAMs) +for the zone for which it is configured as a border from one of its +interfaces that go into that scope zone. These messages are multicast +to the address [MZAP-LOCAL-GROUP] in the Local Scope. - 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. +Each ZBR also listens for messages from other ZBRs for the same border. +The ZBR 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 first multicast address in +the scoped range serve to uniquely identify the scope zone. - in +When a ZBR receives a ZAM for some scope zone: - Figure 2: ZAM Message Flooding +o If the ZAM was received on an interface with a boundary for the given + scope, the ZAM is not forwarded. For example, router D in figure 2 + will not forward the ZAM. - 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. +o If the ZAM was received on an interface which is NOT a Local Scope + boundary, and the last Local Zone ID Address in the path list is 0, + the ZBR fills in the Local Zone ID Address of the local zone from + which the ZAM was received. - 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. +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. - in +o Otherwise, the ZAM is cached for at least [ZAM-DUP-TIME] seconds. - Figure 3: ZAM Message Flooding +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 a non-null path list MUST NOT forward that ZAM back into a Local + Scope zone that is contained in the path list. For example, in + figure 2, router F, which did not get the ZAM via A due to packet + loss, will not forward the ZAM from B back into Zone 2 since the path + list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears. -3.1 Packet Formats +Draft MZAP August 1998 - Zone Announcement Message (IPv4) +o In addition, the ZBR re-originates the ZAM out each interface with a + Local Scope boundary (except that it is not sent back out the + interface over which it was received), with its own IP address added + to the path list, as well as the Zone ID Address of the Local Scope + Zone into which the ZAM 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.) - The format of a Zone Announcement Message is shown in figure 4. + ########################### + # 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 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. + +Additional messages called Zone Convexity Messages (ZCMs) SHOULD also be +sent to 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, nor any special +processing by Local Scope zone ZBRs. These messages are used to detect +non-convex admin scope zones, as illustrated in figure 3, where the path +between B and D goes outside the scope (through A and E). Here Router B +and Router C originates ZCMs, each reporting each other's presence. +Router D cannot see Router B's messages, but can see C's report of B, +and so can conclude the zone is not convex. + +Draft 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: Non-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. Zone IDs + +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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | V=0 |R| PTYPE | ZT | ZTL | IP | MLEN | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Zone Base Address | +| Version | PTYPE |Address Family | NameLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Origin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone ID Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local Zone ID Address 0 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Router Address 0 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ..... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local Zone ID Address N | +| Zone Start Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Router Address N | +| Zone End Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Name | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 4: Zone Announcement Message Format ++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | Padding (if needed) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +Version: + The version defined in this document is version 0. - The fields are defined as follows: +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) - Version (V): 3 bits The version defined in this document is version - 0. +Address Family: + This indicates the format of the following packet. The following + values are defined by this document: + 0: IPv4 + 1: IPv6 - 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. +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. - Packet Type (PTYPE): 4 bits A Zone Announcement Message has PTYPE=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. - Zone Traveled (ZT): 8 bits This gives the number of Local Zone IDs - contained in this message path. +Message Origin: 32 bits (IPv4) or 128 bits (IPv6) + This gives the IP address of the interface that originated the + message. - 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. +Draft MZAP August 1998 - IP Protocol Version (IP): 3 bits This indicates the format of the - following packet. The following values are defined: +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. - 0: IPv4 +Name Len: + The length, in bytes, of the Zone Name field. - 1: IPv6 +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. - 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. +Padding (if needed): + The MZAP header is padded with null bytes until it is 4-byte aligned. - 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. +3.7.1. Zone Announcement Message - Message Origin: 32 bits This gives the IP address of the interface - that originated the ZAM 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: - 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. +o the Global Scope - 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. +o the Local Scope - 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. +o the Link-local scope -3.1.1 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. 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 of a Zone Announcement Message is shown below: - The format is the same as a ZAM message, and is shown in figure 5: +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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | V=0 | PTYPE | ZT | ZTL | IP | MLEN | + MZAP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Zone Base Address | +| ZT | ZTL | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Message Origin | +| Local Zone ID Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Zone ID Address | +| Router Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local Zone ID Address 0 | +| Local Zone ID Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Router Address N | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Zone Name | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Authentication Block (optional) ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 5: Zone Announcement Message Format +The fields are defined as follows: +Zones Traveled (ZT): 8 bits + This gives the number of Local Zone IDs contained in this message + path. - All fields are copied from the ZAM message, except PTYPE which is set - to one. +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. A value of 0 indicates that no + limit exists. - A router receiving ZLE messages SHOULD log them and attempt to alert - the network administrator that the scope zone is misconfigured. +Hold Time: + The time, in seconds, after which the receiver may assume the scope + no longer exists, if no subsequent ZAM is received. This should be + set to [ZAM-HOLDTIME]. - Zone Convexity Message +Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) + The zone path is a list of Local Zone ID Addresses (the Zone ID + Address of a local zone) through which the ZAM has passed, and IP + addresses of the router that forwarded the packet. The origin router + fills in the "Local Zone ID Address 0" field when sending the ZAM. + 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 of the zone into which the message is being forwarded, and - 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 - ZCM is shown in figure 6 and is similar to a ZAM, expect PTYPE take - the value two. +Draft MZAP August 1998 + + its own IP address to the end of this list, and increment ZT + accordingly. The zone path is empty which the ZAM is first sent. + +Authentication Block: + If present, this provides information which can be used to + authenticate the sender of the ZAM (i.e. Router Address N, if ZT is + non-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 only scheduled if at least [ZLE-MIN- +INTERVAL] seconds have elapsed since it previously sent a ZLE to any +destination. To schedule a ZLE, the router sets a random delay timer +within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the +[MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any +are received before the random delay timer expires, the timer is cleared +and the ZLE is not sent. If the timer expires, the router sends a ZLE +to the [MZAP-RELATIVE-GROUP] within the indicated scope. + +The method used to choose a random delay (T) is as follows: + Choose a random value X from the uniform random interval [0:1] + Let C = 256 + Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) +This method ensures that close to one ZBR will respond. +The format of a 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | V=0 | PTYPE | ZNUM | unused | IP | MLEN | + MZAP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Zone Base Address | +| ZT | ZTL | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Message Origin | +| Local Zone ID Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Zone ID Address | +| Router Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ZBR Address 0 | +| Local Zone ID Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... + +Draft MZAP August 1998 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ZBR Address N | +| Router Address N | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Local Zone ID Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Zone Name | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 6: Zone Convexity Message Format +All fields are copied from the ZAM, except PTYPE which is set to one. - The fields are as follows: +A router receiving ZLE messages SHOULD log them and attempt to alert the +network administrator that the scope zone is misconfigured. - Number of ZBR addresses (ZNUM): 8 bits This field gives the number of - ZBR Addresses contained in this message. +3.7.3. Zone Convexity 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. +A Zone Announcement Message has PTYPE=2, and is periodically sent by a +ZBR for each scope for which it is a border, EXCEPT: -4 Using Zone Announcement Messages +o the Global Scope - 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[2], which in turn will listen to Zone - Announcement Messages. +o the Link-local scope +(Note that ZCM's ARE sent in the Local Scope.) - A ZBR can discover misconfiguration of scope boundaries in one of - several ways: +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 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| ZNUM | unused | Hold Time | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| ZBR Address 1 | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ..... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| ZBR Address N | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - o It receives ZLE messages indicating that the scope zone is - leaking. +The fields are as follows: +Number of ZBR addresses (ZNUM): 8 bits + This field gives the number of ZBR Addresses contained in this + message. +Hold Time: + The time, in seconds, after which the receiver may assume the sender - 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. +Draft MZAP August 1998 - 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. + is no longer reachable, if no subsequent ZCM is received. This + should be set to [ZCM-HOLDTIME]. - in +ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) + These fields give the addresses of the other ZBRs from which the + Message Origin ZBR has received ZCMs but whose hold time has not + expired. The router should include all such addresses which fit in + the packet, preferring those which it has not included recently if + all do not fit. - Figure 7: ZAM Message Leaking +4. Message Timing - All these conditions should be considered errors and the router - should attempt to alert the network administrator to the nature of - the misconfiguration. +Each ZBR 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. - 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. +Each ZBR 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. -5 Message Timing +A router SHOULD NOT send more than one Zone Limit Exceeded message every +[ZLE-MIN-INTERVAL] regardless of destination. - 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. +5. Constants - 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. +[MZAP-PORT]: The well-known UDP port to which all MZAP messages are +sent. Value: TBD by IANA. - A router SHOULD NOT send more than one Zone Limit Exceeded message - every ZLE-MIN-INTERVAL regardless of destination. +[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. - Default values are: +[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 300 seconds. +[ZAM-INTERVAL]: The interval at which a Zone Border Router originates +Zone Announcement Messages. Default value: 600 seconds (10 minutes). - ZCM-INTERVAL 300 seconds. +[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). - ZLE-MIN-INTERVAL 300 seconds. +Draft MZAP August 1998 -6 Security Considerations +[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]: 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: 300 seconds (5 +minutes). + +[ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, +regardless of destination. Default value: 300 seconds (5 minutes). + +6. Security Considerations MZAP does not include authentication in its messages. Thus it is open - to misbehaving hosts sending spoof ZAM or ZCM messages. +to misbehaving hosts sending spoof ZAMs or ZCMs. - 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 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 of ZAM messages, spoof messages can also cause false - logging of configuration problems. This is also considered to not be - a significant problem. +In the case of 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 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. +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 +In addition, ZAMs are used to inform Multicast Address Allocation +Servers of names of scopes, and spoofed ZAMs would result in false names - [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. +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 be configured with the public key of the local zone + in which it resides. 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] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July + 1998. + +[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + +[3] Handley, 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