draft-ietf-mboned-mzap-01.txt   draft-ietf-mboned-mzap-02.txt 
MBoneD Working Group Mark Handley MBoneD Working Group Mark Handley
Internet Engineering Task Force ISI Internet Engineering Task Force ISI
INTERNET-DRAFT Dave Thaler INTERNET-DRAFT Dave Thaler
3 August 1998 Microsoft 7 October 1998 Microsoft
Expires February 1999 Expires April 1999
Multicast-Scope Zone Announcement Protocol (MZAP) Multicast-Scope Zone Announcement Protocol (MZAP)
<draft-ietf-mboned-mzap-01.txt> <draft-ietf-mboned-mzap-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be 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 updated, replaced, or obsoleted by other documents at any time. It is
skipping to change at page 2, line ? skipping to change at page 2, line ?
This document defines a protocol, the Multicast-Scope Zone Announcement This document defines a protocol, the Multicast-Scope Zone Announcement
Protocol (MZAP), for discovering the multicast administrative scope Protocol (MZAP), for discovering the multicast administrative scope
zones that are relevant at a particular location. MZAP also provides zones that are relevant at a particular location. MZAP also provides
mechanisms whereby two common misconfigurations of administrative scope mechanisms whereby two common misconfigurations of administrative scope
zones can be discovered. zones can be discovered.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Draft MZAP August 1998 Draft MZAP October 1998
1. Introduction 1. Introduction
IP Multicast groups can be of 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 RFC 2365 [1]. An administrative administrative scoping, as defined in RFC 2365 [1]. An administrative
scope zone is defined by a set of routers surrounding 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.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
between two nodes within the zone passes outside the zone), or to 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 border routers were not configured correctly), or
to intersect in both area and address range. 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 zones, relevant to them. This makes it difficult to use admin scope zones,
and hence reduces 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
Draft MZAP August 1998 Draft MZAP October 1998
(MZAP) which will provide applications with information about the scope (MZAP) which will provide applications with information about the scope
zones they are within, and also provide diagnostic information to detect zones they are within, and also provide diagnostic information to detect
misconfigured scope zones. misconfigured scope zones.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
Constants used by this protocol are shown as [NAME-OF-CONSTANT], and Constants used by this protocol are shown as [NAME-OF-CONSTANT], and
skipping to change at page 4, line 5 skipping to change at page 4, line 5
A,B,C - routers * - 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: 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.
Draft MZAP August 1998 Draft MZAP October 1998
When a ZBR is configured correctly, it can deduce which side of the 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 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 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. do if the router itself is considered outside the scope zone.
Such a ZBR should then send periodic Zone Announcement Messages (ZAMs) 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 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 interfaces that go into that scope zone. These messages are multicast
to the address [MZAP-LOCAL-GROUP] in the Local Scope. to the address [MZAP-LOCAL-GROUP] in the Local Scope.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
not already in the ZAM's path list, then the ZAM is immediately re- 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 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 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 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 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 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 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 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. list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears.
Draft MZAP August 1998 Draft MZAP October 1998
o In addition, the ZBR re-originates the ZAM out each interface with a 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 Local Scope boundary (except that it is not sent back out the
interface over which it was received), with its own IP address added interface over which it was received, nor is it sent into any local
to the path list, as well as the Zone ID Address of the Local Scope scope zone whose ID is known and appears in the path list). In each
Zone into which the ZAM is being sent, or 0 if the ID is unknown. such ZAM re-originated, the ZBR adds its own IP address to the path
(For example, if the other end of a point-to-point link also has a list, as well as the Zone ID Address of the Local Scope Zone into
boundary on the interface, then the link has no Local Scope Zone ID.) 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.)
########################### ###########################
# Zone1 = Zone2 # ##### = large scope zone border # Zone1 = Zone2 # ##### = large scope zone border
*E-----+--->A*-----+-x # *E-----+--->A*-----+-x #
# | = v # ===== = Local Scope boundaries # | = v # ===== = Local Scope boundaries
# | ======*===*==# # | ======*===*==#
# | = B F # ----> = path of ZAM origined by E # | = B F # ----> = path of ZAM origined by E
# +--->C*-> | ^ # # +--->C*-> | ^ #
# v = <-+---+ # ABCDE = ZBRs # v = <-+---+ # ABCDE = ZBRs
# D = Zone3 # # D = Zone3 #
skipping to change at page 6, line 5 skipping to change at page 6, line 5
sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. As these sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. As these
are not locally scoped packets, they are simply multicast across the 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 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 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 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 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. 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, 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. and so can conclude the zone is not convex.
Draft MZAP August 1998 Draft MZAP October 1998
#####*####======== #####*####========
# B # = ##### = non-convex scope boundary # B # = ##### = non-convex scope boundary
# |->A* = # |->A* =
# | # = ===== = other scope boundaries # | # = ===== = other scope boundaries
# | ####*#### # | ####*####
# | E # ----> = path of B's ZAM # | E # ----> = path of B's ZAM
# v D* # v D*
# C # * = border interface # C # * = border interface
#####*############ #####*############
skipping to change at page 7, line 5 skipping to change at page 7, line 5
3.2. Informing internal entities of scopes 3.2. Informing internal entities of scopes
Any host or application may listen to Zone Announcement Messages to Any host or application may listen to Zone Announcement Messages to
build up a list of the scope zones that are relevant locally. However, build up a list of the scope zones that are relevant locally. However,
listening to Zone Announcement Messages is not the recommended method listening to Zone Announcement Messages is not the recommended method
for regular applications to discover this information. These for regular applications to discover this information. These
applications will normally query a local Multicast Address Allocation applications will normally query a local Multicast Address Allocation
Server [3], which in turn listens to Zone Announcement Messages to Server [3], which in turn listens to Zone Announcement Messages to
Draft MZAP August 1998 Draft MZAP October 1998
maintain a list of scopes. maintain a list of scopes.
3.3. Detecting non-convex scope zones 3.3. Detecting non-convex scope zones
Non-convex scope zones can be detected via two methods: Non-convex scope zones can be detected via two methods:
(1) If a ZBR is listed in ZCMs received, but the next-hop interface (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 (according to the multicast RIB) towards that ZBR is outside the
scope zone, or scope zone, or
skipping to change at page 7, line 47 skipping to change at page 7, line 47
=======*=====#====*=======# =======*=====#====*=======#
= D # | # ===== = other scope boundaries = D # | # ===== = other scope boundaries
= ^-----*C<--+ # = ^-----*C<--+ #
= Zone4 # Zone3 # ----> = path of ZAMs = Zone4 # Zone3 # ----> = path of ZAMs
=============############## =============##############
Figure 4: ZAM Leaking Figure 4: ZAM Leaking
(2) If a ZLE message is received. (2) If a ZLE message is received.
In either case, the misconfigured router will be one of the routers in In either case, the misconfigured router will be either the message
the path list included in the message received. origin, or one of the routers in the path list included in the message
Draft MZAP August 1998 Draft MZAP October 1998
received.
3.5. Detecting a leaky Local Scope zone 3.5. Detecting a leaky Local Scope zone
A local scope is leaky if a router has an admin scope boundary on some 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 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: 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 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 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 its own Zone ID for the given scope. If the two do not match, this
skipping to change at page 8, line 42 skipping to change at page 8, line 44
end addresses of a locally-configured scope. end addresses of a locally-configured scope.
Conflicting scope names can be detected via the following method: 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, 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 it receives a ZAM with a non-empty scope name for the same scope,
and the scope names do not match. and the scope names do not match.
Detecting either type of conflict above indicates that either the local Detecting either type of conflict above indicates that either the local
router or router originating the message is misconfigured. router or router originating the message is misconfigured.
Configuration tools SHOULD strip white space from the beginning and end
of each name to avoid accidental misconfiguration.
Draft MZAP October 1998
3.7. Packet Formats 3.7. Packet Formats
All MZAP messages are sent over UDP, with a destination port of [MZAP- All MZAP messages are sent over UDP, with a destination port of [MZAP-
PORT]. The common MZAP message header (which follows the UDP header), PORT]. The common MZAP message header (which follows the UDP header),
is show below: is shown below:
Draft MZAP August 1998 Draft MZAP October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | PTYPE |Address Family | NameLen | | Version |B| PTYPE |Address Family | NameCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Origin | | Message Origin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID Address | | Zone ID Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Start Address | | Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone End Address | | Zone End Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Name | | Encoded Zone Name-1 (variable length) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | Encoded Zone Name-N (variable length) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (if needed) | | | Padding (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: Version:
The version defined in this document is version 0. 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
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]).
Packet Type (PTYPE): Packet Type (PTYPE):
The packet types defined in this document are: The packet types defined in this document are:
0: Zone Announcement Message (ZAM) 0: Zone Announcement Message (ZAM)
1: Zone Limit Exceeded (ZLE) 1: Zone Limit Exceeded (ZLE)
2: Zone Convexity Message (ZCM) 2: Zone Convexity Message (ZCM)
Address Family: Address Family:
This indicates the format of the following packet. The following The IANA-assigned address family number identifying the address
values are defined by this document: family for all addresses in the packet. The families defined for IP
0: IPv4 are:
1: IPv6 1: IPv4
2: IPv6
Name Count:
Draft MZAP October 1998
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) Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
This gives the start address for the scope zone border. For example, 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 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. Address is 239.1.0.0.
Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) Zone End Address: 32 bits (IPv4) or 128 bits (IPv6)
This gives the ending address for the scope zone border. For 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 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 End Address is 239.1.0.255.
Message Origin: 32 bits (IPv4) or 128 bits (IPv6) Message Origin: 32 bits (IPv4) or 128 bits (IPv6)
This gives the IP address of the interface that originated the This gives the IP address of the interface that originated the
message. message.
Draft MZAP August 1998
Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6) Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)
This gives the lowest IP address of a boundary router that has been This gives the lowest IP address of a boundary router that has been
observed in the zone originating the message. Together with Zone observed in the zone originating the message. Together with Zone
Start Address and Zone End Address, it forms a unique ID for the 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 zone. Note that this ID is NOT the ID of the Local Scope zone in
which the origin resides. which the origin resides.
Encoded Zone Name:
+--------------------+
|D| LangLen (7 bits) |
+--------------------+-----------+
| Language Tag (variable size) |
+--------------------+-----------+
| NameLen (1 byte) |
+--------------------+-----------+
| Zone Name (variable size) |
+--------------------------------+
"Default Language" (D) bit:
If set, indicates a preference that the name in the following language
should be used if no name is available in a desired language.
Language tag length (LangLen): 7 bits
The length, in bytes, of the language tag.
Language Tag: (variable size)
The language tag, such as "en-US", indicating the language of the zone name.
Language tags are described in [6].
Draft MZAP October 1998
Name Len: Name Len:
The length, in bytes, of the Zone Name field. The length, in bytes, of the Zone Name field.
The length MUST NOT be zero.
Zone Name: multiple of 8 bits Zone Name: multiple of 8 bits
The Zone Name is an ISO 10646 character string in UTF-8 encoding [4] The Zone Name is an ISO 10646
indicating the name given to the scope zone (eg: ``ISI-West Site''). character string in UTF-8 encoding [4] indicating the name given to the
It should be relatively short and MUST be less than 256 bytes in scope zone (eg: ``ISI-West Site''). It should be relatively short and
length. All the border routers to the same region SHOULD be MUST be less than 256 bytes in length. All the border routers to the
configured to give the same Zone Name, or a zero length string MAY be same region SHOULD be configured to give the same Zone Name, or a zero
given. A zero length string is taken to mean that another router is length string MAY be given. A zero length string is taken to mean
expected to be configured with the zone name. Having ALL the ZBRs that another router is expected to be configured with the zone name.
for a scope zone announce zero length names should be considered an Having ALL the ZBRs for a scope zone announce zero length names
error. should be considered an error.
Padding (if needed): Padding (if needed):
The MZAP header is padded with null bytes until it is 4-byte aligned. The end of the MZAP header is padded with null bytes until it is
4-byte aligned.
3.7.1. Zone Announcement Message 3.7.1. Zone Announcement Message
A Zone Announcement Message has PTYPE=0, and is periodically sent by a A Zone Announcement Message has PTYPE=0, and is periodically sent by a
ZBR for each scope for which it is a border, EXCEPT: ZBR for each scope for which it is a border, EXCEPT:
o the Global Scope o the Global Scope
o the Local Scope o the Local Scope
o the Link-local scope o the Link-local scope
The format of a Zone Announcement Message is shown below: The format of a Zone Announcement Message is shown below:
Draft MZAP August 1998 Draft MZAP October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time | | ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 | | Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 5 skipping to change at page 14, line 5
Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) 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 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 Address of a local zone) through which the ZAM has passed, and IP
addresses of the router that forwarded the packet. The origin router addresses of the router that forwarded the packet. The origin router
fills in the "Local Zone ID Address 0" field when sending the ZAM. 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 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 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 the packet of the zone into which the message is being forwarded, and
Draft MZAP August 1998 Draft MZAP October 1998
its own IP address to the end of this list, and increment ZT 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. accordingly. The zone path is empty which the ZAM is first sent.
Authentication Block: Authentication Block:
If present, this provides information which can be used to If present, this provides information which can be used to
authenticate the sender of the ZAM (i.e. Router Address N, if ZT is 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 non-zero, or Message Origin, if ZT is zero). (TBD: any reason not to
re-use SAP's "Authentication Header" here?) re-use SAP's "Authentication Header" here?)
skipping to change at page 13, line 5 skipping to change at page 15, line 5
| ZT | ZTL | unused | | ZT | ZTL | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 | | Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 | | Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 | | Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... .....
Draft MZAP August 1998 Draft MZAP October 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N | | Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N | | Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields are copied from the ZAM, except PTYPE which is set to one. 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 A router receiving ZLE messages SHOULD log them and attempt to alert the
skipping to change at page 14, line 5 skipping to change at page 16, line 5
| ZBR Address N | | ZBR Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows: The fields are as follows:
Number of ZBR addresses (ZNUM): 8 bits Number of ZBR addresses (ZNUM): 8 bits
This field gives the number of ZBR Addresses contained in this This field gives the number of ZBR Addresses contained in this
message. message.
Hold Time: Hold Time:
The time, in seconds, after which the receiver may assume the sender The time, in seconds, after which the receiver may assume the sender
Draft MZAP August 1998 Draft MZAP October 1998
is no longer reachable, if no subsequent ZCM is received. This is no longer reachable, if no subsequent ZCM is received. This
should be set to [ZCM-HOLDTIME]. should be set to [ZCM-HOLDTIME].
ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) ZBR Address: 32 bits (IPv4) or 128 bits (IPv6)
These fields give the addresses of the other ZBRs from which the These fields give the addresses of the other ZBRs from which the
Message Origin ZBR has received ZCMs but whose hold time has not Message Origin ZBR has received ZCMs but whose hold time has not
expired. The router should include all such addresses which fit in expired. The router should include all such addresses which fit in
the packet, preferring those which it has not included recently if the packet, preferring those which it has not included recently if
all do not fit. all do not fit.
skipping to change at page 15, line 5 skipping to change at page 17, line 5
ZCMs are sent. A Zone Border Router listens to the relative group in 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. each scope for which it is a border. Value: TBD by IANA.
[ZAM-INTERVAL]: The interval at which a Zone Border Router originates [ZAM-INTERVAL]: The interval at which a Zone Border Router originates
Zone Announcement Messages. Default value: 600 seconds (10 minutes). Zone Announcement Messages. Default value: 600 seconds (10 minutes).
[ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set [ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set
to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31 to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31
minutes). minutes).
Draft MZAP August 1998 Draft MZAP October 1998
[ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which [ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which
ZAMs for the same scope will not be forwarded. Default value: 30 ZAMs for the same scope will not be forwarded. Default value: 30
seconds. seconds.
[ZCM-INTERVAL]: The interval at which a Zone Border Router originates [ZCM-INTERVAL]: The interval at which a Zone Border Router originates
Zone Convexity Messages. Default value: 600 seconds (10 minutes). Zone Convexity Messages. Default value: 600 seconds (10 minutes).
[ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set [ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set
to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31 to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31
skipping to change at page 16, line 5 skipping to change at page 18, line 5
successfully, but would be unaware that their traffic may be traveling successfully, but would be unaware that their traffic may be traveling
further than they expected. As a result, applications MUST only take further than they expected. As a result, applications MUST only take
scope names as a guideline, and SHOULD assume that their traffic sent to scope names as a guideline, and SHOULD assume that their traffic sent to
non-local scope zones might travel anywhere. The confidentiality of non-local scope zones might travel anywhere. The confidentiality of
such traffic CANNOT be assumed from the fact that it was sent to a such traffic CANNOT be assumed from the fact that it was sent to a
scoped address that was discovered using MZAP. scoped address that was discovered using MZAP.
In addition, ZAMs are used to inform Multicast Address Allocation In addition, ZAMs are used to inform Multicast Address Allocation
Servers of names of scopes, and spoofed ZAMs would result in false names Servers of names of scopes, and spoofed ZAMs would result in false names
Draft MZAP August 1998 Draft MZAP October 1998
being presented to users. To counter this, ZAMs may be authenticated as being presented to users. To counter this, ZAMs may be authenticated as
follows: follows:
(1) A ZBR signs all ZAMs it originates. (1) A ZBR signs all ZAMs it originates.
(2) A ZBR signs a ZAM it forwards if and only if it can authenticate (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 the previous sender. A ZBR MUST still forward un-authenticated
ZAMs (to provide leak detection), but should propagate an ZAMs (to provide leak detection), but should propagate an
autheticated ZAM even if an un-authenticated one was received with autheticated ZAM even if an un-authenticated one was received with
skipping to change at page 16, line 41 skipping to change at page 18, line 41
[3] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast [3] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast
Address Allocation Architecture", Internet Draft, Dec 1997. Address Allocation Architecture", Internet Draft, Dec 1997.
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP [5] Fenner, W., and S. Casner, "A ''traceroute'' facility for IP
Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft, Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, Internet Draft,
November 1997. 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.
Draft MZAP October 1998
8. Full Copyright Statement 8. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included 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 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 may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
skipping to change at page 17, line 35 skipping to change at page 19, line 44
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 Overview ........................................................ 3 2 Overview ........................................................ 3
3 Usage ........................................................... 6 3 Usage ........................................................... 6
3.1 Zone IDs ...................................................... 6 3.1 Zone IDs ...................................................... 6
3.2 Informing internal entities of scopes ......................... 6 3.2 Informing internal entities of scopes ......................... 6
3.3 Detecting non-convex scope zones .............................. 7 3.3 Detecting non-convex scope zones .............................. 7
3.4 Detecting leaky boundaries for non-local scopes ............... 7 3.4 Detecting leaky boundaries for non-local scopes ............... 7
3.5 Detecting a leaky Local Scope zone ............................ 8 3.5 Detecting a leaky Local Scope zone ............................ 8
3.6 Detecting conflicting scope zones ............................. 8 3.6 Detecting conflicting scope zones ............................. 8
3.7 Packet Formats ................................................ 8 3.7 Packet Formats ................................................ 9
3.7.1 Zone Announcement Message ................................... 10 3.7.1 Zone Announcement Message ................................... 12
3.7.2 Zone Limit Exceeded (ZLE) ................................... 12 3.7.2 Zone Limit Exceeded (ZLE) ................................... 14
3.7.3 Zone Convexity Message ...................................... 13 3.7.3 Zone Convexity Message ...................................... 15
4 Message Timing .................................................. 14 4 Message Timing .................................................. 16
5 Constants ....................................................... 14 5 Constants ....................................................... 16
6 Security Considerations ......................................... 15
7 References ...................................................... 16 Draft MZAP October 1998
8 Full Copyright Statement ........................................ 16
6 Security Considerations ......................................... 17
7 References ...................................................... 18
8 Full Copyright Statement ........................................ 19
 End of changes. 

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