draft-ietf-mboned-mzap-00.txt   draft-ietf-mboned-mzap-01.txt 
Internet Engineering Task Force MboneD WG MBoneD Working Group Mark Handley
Internet Draft M. Handley Internet Engineering Task Force ISI
draft-ietf-mboned-mzap-00.txt ISI INTERNET-DRAFT Dave Thaler
December 15, 1997 3 August 1998 Microsoft
Expires: June 1998 Expires February 1999
Multicast-Scope Zone Announcement Protocol (MZAP) Multicast-Scope Zone Announcement Protocol (MZAP)
<draft-ietf-mboned-mzap-01.txt>
STATUS OF THIS MEMO Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document is an Internet Draft. Internet Drafts are working
and may be updated, replaced, or obsoleted by other documents at any documents of the Internet Engineering Task Force (IETF), its Areas, and
time. It is inappropriate to use Internet-Drafts as reference its Working Groups. Note that other groups may also distribute working
material or to cite them other than as ``work in progress''. documents as Internet Drafts.
To learn the current status of any Internet-Draft, please check the Internet Drafts are valid for a maximum of six months and may be
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow updated, replaced, or obsoleted by other documents at any time. It is
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), inappropriate to use Internet Drafts as reference material or to cite
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or them other than as a "work in progress".
ftp.isi.edu (US West Coast).
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 Copyright Notice
Zone Announcement Protocol (MZAP), for discovering the
multicast administrative scope zones that are relevant at
a particular location. MZAP also provides mechanisms
whereby two common misconfigurations of administrative
scope zones can be discovered.
1 Status Copyright (C) The Internet Society (1998). All Rights Reserved.
This is a strawman proposal. It has not been subject to any peer Draft MZAP August 1998
review or implementation.
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 scope using a scoping mechanism. In this document, we only consider
administrative scoping, as defined in [1]. An administrative scope administrative scoping, as defined in RFC 2365 [1]. An administrative
zone is defined by a set of border routers to a region of the scope zone is defined by a set of routers surrounding a region of the
network. These border routers are configured to not pass multicast network. These "border routers" are configured to not pass multicast
traffic destined for a particular range of multicast addresses to or traffic destined for a particular range of multicast addresses to or
from links leaving the scope zone. from links leaving the scope zone.
Administrative scope zones may be of any size, and a particular host Administrative scope zones may be of any size, and a particular host may
may be within many administrative scope zones. The only zones a host be within many administrative scope zones of various sizes. The only
can assume that it is within are the global zone, and local scope zones a host can assume that it is within are the global zone, and a
Local scope is defined as being the smallest administrative scope "Local Scope". A Local Scope is defined as being the smallest
zone encompassing a host, and the border is configured for addresses administrative scope zone encompassing a host, and the border is
in the range 239.255.0.0 to 239.255.255.255 inclusive. [1] specifies: configured for addresses in the range 239.255.0.0 to 239.255.255.255
239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope inclusive. RFC 2365 specifies:
is the minimal enclosing scope, and hence is not further divisible. "239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local
Although the exact extent of a Local Scope is site dependent, locally Scope is the minimal enclosing scope, and hence is not further
scoped regions must obey certain topological constraints. In divisible. Although the exact extent of a Local Scope is site
particular, a Local Scope must not span any other scope boundary. dependent, locally scoped regions must obey certain topological
Further, a Local Scope must be completely contained within or equal constraints. In particular, a Local Scope must not span any other
to any larger scope. In the event that scope regions overlap in area, scope boundary. Further, a Local Scope must be completely contained
the area of overlap must be in its own local scope. This implies within or equal to any larger scope. In the event that scope regions
that any scope boundary is also a boundary for the Local Scope. 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 Two problems make administrative scoping difficult to deploy and
difficult to use: difficult to use:
o Misconfiguration is easy. It is difficult to detect scope o Misconfiguration is easy. It is difficult to detect scope zones that
zones that have been configured so as to not be convex (the have been configured so as to not be convex (the shortest path
shortest path between two nodes within the zone passes outside between two nodes within the zone passes outside the zone), or to
the zone) or to leak (one or more border routers was not leak (one or more border routers were not configured correctly), or
configured correctly). to intersect in both area and address range.
o Applications have no way to discover the scope zones that are o Applications have no way to discover the scope zones that are
relevant to them. This makes it difficult to use admin scope relevant to them. This makes it difficult to use admin scope zones,
zones, and hence reduced the incentive to deploy them. and hence reduces the incentive to deploy them.
This document defines the Multicast Scope Zone Announcement Protocol 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 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 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 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 Routers SHOULD be configured so that the router itself is within the
scope zone. This is should in figure 1A, where router 1 is inside 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 scope zone and has the border configuration. It is possible for the
first router outside the scope zone to be configured with the border, first router outside the scope zone to be configured with the border, as
as illustrated in figure 1B where routers 2 and 3 are outside the illustrated in figure 1(b) where routers B and C are outside the zone
zone and have the border configuration, but this is NOT RECOMMENDED. and have the border configuration, but this is NOT RECOMMENDED.
............ ................ ............ ................
. . +O+--> . *O+--> . . +B+--> . *B+-->
. . / 2 . /. 2 . . / . /.
. 1 * . 1 + . . * . + .
. <---+O*---+O+-> . <---+O+---*O+-> . <---+A*---+C+-> . <---+A+---*C+->
. + . 3 . + . 3 . + . . + .
. / . . / . . / . . / .
. zone X <-- . . zone X <-- . . 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. other admin scope border routers.
When a ZBR router is configured correctly, it can deduce which side Draft MZAP August 1998
of the boundary is inside the scope zone and which side is outside
it. It can also send messages into the scope zone, which it SHOULD
NOT be able to do if the router itself is considered outside the
scope zone.
Such a ZBR router should then send periodic Zone Announcement When a ZBR is configured correctly, it can deduce which side of the
Messages (ZAMs) for the zone for which it is configured as a border boundary is inside the scope zone and which side is outside it. It can
from each of its interfaces that go into that scope zone. These also send messages into the scope zone, which it SHOULD NOT be able to
messages are multicast to the address 239.255.255.254, which is a do if the router itself is considered outside the scope zone.
locally scoped address.
Each ZBR router should also listen for ZAM messages from other ZBRs Such a ZBR should then send periodic Zone Announcement Messages (ZAMs)
for the same border. The ZBR router with the lowest interface IP for the zone for which it is configured as a border from one of its
address within the zone from those ZBRs forming the zone border interfaces that go into that scope zone. These messages are multicast
becomes the zone-id router for the zone. The combination of this IP to the address [MZAP-LOCAL-GROUP] in the Local Scope.
address and the base address of the scoping range server to uniquely
identify the scope zone.
Every local scope ZBR that receives any ZAM for a scope zone other Each ZBR also listens for messages from other ZBRs for the same border.
than local scope SHOULD then forward the ZAM out of all the other The ZBR with the lowest interface IP address within the zone from those
interfaces that are in different local scope zones except ones that ZBRs forming the zone border becomes the zone-id router for the zone.
form a border for the zone described in the ZAM. It adds the zone-id The combination of this IP address and the first multicast address in
of the local scope zone that the message came from to the ZAM path the scoped range serve to uniquely identify the scope zone.
list before doing so. A local scope ZBR receiving a ZAM with a non-
null path list MUST NOT forward that ZAM back into a local scope zone
that is contained in the path list. This process is illustrated in
figure 2.
in 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 o If the ZAM was received on an interface which is NOT a Local Scope
Local Zone IDs in the ZAM path becomes equal to the Zones Traveled boundary, and the last Local Zone ID Address in the path list is 0,
Limit, the packet should be dropped. Zones Traveled Limit is set when the ZBR fills in the Local Zone ID Address of the local zone from
the packet is first sent, and defaults to 32, but can be set to a which the ZAM was received.
lower value if a network administrator knows the expected size of the
zone.
Addition messages called Zone Convexity Messages (ZCM) SHOULD also be o If a ZAM for the same scope (as identified by the origin Zone ID and
sent to the second highest address in the scope zone range itself first multicast address) was received in the last [ZAM-DUP-TIME]
(For example, if the scope zone border is for 239.1.0.0 to seconds, the ZAM is not forwarded. For example, when router C in
239.1.0.255, then these messages should be sent to 239.1.0.254.) As figure 2 receives the ZAM via B, it will not be forwarded, since it
these are not locally scoped packets, they are simply multicast has just forwarded the ZAM from E.
across the scope zone itself, and require no path to be built up, or
forwarding by local scope zone ZBRs. These messages are used to
detect non-convex admin scope zones, as illustrated in figure 3. Here
Router B and Router C originates ZCM messages, each reporting each
other's presence. Router D cannot see Router B's messages, but sees
Router C's report of Router B, and so concludes the zone is not
convex.
in 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
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 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 | | Version | PTYPE |Address Family | NameLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Base Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Origin | | Message Origin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID Address | | Zone ID Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 | | Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N | | Zone End Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Name | | Zone Name |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | Padding (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
Figure 4: Zone Announcement Message Format 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 Address Family:
0. 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 Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
MAY generate a Zone Limit Exceeded message in response to this This gives the start address for the scope zone border. For example,
ZAM message. When set to zero, a router MUST NOT generate a Zone if the zone is a border for 239.1.0.0 to 239.1.0.255, then Zone Start
Limit Exceeded message in response to this message. 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 Message Origin: 32 bits (IPv4) or 128 bits (IPv6)
contained in this message path. 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 Draft MZAP August 1998
local zones that the packet can traverse before it MUST be
dropped.
IP Protocol Version (IP): 3 bits This indicates the format of the Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)
following packet. The following values are defined: 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 Padding (if needed):
with the zone base address defines the range of addresses that The MZAP header is padded with null bytes until it is 4-byte aligned.
form the border to this zone. For example, if the zone is a
border for 239.1.0.0 to 239.1.0.255, then MLEN has the value 24.
A value of zero means all the bits are included in the mask, and
the zone is a border for a single address.
Zone Base Address: 32 bits This gives the base address for the scope 3.7.1. Zone Announcement Message
zone border. For example, if the zone is a border for 239.1.0.0
to 239.1.0.255, then Zone Base Address is 239.1.0.0.
Message Origin: 32 bits This gives the IP address of the interface A Zone Announcement Message has PTYPE=0, and is periodically sent by a
that originated the ZAM message. ZBR for each scope for which it is a border, EXCEPT:
Zone ID Address: 32 bits This gives the lowest IP address that has o the Global Scope
been observed in the zone sending ZAM messages. Together with
Zone Base Address and MLEN it forms a unique ID for the zone.
Zone Path: multiple of 64 bits The zone path is a list of 32 bit o the Local Scope
Local Zone ID Addresses (the Zone ID Address of a local zone)
through which the ZAM message has passed, and 32 bit IP
addresses of the router that forwarded the packet. Every local
scope router that forwards the ZAM across a local scope boundary
MUST add the Local Zone ID Address of the local zone that the
packet was received from and its own IP address to the end of
this list, and increments ZT accordingly. The zone path is
empty which the ZAM message is first sent.
Zone Name: multiple of 8 bits The Zone Name is an ISO 10646 character o the Link-local scope
string in UTF-8 encoding indicating the name given to the scope
zone (eg: "ISI-West Site"). It should be relatively short and
MUST be less that 256 bytes in length. All the border routers to
the same region SHOULD be configured to give the same Zone Name,
or a zero length string MAY be given. A zero length string is
taken to mean that another router is expected to be configured
with the zone name. Having ALL the ZBR routers for a scope zone
announce zero length names should be considered an error.
3.1.1 Zone Limit Exceeded (ZLE) The format of a Zone Announcement Message is shown below:
This packet is sent by a local-zone border router that would have
exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. It
is only sent if the "Respond" bit in the ZAM packet is set, and it is
unicast to the Message Origin given in the ZAM packet.
The format is the same as a ZAM message, and is shown in figure 5: Draft MZAP August 1998
0 1 2 3 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 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 | | 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 Zones Traveled Limit (ZTL): 8 bits
to one. 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 Hold Time:
the network administrator that the scope zone is misconfigured. 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 Draft MZAP August 1998
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 its own IP address to the end of this list, and increment ZT
ZCM is shown in figure 6 and is similar to a ZAM, expect PTYPE take accordingly. The zone path is empty which the ZAM is first sent.
the value two.
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
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 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 3.7.3. Zone Convexity Message
ZBR Addresses contained in this message.
ZBR Address (32 bits) These fields give the addresses of ALL the A Zone Announcement Message has PTYPE=2, and is periodically sent by a
other ZBR routers that the Message Origin ZBR has received ZCM ZBR for each scope for which it is a border, EXCEPT:
messages from during the time that it has taken the Message
Origin ZBR to send ten ZCM messages.
4 Using Zone Announcement Messages o the Global Scope
Any host or application may listen to Zone Announcement Messages to o the Link-local scope
build up a list of the scope zones that are relevant locally. (Note that ZCM's ARE sent in the Local Scope.)
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.
A ZBR can discover misconfiguration of scope boundaries in one of Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL-
several ways: 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 The fields are as follows:
leaking. 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 Draft MZAP August 1998
on an interface that points outside the zone boundary. Such a
ZAM message must have escaped the zone through a leak, and
flooded back around behind the boundary. This is illustrated in
figure 7.
o Other ZBR routers in the scope zone are announcing that they is no longer reachable, if no subsequent ZCM is received. This
are seeing a different set of routers than our router observes should be set to [ZCM-HOLDTIME].
from arriving ZCM messages. If this is a persistent condition,
it indicates that the scope zone is probably not convex, as
illustrated in figure 3.
in 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 Each ZBR should send a Zone Announcement Message for each scope zone for
should attempt to alert the network administrator to the nature of which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-
the misconfiguration. INTERVAL] each time to avoid message synchronisation.
Zone Convexity Messages can also be sent and received by correctly Each ZBR should send a Zone Convexity Message for each scope zone for
configured ordinary hosts within a scope region, which may be a which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM-
useful diagnostic facility that does not require privileged access. 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 5. Constants
scope zone for which it is a boundary every ZAM-INTERVAL seconds,
+/- 30% of ZAM-INTERVAL each time to avoid message synchronisation.
Each ZBR router should send a Zone Convexity Message for each scope [MZAP-PORT]: The well-known UDP port to which all MZAP messages are
zone for which it is a boundary every ZCM-INTERVAL seconds, +/- 30% sent. Value: TBD by IANA.
of ZCM-INTERVAL each time to avoid message synchronisation.
A router SHOULD NOT send more than one Zone Limit Exceeded message [MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which
every ZLE-MIN-INTERVAL regardless of destination. 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 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 In the case of ZCMs, these spoof messages can cause false logging of
logging of convexity problems. It is likely that is would be purely convexity problems. It is likely that is would be purely an annoyance,
an annoyance, and not cause any significant problem. and not cause any significant problem.
In the case of ZAM messages, spoof messages can also cause false In the case of ZAMs, spoof messages can also cause false logging of
logging of configuration problems. This is also considered to not be configuration problems. This is also considered to not be a significant
a significant problem. problem.
Spoof zone announcements however might cause applications to believe Spoof zone announcements however might cause applications to believe
that a scope zone exists when it does not. If these were believed, that a scope zone exists when it does not. If these were believed, then
then applications may choose to use this non-existent admin scope applications may choose to use this non-existent admin scope zone for
zone for their uses. Such applications would be able to communicate their uses. Such applications would be able to communicate
successfully, but would be unaware that their traffic may be successfully, but would be unaware that their traffic may be traveling
traveling further than they expected. As a result, applications MUST further than they expected. As a result, applications MUST only take
only take scope names as a guideline, and SHOULD assume that their scope names as a guideline, and SHOULD assume that their traffic sent to
traffic sent to non-local scope zones might travel anywhere. The non-local scope zones might travel anywhere. The confidentiality of
confidentiality of such traffic CANNOT be assumed from the fact that such traffic CANNOT be assumed from the fact that it was sent to a
it was sent to a scoped address that was discovered using MZAP. 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 MZAP August 1998
Draft, draft-ietf-mboned-admin-ip-space-04.txt [2] M. Handley, D.
Thaler, D. Estrin, "The Internet Multicast Address Allocation being presented to users. To counter this, ZAMs may be authenticated as
Architecture", Internet Draft, Dec 1997. 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/