--- 1/draft-ietf-mboned-mzap-03.txt 2006-02-05 00:20:43.000000000 +0100 +++ 2/draft-ietf-mboned-mzap-04.txt 2006-02-05 00:20:43.000000000 +0100 @@ -1,467 +1,473 @@ - MBoneD Working Group Mark Handley -Internet Engineering Task Force ISI +Internet Engineering Task Force AT&T INTERNET-DRAFT Dave Thaler -17 February 1999 Microsoft -Expires August 1999 Roger Kermode +22 June 1999 Microsoft +Expires December 1999 Roger Kermode Motorola Multicast-Scope Zone Announcement Protocol (MZAP) - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 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". +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt -To view the list Internet-Draft Shadow Directories, see -http://www.ietf.org/shadow.html. - -Abstract +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html.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 +mechanisms whereby common misconfigurations of administrative scope zones can be discovered. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. -Draft MZAP February 1998 +Draft MZAP June 1999 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 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. +The use of administratively-scoped IP multicast, as defined in RFC 2365 +[1], allows packets to be addressed to a specific range of multicast +addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the +packets will not cross configured administrative boundaries, and also +allows such addresses to be locally assigned and hence are not required +to be unique across administrative boundaries. This property of logical +naming both allows for address reuse, as well as provides the capability +for infrastructure services such as address allocation, session +advertisement, and service location to use well-known addresses which +are guaranteed to have local significance within every organization. + +The range of administratively-scoped addresses can be subdivided by +administrators so that multiple levels of administrative boundaries can +be simultaneously supported. As a result, a "multicast scope" is +defined as a particular range of addresses which has been given some +topological meaning. + +To support such usage, a router at an administrative boundary is +configured with one or more per-interface filters, or "multicast scope +boundaries". Having such a boundary on an interface means that it will +not forward packets matching a configured range of multicast addresses +in either direction on the interface. + +A specific area of the network topology which is within a boundary for a +given scope is known as a "multicast scope zone". Since the same ranges +can be reused within disjoint areas of the network, there may be many +"multicast scope zones" for any given multicast scope. A scope zone may +have zero or more textual names (in different languages) for the scope, +for human convenience. For example, if the range 239.192/14 were +assigned to span an entire corporate network, it might be given +(internally) the name "BigCo Private 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." +be within many administrative scope zones (for different scopes, i.e., +for non-overlapping ranges of addresses) of various sizes, as long as +scope zones that intersect topologically do not intersect in address +range. -Two problems make administrative scoping difficult to deploy and -difficult to use: +Applications and services are interested in various aspects of the +scopes within which they reside: + +o Applications which present users with a choice of which scope in + which to operate (e.g., when creating a new session, whether it is + +Draft MZAP June 1999 + + to be confined to a corporate intranet, or whether it should go out + over the public Internet) are interested in the textual names which + have significance to users. + +o Services which use "relative" multicast addresses (as defined in + [1]) in every scope are interested in the range of addresses used + by each scope, so that they can apply a constant offset and compute + which address to use in each scope. + +o Address allocators are interested in the address range, and whether + they are allowed to allocate addresses within the entire range or + not. + +o Some applications and services may also be interested in the + nesting relationships among scopes. For example, knowledge of the + nesting relationships can be used to perform "expanding-scope" + searches in a similar, but better behaved, manner to the well-known + expanding ring search where the TTL of a query is steadily + increased until a replier can be found. Studies have also shown + that nested scopes can be useful in localizing multicast repair + traffic [8]. + +Two barriers currently make administrative scoping difficult to deploy +and use: + +o Applications have no way to dynamically discover information on + scopes that are relevant to them. This makes it difficult to use + administrative scope zones, and hence reduces the incentive to deploy + them. 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 + leak (one or more boundary 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 administrative - scope zones, and hence reduces the incentive to deploy them. - -Draft MZAP February 1998 - - 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. +These two barriers are addressed by this document. In particular, this +document defines the Multicast Scope Zone Announcement Protocol (MZAP) +which allows an entity to learn what scope zones it is within. +Typically servers will cache the information learned from MZAP and can +then provide this information to applications in a timely fashion upon +request using other means, e.g., via MADCAP [9]. MZAP also provides +diagnostic information to the boundary routers themselves that enables +misconfigured scope zones to be detected. -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]. +Draft MZAP June 1999 -Constants used by this protocol are shown as [NAME-OF-CONSTANT], and -summarized in section 5. +2. Terminology -2. Overview +The "Local Scope" is defined in RFC 2365 [1] and represents the smallest +administrative scope larger than link-local, and the associated address +range is defined as 239.255.0.0 to 239.255.255.255 inclusive (for IPv4, +FF03::/16 for IPv6). 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." -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 administrative scope -zone MUST also be a border for the Local Scope zone, as defined in [1]. +A multicast scope Zone Boundary Router (ZBR) is a router that is +configured with a boundary for a particular multicast scope on one or +more of its interfaces. Any interface that is configured with a boundary +for any administrative scope zone MUST also have a boundary for the +Local Scope zone, as described above. -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 1(b) where routers B and C are outside the zone -and have the border configuration, but this is NOT RECOMMENDED. +Such routers SHOULD be configured so that the router itself is within +the scope zone. This is shown in Figure 1(a), where router A is inside +the scope zone and has the boundary configuration. ............ ................ . . +B+--> . *B+--> . . / . / . . * . + . . <---+A*---+C+-> . <---+A+---*C+-> . + . . + . . / . . / . . zone X <-- . . zone X <-- . .............. .................. - A,B,C - routers * - border interface + - interface - - (a) Correct zone border (b) Incorrect zone border - - Figure 1: Administrative scope zone border placement - -This rule does not apply for Local Scope borders, but applies for all -other administrative scope border routers. + A,B,C - routers * - boundary interface + - interface -Draft MZAP February 1998 + (a) Correct zone boundary (b) Incorrect zone boundary -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. + Figure 1: Administrative scope zone boundary placement -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. +It is possible for the first router outside the scope zone to be +configured with the boundary, as illustrated in Figure 1(b) where -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. +Draft MZAP June 1999 -When a ZBR receives a ZAM for some scope zone: +routers B and C are outside the zone and have the boundary +configuration, whereas A does not, but this is NOT RECOMMENDED. This +rule does not apply for Local Scope boundaries, but applies for all +other boundary routers. -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. +We next define the term "Zone ID" to mean the lowest IP address used by +any ZBR for a particular zone for sourcing MZAP messages into that scope +zone. The combination of this IP address and the first multicast +address in the scope range serve to uniquely identify the scope zone. +Each ZBR listens for messages from other ZBRs for the same boundary, and +can determine the Zone ID based on the source addresses seen. The Zone +ID may change over time as ZBRs come up and down. -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. +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]. -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. +Constants used by this protocol are shown as [NAME-OF-CONSTANT], and +summarized in section 7. -o Otherwise, the ZAM is cached for at least [ZAM-DUP-TIME] seconds. +3. Overview -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. +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. -Draft MZAP February 1998 +Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for +each zone for which it is configured as a boundary into that scope zone, +containing information on the scope zone's address range, Zone ID, and +textual names. These messages are multicast to the well-known address +[MZAP-LOCAL-GROUP] in the Local Scope, and are relayed across Local +Scope boundaries into all Local Scope zones within the scope zone +referred to by the ZAM message, as shown in Figure 2. -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, nor is it sent into any local - scope zone whose ID is known and appears in the path list). In each - such ZAM re-originated, the ZBR adds its own IP address 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.) +Draft MZAP June 1999 ########################### - # Zone1 = Zone2 # ##### = large scope zone border + # Zone1 = Zone2 # ##### = large scope zone boundary *E-----+--->A*-----+-x # # | = v # ===== = Local Scope boundaries # | ======*===*==# # | = B F # ----> = path of ZAM originated by E - # +--->C*-> | ^ # + G*<-----+--->C*-> | ^ # # v = <-+---+ # ABCDE = ZBRs # D = Zone3 # - #######*################### * = border interface + #######*################### * = boundary 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 administrative 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 February 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 +Any entity can thus listen on a single well-known group address and +learn about all scopes in which it resides. -2.1. Nesting +3.1. Scope Nesting MZAP also provides the ability to discover the nesting relationships between scope zones. Two zones are nested if one is comprised of a -subset of the routers in the other, as shown in Figure 4. +subset of the routers in the other, as shown in Figure 3. +-----------+ +-----------+ +-------------+ | Zone 1 | | Zone 3 | | Zone 5 | | +------+| | +------+ | .........|.. | |Zone 2|| | |Zone 4| | : Zone 6 | : | +--A---+| | C | | D | : +-----------+ +----+--B---+ +--------E----+ : :..........: (a) "Contained" (b) "Common Border" (c) "Overlap" Zone 2 nests Zone 4 nests Zones 5 and 6 inside Zone 1 inside Zone 3 do not nest - Figure 4: Zone nesting examples - -Nested scopes provide the ability to perform "expanding-scope" searches -in a similar, but better behaved, manner to the well-known expanding -ring search where the TTL of a query is steadily increased until a -replier can be found. Studies have also shown that nested scopes can be -useful in localizing multicast repair traffic [8]. + Figure 3: Zone nesting examples A ZBR cannot independently determine whether one zone is nested inside -another. However, they can determine that one zone does NOT nest inside +another. However, it can determine that one zone does NOT nest inside another. For example, in figure 4: -Draft MZAP February 1998 - o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2 - from leaving zone 2. ZBR A can thus determine that zone 1 does not - nest within zone 2, but it cannot, however, determine whether zone 2 - nests within zone 1. + from leaving zone 2. When ZBR A first receives a ZAM for zone 1, it + +Draft MZAP June 1999 + + then knows that zone 1 does not nest within zone 2, but it cannot, + however, determine whether zone 2 nests within zone 1. o ZBR B acts as ZBR for both zones 3 and 4, and hence cannot determine if one is nested inside the other. However, ZBR C can determine that - zone 3 does not nest inside zone 4 since it is a ZBR for zone 4 and - not zone 3. + zone 3 does not nest inside zone 4 when it receives a ZAM for zone 3, + since it is a ZBR for zone 4 but not zone 3. o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that - zone 6 does not nest inside zone 5. Similarly, ZBR E only acts as - ZBR zone 5 and not 6, hence ZBR E can deduce that zone 5 does not - nest inside zone 6. + zone 5 does not nest inside zone 6 upon hearing a ZAM for zone 5. + Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence ZBR E can + deduce that zone 6 does not nest inside zone 5 upon hearing a ZAM for + zone 6. The fact that ZBRs can determine that one zone does not nest inside another, but not that a zone does nest inside another, means that -nesting must be determined in a distributed fashion. - -When a ZBR receives a ZAM for a scope X for which it is NOT a border, it -creates a local "X not inside" state entry, if such an entry does not -already exist. It then restarts the entry's timer at [ZAM-HOLDTIME]. -Existence of this state indicates that the ZBR knows that X does not -nest inside any scope for which it is a border. If the entry's timer -expires (because no more ZAMs for X are heard for [ZAM-HOLDTIME]), the -entry is deleted. - -Periodically, at an interval of [NIM-INTERVAL], a router originates a -Not-Inside Message (NIM) for each "X not inside" entry, for each scope -zone Y for which it is a border. Like a ZAM, this message is multicast -to the address [MZAP-LOCAL-GROUP] from one of its interfaces in Y. +nesting must be determined in a distributed fashion. This is done by +sending Not-Inside Messages (NIMs) which express the fact that a zone X +is not inside a zone Y. Such messages are sent to the well-known +[MZAP-LOCAL-GROUP] and are thus seen by the same entities listening to +ZAM messages (e.g., MADCAP servers). Such entities can then determine +the nesting relationship between two scopes based on a sustained absence +of any evidence to the contrary. -When a ZBR receives a NIM saying that "X is not inside Y", it is -forwarded, unmodified, in a manner similar to ZAMs: +3.2. Other Messages -o If the NIM was received on an interface with a boundary for either X - or Y, the NIM is discarded. +Two other message types, Zone Convexity Messages (ZCMs) and Zone Limit +Exceeded (ZLE) messages, are used only by routers, and enable them to +compare their configurations for consistency and detect +misconfigurations. These messages are sent to MZAP's relative address +within the scope range associated with the scope zone to which they +refer, and hence are typically not seen by entities other than routers. +Their use in detecting specific misconfiguration scenarios will be +covered in the next section. -o Unlike ZAMs, if the NIM was not received on the interface towards the - message origin (according to the Multicast RIB), the NIM is - discarded. +Packet formats for all messages are described in Section 5. -o If a NIM for the same X and Y (where each is identified by its first - multicast address) was received in the last [ZAM-DUP-TIME] seconds, - the NIM is not forwarded. +3.3. Zone IDs -Draft MZAP February 1998 +When a boundary router first starts up, it uses its lowest IP address +which it considers to be inside a given zone, and which is routable +everywhere within the zone (for example, not a link-local address), as +the Zone ID for that zone. It then schedules ZCM and ZAM messages to be -o Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds. +Draft MZAP June 1999 -o The ZBR then re-originates the NIM (unchanged) into each local scope - zone in which it has interfaces, except that it is not sent back into - the local scope zone from which the message was received, nor is it - sent out any interface with a boundary for either X or Y. +sent in the future (it does not send them immediately). 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. Usage +4. Detecting Router Misconfigurations -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 +In this section, we cover 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 immediately). 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 join the [MZAP-LOCAL-GROUP] to listen for -Zone Announcement Messages to build up a list of the scope zones that -are relevant locally, and for Not-Inside Messages if it wishes to learn -nesting information. However, listening for to such 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 and Not-Inside Messages to maintain scope -information. +4.1. Detecting non-convex scope zones -Draft MZAP February 1998 +Zone Convexity Messages (ZCMs) are used by routers to detect non-convex +administrative scope zones, which are one possible misconfiguration. +Non-convex scope zones can cause problems for applications since a +receiver may never see administratively-scoped packets from a sender +within the same scope zone, since packets travelling between them may be +dropped at the boundary. -An internal entity may assume that X nests within Y if: +In the example illustrated in Figure 4, the path between B and D goes +outside the scope (through A and E). Here, Router B and Router C send +ZCMs within a given scope zone for which they each have a boundary, with +each reporting the other boundary routers of the zone from which they +have heard. In Figure 4, 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. -a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME] - seconds ago, AND + #####*####======== + # B # = ##### = non-convex scope boundary + # |->A* = + # | # = ===== = other scope boundaries + # | ####*#### + # | E # ----> = path of B's ZCM + # v D* + # C # * = boundary interface + #####*############ -b) it has not heard a NIM indicating that "X not inside Y" for at - least [NIM-HOLDTIME] seconds. + Figure 4: Non-convexity detection -3.3. Detecting non-convex scope zones +Draft MZAP June 1999 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. + 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 +4.2. Detecting leaky boundaries for non-local scopes + +A "leaky" boundary is one which logically has a "hole" due to some +router not having a boundary applied on an interface where one ought to +exist. Hence, the boundary does not completely surround a piece of the +network, resulting in scoped data leaking outside. 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 5. =============#####*######## = Zone1 # A Zone2 # C = misconfigured router = +---->*E v # = | # B # ##### = leaky scope boundary =======*=====#====*=======# = D # | # ===== = other scope boundaries = ^-----*C<--+ # = Zone4 # Zone3 # ----> = path of ZAMs =============############## Figure 5: ZAM Leaking -Draft MZAP February 1998 +(2) If a Zone Length Exceeded (ZLE) message is received. The ZAM + packet also contains a Zones Traveled Limit. If the number of + Local Scope zones traversed becomes equal to the Zones Traveled + Limit, a ZLE message is generated (the suppression mechanism for + preventing implosion is described later in the Processing Rules -(2) If a ZLE message is received. +Draft MZAP June 1999 + + section). ZLEs detect leaks where packets do not return to another + part of the same scope zone, but instead reach other Local Scope + zones far away from the ZAM originator. In either case, the misconfigured router will be either the message -origin, or one of the routers in the path list included in the message -received. +origin, or one of the routers in the ZBR path list which is included in +the message received (or perhaps a router on the path between two such +ZBRs which ought to have been a ZBR itself). -3.5. Detecting a leaky Local Scope zone +4.3. Detecting a leaky Local Scope zone A local scope is leaky if a router has an administrative 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. +o If a ZAM for a given scope is received by a ZBR which is a boundary + 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 +4.4. 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. +o If a ZBR is configured with a textual name for a given scope and + language, and it receives a ZAM or ZCM with a name for the same scope + and language, but the scope names do not match. + +Draft MZAP June 1999 Detecting either type of conflict above indicates that either the local -router or router originating the message is misconfigured. +router or the router originating the message is misconfigured. Configuration tools SHOULD strip white space from the beginning and end - -Draft MZAP February 1998 - of each name to avoid accidental misconfiguration. -3.7. Packet Formats +5. 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 shown below: +PORT] and an IPv4 TTL or IPv6 Hop Limit of 255. + +When sending an MZAP message referring to a given scope zone, a ZBR MUST +use a source address which will have significance everywhere within the +scope zone to which the message refers. For example, link-local +addresses MUST NOT be used. + +The common MZAP message header (which follows the UDP header), 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |B| PTYPE |Address Family | NameCount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Origin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone ID Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zone Start Address | @@ -475,69 +481,71 @@ | . . . | Encoded Zone Name-N (variable length) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (if needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: The version defined in this document is version 0. "Big" scope bit (B): If clear, indicates that the addresses in the scoped range are not + +Draft MZAP June 1999 + subdividable, and that address allocators may utilize the entire range. If set, address allocators should not use the entire range, but should learn an appropriate sub-range via another mechanism (e.g., AAP [7]). -Draft MZAP February 1998 - 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) 3: Not-Inside Message (NIM) Address Family: - The IANA-assigned address family number identifying the address - family for all addresses in the packet. The families defined for IP - are: + The IANA-assigned address family number [10,11] identifying the + address family for all addresses in the packet. The families defined + for IP are: 1: IPv4 2: IPv6 Name Count: The number of encoded zone name blocks in this packet. The count may be zero. 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. + This gives the start address for the scope zone boundary. For + example, if the zone is a boundary 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 + This gives the ending address for the scope zone boundary. For + example, if the zone is a boundary 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. 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. - -Draft MZAP February 1998 + zone. Note that this ID is usually different from the ID of the + Local Scope zone in which the origin resides. Encoded Zone Name: + +Draft MZAP June 1999 + +--------------------+ |D| Reserved (7 bits)| +--------------------+ | LangLen (1 byte) | +--------------------+-----------+ | Language Tag (variable size) | +--------------------+-----------+ | NameLen (1 byte) | +--------------------+-----------+ | Zone Name (variable size) | @@ -559,42 +567,32 @@ Name Len: The length, in bytes, of the Zone Name field. The length MUST NOT be zero. 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. White space SHOULD be stripped from the beginning and end of - each name before encoding, to avoid accidental conflicts. 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. + each name before encoding, to avoid accidental conflicts. Padding (if needed): The end of the MZAP header is padded with null bytes until it is 4- - -Draft MZAP February 1998 - byte aligned. -Draft MZAP February 1998 +Draft MZAP June 1999 -3.7.1. Zone Announcement Message +5.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 +ZBR for each scope for which it is a boundary, EXCEPT: o the Local Scope o the Link-local scope The format of a Zone Announcement Message 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 @@ -606,122 +604,85 @@ | Router Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Authentication Block (optional) -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are defined as follows: Zones 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 dropped. A value of 0 indicates that no limit exists. -Draft MZAP February 1998 - 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]. +Draft MZAP June 1999 + 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 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. +5.2. Zone Limit Exceeded (ZLE) The format of a ZLE is shown below: - -Draft MZAP February 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MZAP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| ZT | ZTL | unused | +| ZT | ZTL | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Zone ID Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are copied from the ZAM, 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. - -3.7.3. Zone Convexity Message +5.3. Zone Convexity Message A Zone Announcement Message has PTYPE=2, and is periodically sent by a -ZBR for each scope for which it is a border, EXCEPT: - -o the Global Scope +ZBR for each scope for which it is a boundary (except the Link-local +scope). Note that ZCM's ARE sent in the Local Scope. -o the Link-local scope -(Note that ZCM's ARE sent in the Local Scope.) +Draft MZAP June 1999 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: - -Draft MZAP February 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MZAP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZNUM | unused | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBR Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... @@ -739,270 +700,544 @@ 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 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. -3.7.4. Not-Inside Message +5.4. Not-Inside Message A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a ZBR which knows that a scope X does not nest within another scope Y ("X not inside Y"): -The format of a Not Inside Message is shown below: +The format of a Not-Inside Message is shown below: -Draft MZAP February 1998 +Draft MZAP June 1999 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Not-Inside Zone Start Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Authentication Block (optional) | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: MZAP Header: Header fields identifying the scope X. The Name Count may be 0. Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the start address for the scope Y. -Authentication Block: - If present, this provides information which can be used to - authenticate the sender of the NIM (i.e. Message Origin in the MZAP - Header). +6. Message Processing Rules -4. Message Timing +6.1. Internal entities listening to MZAP messages + +Any host or application may join the [MZAP-LOCAL-GROUP] to listen for +Zone Announcement Messages to build up a list of the scope zones that +are relevant locally, and for Not-Inside Messages if it wishes to learn +nesting information. However, listening to such messages is not the +recommended method for regular applications to discover this +information. These applications will normally query a local Multicast +Address Allocation Server (MAAS) [3], which in turn listens to Zone +Announcement Messages and Not-Inside Messages to maintain scope +information, and can be queried by clients via MADCAP messages. + +An entity (including a MAAS) lacking any such information can only +assume that it is within the Global Scope, and the Local Scope, both of +which have well-known address ranges defined in [1]. + +An internal entity (e.g., an MAAS) receiving a ZAM will parse the +information that is relevant to it, such as the address range, and the +names. An address allocator receiving such information MUST also use +the "B" bit to determine whether it can add the address range to the set +of ranges from which it may allocate addresses (specifically, it may add +them only if the bit is zero). Even if the bit is zero, an MAAS SHOULD +still store the range information so that clients who use relative- +addresses can still obtain the ranges by requesting them from the MAAS. + +An internal entity (e.g., an MAAS) may assume that X nests within Y if: + +Draft MZAP June 1999 + +a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME] + seconds ago, AND + +b) it has not heard a NIM indicating that "X not inside Y" for at + least [NIM-HOLDTIME] seconds. + +6.2. Sending ZAMs 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. -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. +The ZAM packet also contains a Zones Traveled Limit (ZTL). If the +number of Local Zone IDs in the ZAM path becomes equal to the Zones +Traveled Limit, the packet will be dropped. The ZTL field 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. + +6.3. Receiving ZAMs + +When a ZBR receives a ZAM for some scope zone X, it uses the following +rules. + +If the local ZBR does NOT have any configuration for scope X: + +(1) Check to see if the included start and end addresses overlap with, + but are not identical to, the start and end addresses of any + locally-configured scope Y, and if so, signal an address range + conflict to a local administrator. + +(2) Create a local "X not inside" state entry, if such an entry does + not already exist. The ZBR then restarts the entry's timer at + [ZAM-HOLDTIME]. Existence of this state indicates that the ZBR + knows that X does not nest inside any scope for which it is a + boundary. If the entry's timer expires (because no more ZAMs for X + are heard for [ZAM-HOLDTIME]), the entry is deleted. + +If the local ZBR does have configuration for scope X: + +(1) If the ZAM originated from OUTSIDE the scope (i.e., received over a + boundary interface for scope X): + +Draft MZAP June 1999 + + a) + If the Scope Zone ID in the ZAM matches the ZBR's own Scope Zone + ID, then signal a leaky scope misconfiguration. + + b) + Drop the ZAM (perform no further processing below). For + example, router G in Figure 2 will not forward the ZAM. This + rule is primarily a safety measure, since the placement of G in + Figure 2 is not a recommended configuration, as discussed + earlier. + +(2) If the ZAM originated from INSIDE the scope: + + a) + Add the Origin to the local list of ZBRs (including the local + ZBR) for scope X, and update the Zone ID is to be the lowest IP + address in the list. Set the ZBR list entry added to time out + after [ZAM-HOLDTIME] if no further messages are received from + that ZBR, so that the Zone ID will converge to the lowest + address of any active ZBR for the scope. + + b) + If the Origin's Scope Zone ID in the ZAM does not match the + Scope Zone ID kept by the local ZBR, and this mismatch continues + to occur, then signal a possible leaky scope warning. + + c) + For each textual name in the ZAM, see if a name for the same + scope and language is locally-configured; if so, but the scope + names do not match, signal a scope name conflict to a local + administrator. + + d) + 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. + +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 then discarded. Otherwise, the ZAM is cached for at +least [ZAM-DUP-TIME] seconds. 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. + +Draft MZAP June 1999 + +The Zones Travelled count in the message is then incremented, and if the +updated count is equal to or greater than the ZTL field, schedule a ZLE +to be sent as described in the next subsection and perform no further +processing below. + +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. + +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, nor is it sent into any local scope zone +whose ID is known and appears in the path list). In each such ZAM re- +originated, the ZBR adds its own IP address 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.) + +6.4. Sending ZLEs + +This packet is sent by a local-zone boundary 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) + +Draft MZAP June 1999 + +This equation results in an exponential random distribution which +ensures that close to one ZBR will respond. Using a purely uniform +distribution would begin to exhibit scaling problems as the number of +ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE arrives +before the time chosen, two routers choosing delays which differ by an +amount less than the propagation delay between them will both send +messages, consuming excess bandwidth. Hence it is desirable to minimize +the number of routers choosing a delay close to the lowest delay chosen, +and an exponential distribution is suitable for this purpose. A router SHOULD NOT send more than one Zone Limit Exceeded message every [ZLE-MIN-INTERVAL] regardless of destination. -Each ZBR should send a Zone State Session Message for each scope zone -for which it is a boundary every [ZNSM-INTERVAL] seconds, +/- 30% of -[ZNSM- INTERVAL] each time to avoid message synchronization. +6.5. Receiving ZLEs -5. Constants +When a router receives a ZLE, it performs the following actions: -[MZAP-PORT]: The well-known UDP port to which all MZAP messages are -sent. Value: TBD by IANA. +(1) If the router has a duplicate ZLE message scheduled to be sent, it + unschedules its own message so another one will not be sent. -Draft MZAP February 1998 +(2) If the ZLE contains the router's own address in the Origin field, + it signals a leaky scope misconfiguration. + +6.6. Sending ZCMs + +Each ZBR should send a Zone Convexity Message (ZCM) for each scope zone +for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of +[ZCM-INTERVAL] each time to avoid message synchronisation. + +ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. +(For example, if the scope range is 239.1.0.0 to 239.1.0.255, then these +messages should be sent to 239.1.0.252.) 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 +intermediate Local Scope ZBRs. + +6.7. Receiving ZCMs + +When a ZCM is received for a given scope X, on an interface which is +inside the scope, it follows the rules below: + +Draft MZAP June 1999 + +(1) The Origin 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. The new entry is scheduled to be timed out + after [ZCM-HOLDTIME] if no further messages are received from that + ZBR, so that the Zone ID will converge to the lowest address of any + active ZBR for the scope. + +(2) 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 if no ZCM is received from that ZBR for [ZCM- + HOLDTIME] seconds, as in the example in Figure 3, then signal a + non-convexity problem. + +(3) For each textual name in the ZCM, see if a name for the same scope + and language is locally-configured; if so, but the scope names do + not match, signal a scope name conflict to a local administrator. + +6.8. Sending NIMs + +Periodically, for each scope zone Y for which it is a boundary, a router +originates a Not-Inside Message (NIM) for each "X not inside" entry it +has created when receiving ZAMs. Like a ZAM, this message is multicast +to the address [MZAP-LOCAL-GROUP] from one of its interfaces inside Y. + +Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL] +seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization. + +6.9. Receiving NIMs + +When a ZBR receives a NIM saying that "X is not inside Y", it is +forwarded, unmodified, in a manner similar to ZAMs: + +(1) If the NIM was received on an interface with a boundary for either + X or Y, the NIM is discarded. + +(2) Unlike ZAMs, if the NIM was not received on the interface towards + the message origin (according to the Multicast RIB), the NIM is + discarded. + +(3) If a NIM for the same X and Y (where each is identified by its + first multicast address) was received in the last [ZAM-DUP-TIME] + seconds, the NIM is not forwarded. + +Draft MZAP June 1999 + +(4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds. + +(5) The ZBR then re-originates the NIM (i.e., with the original UDP + payload) into each local scope zone in which it has interfaces, + except that it is not sent back into the local scope zone from + which the message was received, nor is it sent out any interface + with a boundary for either X or Y. + +7. Constants + +[MZAP-PORT]: The well-known UDP port to which all MZAP messages are +sent. Value: 2106. [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. +ZAMs are sent. All Multicast Address Allocation servers and Zone +Boundary Routers listen to this group. Value: 239.255.255.252 for IPv4; +FF03:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFC for IPv6. [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. +ZCMs are sent. A Zone Boundary Router listens to the relative group in +each scope for which it is a boundary. Value: (last IP address in scope +range) - 3. For example, in the Local Scope, the relative group is the +same as the [MZAP-LOCAL-GROUP] address. -[ZAM-INTERVAL]: The interval at which a Zone Border Router originates +[ZAM-INTERVAL]: The interval at which a Zone Boundary Router originates Zone Announcement Messages. Default value: 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). [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 +[ZCM-INTERVAL]: The interval at which a Zone Boundary 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 + +Draft MZAP June 1999 + minutes). [ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, regardless of destination. Default value: 300 seconds (5 minutes). -[NIM-INTERVAL]: The interval at which a Zone Border Router originates -Zone Not Inside Messages. Default value is 1800 seconds (30 minutes) +[NIM-INTERVAL]: The interval at which a Zone Boundary Router originates +Not-Inside Messages. Default value: 1800 seconds (30 minutes). [NIM-HOLDTIME]: The holdtime to include the state within a NIM. This SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value: 5460 (91 minutes) -6. Security Considerations +8. Security Considerations -MZAP does not include authentication in its messages. Thus it is open -to misbehaving hosts sending spoof ZAMs, ZCMs, or NIMs. +While unauthorized reading of MZAP messages is relatively innocuous (so +encryption is generally not an issue), accepting unauthenticated MZAP +messages can be problematic. Authentication of MZAP messages can be +provided by using the IPsec Authentication Header (AH) [12]. -Draft MZAP February 1998 +In the case of ZCMs and ZLEs, an attacker can cause false logging of +convexity and leakage problems. It is likely that is would be purely an +annoyance, and not cause any significant problem. (Such messages could +be authenticated, but since they may be sent within large scopes, the +receiver may not be able to authenticate a non-malicious sender.) -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. +ZAMs and NIMs, on the other hand, are sent within the Local Scope, where +assuming a security relationship between senders and receivers is more +practical. -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. +In the case of NIMs, accepting unauthenticated messages can cause the +false cancellation of nesting relationships. This would cause a section +of the hierarchy of zones to flatten. Such a flattening would lessen +the efficiency benefits afforded by the hierarchy but would not cause it +to become unusable. -In the case of NIMs, spoof messages can also cause the false -cancellation of nesting relationships. This would cause a section of the -hierarchy of zones to flatten. Such a flattening would lessen the -efficiency benefits afforded by the hierarchy but would not cause it to -become unusable. +Accepting unauthenticated ZAM messages, however, could 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 administrative scope 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, any +application accepting unauthenticated ZAMs 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 -Spoofed 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 administrative 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. +Draft MZAP June 1999 + +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 -being presented to users. To counter this, ZAMs may be authenticated as -follows: +Servers (MAASs) of names and address ranges of scopes, and accepting +unauthenticated ZAMs could result in false names being presented to +users, and in wrong addresses being allocated to users. To counter +this, MAAS's authenticate ZAMs as follows: -(1) A ZBR signs all ZAMs it originates. +(1) A ZBR signs all ZAMs it originates (using an AH). -(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 - authenticated ZAM even if an un-authenticated one was received with - the last [ZAM-DUP-TIME] seconds. +(2) A ZBR signs a ZAM it relays 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 authenticated + 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. -Draft MZAP February 1998 +9. Acknowledgements -7. References +This document is a product of the MBone Deployment Working Group, whose +members provided many helpful comments and suggestions. The Multicast +Address Allocation Working Group also provided useful feedback regarding +scope names and interactions with applications. + +10. 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. +Draft MZAP June 1999 + [5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft, November 1997. [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [7] Handley, M., "Multicast Address Allocation Protocol (AAP)", draft- handley-aap-01.txt, Internet Draft, July 1998. [8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998, Vancouver, Canada. -8. Acknowledgements +[9] Patel, B., Shah, M., and S. Hanna. "Multicast Address Dynamic + Client Allocation Protocol (MADCAP)", Work in progress, May 1999. -This document is a product of the MBone Deployment Working Group, whose -members provided many helpful comments and suggestions. The Multicast -Address Allocation Working Group also provided useful feedback regarding -scope names and interactions with applications. +[10] J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994. -9. Authors' Addresses +[11] IANA, "Address Family Numbers", http://www.isi.edu/in- + notes/iana/assignments/address-family-numbers + +[12] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, + November 1998. + +Draft MZAP June 1999 + +11. Authors' Addresses Mark Handley AT&T Center for Internet Research at ICSI 1947 Center St, Suite 600 Berkely, CA 94704 USA Email: mjh@aciri.org -Draft MZAP February 1998 - David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA Email: dthaler@microsoft.com Roger Kermode Motorola Australian Research Centre 12 Lord St, Botany, NSW 2109 Australia Email: Roger_Kermode@email.mot.com -10. Full Copyright Statement +12. Full Copyright Statement -Copyright (C) The Internet Society (1998). All Rights Reserved. +Copyright (C) The Internet Society (1999). 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 implementation 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 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 + +Draft MZAP June 1999 + 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." - -Draft MZAP February 1998 +FITNESS FOR A PARTICULAR PURPOSE. Table of Contents 1 Introduction .................................................... 2 -2 Overview ........................................................ 3 -2.1 Nesting ....................................................... 6 -3 Usage ........................................................... 8 -3.1 Zone IDs ...................................................... 8 -3.2 Informing internal entities of scopes ......................... 8 -3.3 Detecting non-convex scope zones .............................. 9 -3.4 Detecting leaky boundaries for non-local scopes ............... 9 -3.5 Detecting a leaky Local Scope zone ............................ 10 -3.6 Detecting conflicting scope zones ............................. 10 -3.7 Packet Formats ................................................ 11 -3.7.1 Zone Announcement Message ................................... 15 -3.7.2 Zone Limit Exceeded (ZLE) ................................... 16 -3.7.3 Zone Convexity Message ...................................... 17 -3.7.4 Not-Inside Message .......................................... 18 -4 Message Timing .................................................. 19 -5 Constants ....................................................... 19 -6 Security Considerations ......................................... 20 -7 References ...................................................... 22 -8 Acknowledgements ................................................ 22 -9 Authors' Addresses .............................................. 22 -10 Full Copyright Statement ....................................... 23 +2 Terminology ..................................................... 4 +3 Overview ........................................................ 5 +3.1 Scope Nesting ................................................. 6 +3.2 Other Messages ................................................ 7 +3.3 Zone IDs ...................................................... 7 +4 Detecting Router Misconfigurations .............................. 8 +4.1 Detecting non-convex scope zones .............................. 8 +4.2 Detecting leaky boundaries for non-local scopes ............... 9 +4.3 Detecting a leaky Local Scope zone ............................ 10 +4.4 Detecting conflicting scope zones ............................. 10 +5 Packet Formats .................................................. 11 +5.1 Zone Announcement Message ..................................... 14 +5.2 Zone Limit Exceeded (ZLE) ..................................... 15 +5.3 Zone Convexity Message ........................................ 15 +5.4 Not-Inside Message ............................................ 16 +6 Message Processing Rules ........................................ 17 +6.1 Internal entities listening to MZAP messages .................. 17 +6.2 Sending ZAMs .................................................. 18 +6.3 Receiving ZAMs ................................................ 18 +6.4 Sending ZLEs .................................................. 20 +6.5 Receiving ZLEs ................................................ 21 +6.6 Sending ZCMs .................................................. 21 +6.7 Receiving ZCMs ................................................ 21 +6.8 Sending NIMs .................................................. 22 +6.9 Receiving NIMs ................................................ 22 +7 Constants ....................................................... 23 +8 Security Considerations ......................................... 24 +9 Acknowledgements ................................................ 25 +10 References ..................................................... 25 +11 Authors' Addresses ............................................. 27 +12 Full Copyright Statement ....................................... 27