draft-ietf-mmusic-mbus-transport-05.txt   draft-ietf-mmusic-mbus-transport-06.txt 
Network Working Group Ott Network Working Group Ott
Internet-Draft TZI, Universitaet Bremen Internet-Draft TZI, Universitaet Bremen
Expires: November 7, 2001 Perkins Expires: November 28, 2001 Perkins
USC Information Sciences Institute USC Information Sciences Institute
Kutscher Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
May 9, 2001 May 30, 2001
A Message Bus for Local Coordination A Message Bus for Local Coordination
draft-ietf-mmusic-mbus-transport-05.txt draft-ietf-mmusic-mbus-transport-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 7, 2001.
This Internet-Draft will expire on November 28, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The local Message Bus (Mbus) is a simple message-oriented The local Message Bus (Mbus) is a simple message-oriented
coordination infrastructure for group communication within groups of coordination infrastructure for group communication within groups of
co-located communication peers. The Mbus provides automatic location co-located communication peers. The Mbus provides automatic location
skipping to change at page 6, line 38 skipping to change at page 6, line 38
1.4 Areas of Application 1.4 Areas of Application
The Mbus prototol can be deployed in many different application The Mbus prototol can be deployed in many different application
areas, including but not limited to: areas, including but not limited to:
Local conference control: In the Mbone community a model has arisen Local conference control: In the Mbone community a model has arisen
whereby a set of loosely coupled tools are used to participate in whereby a set of loosely coupled tools are used to participate in
a conference. A typical scenario is that audio, video and shared a conference. A typical scenario is that audio, video and shared
workspace functionality is provided by three separate tools workspace functionality is provided by three separate tools
(although some combined tools exist). This maps well onto the (although some combined tools exist). This maps well onto the
underlying RTP [7] (as well as other) media streams, which are underlying RTP [8] (as well as other) media streams, which are
also transmitted separately. Given such an architecture, it is also transmitted separately. Given such an architecture, it is
useful to be able to perform some coordination of the separate useful to be able to perform some coordination of the separate
media tools. For example, it may be desirable to communicate media tools. For example, it may be desirable to communicate
playout-point information between audio and video tools, in order playout-point information between audio and video tools, in order
to implement lip-synchronisation, to arbitrate the use of shared to implement lip-synchronisation, to arbitrate the use of shared
resources (such as input devices), etc. resources (such as input devices), etc.
A refinement of this architecture relies on the presence of a A refinement of this architecture relies on the presence of a
number of media engines which perform protocol functions as well number of media engines which perform protocol functions as well
as capturing and playout of media. In addition, one (or more) as capturing and playout of media. In addition, one (or more)
skipping to change at page 8, line 7 skipping to change at page 8, line 7
1.5 Terminology for requirement specifications 1.5 Terminology for requirement specifications
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119[1] and and "OPTIONAL" are to be interpreted as described in RFC 2119[1] and
indicate requirement levels for compliant Mbus implementations. indicate requirement levels for compliant Mbus implementations.
2. Common Formal Syntax Rules 2. Common Formal Syntax Rules
This section contains some definitions of common ABNF [12] syntax This section contains some definitions of common ABNF [13] syntax
elements that are later referenced by other definitions in this elements that are later referenced by other definitions in this
document: document:
base64 = base64_terminal / base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] ) ( 1*(4base64_CHAR) [base64_terminal] )
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive ;; Case-sensitive
base64_terminal = (2base64_char "==") / (3base64_char "=") base64_terminal = (2base64_char "==") / (3base64_char "=")
skipping to change at page 9, line 10 skipping to change at page 9, line 10
; linefeed ; linefeed
LWSP = *(WSP / CRLF WSP) LWSP = *(WSP / CRLF WSP)
; linear white space (past newline) ; linear white space (past newline)
SP = %x20 SP = %x20
; space ; space
WSP = SP / HTAB WSP = SP / HTAB
; white space ; white space
Taken from RFC 2234 [12] and RFC 2554 [13]. Taken from RFC 2234 [13] and RFC 2554 [14].
3. Message Format 3. Message Format
A Mbus message comprises a header and a body. The header is used to A Mbus message comprises a header and a body. The header is used to
indicate how and where a message should be delivered, the body indicate how and where a message should be delivered, the body
provides information and commands to the destination entity. The provides information and commands to the destination entity. The
following information is included in the header: following information is included in the header:
A fixed ProtocolID field identifies the version of the message A fixed ProtocolID field identifies the version of the message
bus protocol used. The protocol defined in this document is bus protocol used. The protocol defined in this document is
skipping to change at page 12, line 27 skipping to change at page 12, line 27
set of address elements. set of address elements.
4.1 Mandatory Address Elements 4.1 Mandatory Address Elements
Each Mbus entity MUST provide one mandatory address element that Each Mbus entity MUST provide one mandatory address element that
allows to identify the entity. The element name is "id" and the allows to identify the entity. The element name is "id" and the
value MUST be be composed of the following components: value MUST be be composed of the following components:
o The IP address of the interface that is used for sending messages o The IP address of the interface that is used for sending messages
to the Mbus. For IPv4 this the address in decimal dotted to the Mbus. For IPv4 this the address in decimal dotted
notation. For IPv6 the interface-ID-part of an address in textual notation. For IPv6 the interface-ID-part of the node's link-local
representation as specified in RFC 2373[3] MUST be used. In this address in textual representation as specified in RFC 2373[3]
specification, this part is called the "host-ID". MUST be used. In this specification, this part is called the
"host-ID".
o An identifier ("entity-ID") that is unique within the scope of a o An identifier ("entity-ID") that is unique within the scope of a
single host-ID. The entity comprises two parts. For systems where single host-ID. The entity comprises two parts. For systems where
the concept of a process ID is applicable it is RECOMMENDED this the concept of a process ID is applicable it is RECOMMENDED this
identifier be composed using a process-ID and a per-process identifier be composed using a process-ID and a per-process
disambiguator for different Mbus entities of a process. If a disambiguator for different Mbus entities of a process. If a
process ID is not available, this part of the entity-ID may be process ID is not available, this part of the entity-ID may be
randomly chosen (it is recommended that at least a 32 bit random randomly chosen (it is recommended that at least a 32 bit random
number is chosen). Both numbers are represented in decimal number is chosen). Both numbers are represented in decimal
textual form and MUST be separated by a '-' (ASCII x2d) textual form and MUST be separated by a '-' (ASCII x2d)
skipping to change at page 14, line 37 skipping to change at page 14, line 37
SeqNum = 1*10DIGIT SeqNum = 1*10DIGIT
TimeStamp = 1*13DIGIT TimeStamp = 1*13DIGIT
MessageType = "R" / "U" MessageType = "R" / "U"
ScrAddr = mbus_address ScrAddr = mbus_address
DestAddr = mbus_address DestAddr = mbus_address
AckList = "(" *(1*DIGIT)) ")" AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")"
See Section 4 for a definition of "mbus_address". See Section 4 for a definition of "mbus_address".
The syntax definition of a complete message is as follows: The syntax definition of a complete message is as follows:
mbus_message = msg_header *1(CRLF msg_payload) mbus_message = msg_header *1(CRLF msg_payload)
msg_payload = mbus_command *(CRLF mbus_command) msg_payload = mbus_command *(CRLF mbus_command)
The definition of production rules for an Mbus command is given in The definition of production rules for an Mbus command is given in
skipping to change at page 15, line 23 skipping to change at page 15, line 23
val = Integer / Float / String / List / Symbol / Data val = Integer / Float / String / List / Symbol / Data
Integer = *1"-" 1*DIGIT Integer = *1"-" 1*DIGIT
Float = *1"-" 1*DIGIT "." 1*DIGIT Float = *1"-" 1*DIGIT "." 1*DIGIT
String = DQUOTE *CHAR DQUOTE String = DQUOTE *CHAR DQUOTE
; see below for escape characters ; see below for escape characters
List = "(" *WSP *(val *(1*WSP val)) *WSP ")" List = "(" *WSP *1(val *(1*WSP val)) *WSP ")"
Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" / ".") Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" / ".")
Data = "<" *base64 ">" Data = "<" *base64 ">"
Boolean values are encoded as an integer, with the value of zero Boolean values are encoded as an integer, with the value of zero
representing false, and non-zero representing true. representing false, and non-zero representing true.
String parameters in the payload MUST be enclosed in the double String parameters in the payload MUST be enclosed in the double
quote (") character. Within strings, the escape character is the quote (") character. Within strings, the escape character is the
skipping to change at page 15, line 47 skipping to change at page 15, line 47
|Escape Sequence | Meaning | |Escape Sequence | Meaning |
+----------------+-----------+ +----------------+-----------+
| \\ | \ | | \\ | \ |
| \" | " | | \" | " |
| \n | newline | | \n | newline |
+----------------+-----------+ +----------------+-----------+
List parameters do not have to be homogeneous lists, i.e. they can List parameters do not have to be homogeneous lists, i.e. they can
contain parameters of different types. contain parameters of different types.
Opaque data is represented as Base64-encoded (see RFC1521[6]) Opaque data is represented as Base64-encoded (see RFC1521[7])
character strings surrounded by "< " and "> " character strings surrounded by "< " and "> "
The ABNF syntax definition for Mbus commands is as follows: The ABNF syntax definition for Mbus commands is as follows:
mbus_command = command_name arglist mbus_command = command_name arglist
command_name = Symbol command_name = Symbol
arglist = List arglist = List
skipping to change at page 18, line 13 skipping to change at page 18, line 13
addresses and also provides a specification of how an Mbus session addresses and also provides a specification of how an Mbus session
can be configured to use non-standard, unassigned addresses (see can be configured to use non-standard, unassigned addresses (see
Section 12). Section 12).
An Mbus session can be configured to use either one of the mentioned An Mbus session can be configured to use either one of the mentioned
scopes. The following sections specify the use of multicast scopes. The following sections specify the use of multicast
addresses for IPv4 and IPv6. addresses for IPv4 and IPv6.
6.1.1 Mbus multicast groups for IPv4 6.1.1 Mbus multicast groups for IPv4
For IPv4, there are two potential address ranges for "local scope" For IPv4, a statically assigned, scope relative multicast address as
multicast that could be considered for the Mbus multicast address: defined by RFC 2365[11] is used. The offset for the scope relative
address for Mbus is 8 (MBUS, see
The IPv4 Local Scope -- 239.255.0.0/16 239.255.0.0/16 is the minimal http://www.iana.org/assignments/multicast-addresses[20]).
enclosing scope for administratively scoped multicast (as defined
by RFC 2365[10]) and not further divisible -- its exact extent is
site dependent. Allocating a statically assigned address in this
scope would require to allocate a scope relative multicast
address (the high order /24 in every scoped region is reserved
for relative assignments), because the main address space is to
be assigned dynamically, e.g. by using address allocation
protocols.
The IPv4 statically assigned link-local scope -- 224.0.0.0/24 Different scopes are defined by RFC 2365[11]. The IPv4 Local Scope
224.0.0.0/24 is the address range for statically assigned (239.255.0.0/16) is the minimal enclosing scope for administratively
multicast address for link-local multicast. Multicast routers scoped multicast (as defined by RFC 2365[11]) and not further
should not forward any multicast datagram with destination divisible -- its exact extent is site dependent.
addresses in this range, regardless of its TTL.
Because of the inexact extent of 239.255.0.0/16 scopes and the fact For the IPv4 Local Scope, applying the rules of RFC 2365[11] and
that the only way to allocate a static address is the use of an using the assigned offset of 8, the Mbus multicast address is
assigned scope relative address the Mbus uses a multicast address therefore 239.255.255.247.
from the statically assigned link-local scope (224.0.0.0/24).
Host-local Mbus scope in an IPv4 environment MUST be implemented by For IPv4, the different defined Mbus scopes (host-local and
using an IPv4 link-local address and an IP-Multicast-TTL of zero. link-local) are to be realizied as follows:
Link-local Mbus scope in an IPv4 environment MUST be implemented by host-local multicast: Unless configured otherwise, the assigned
using an IPv4 link-local Scope address and an IP-Multicast-TTL scope relative Mbus address in the Local Scope (239.255.255.247
greater than zero. A TTL value of 1 SHOULD be used in order to make as of RFC 2365[11]) MUST be used. Mbus UDP datagrams SHOULD be
sure that the link-local scope is not exceeded, e.g., in cases where sent with a TTL of 0.
administratively scoped multicast does not work correctly.
The IPv4 link-local multicast address has yet to be assigned (see link-local multicast: Unless configured otherwise, the assigned
Section 14). scope relative Mbus address in the Local Scope (239.255.255.247
as of RFC 2365[11]) MUST be used. Mbus UDP datagrams SHOULD be
sent with a TTL of 1.
6.1.2 Mbus multicast groups for IPv6 6.1.2 Mbus multicast groups for IPv6
IPv6 has different address ranges for different multicast scopes and IPv6 has different address ranges for different multicast scopes and
distinguishes node local and link local scopes, that are implemented distinguishes node local and link local scopes, that are implemented
as a set of address prefixes for the different address ranges (RFC as a set of address prefixes for the different address ranges (RFC
2373[18]). The link-local prefix is FF02, the node-local prefix is 2373[19]). The link-local prefix is FF02, the node-local prefix is
FF01. A permanently assigned multicast address will be used for Mbus FF01. A permanently assigned multicast address will be used for Mbus
multicast communication, i.e. an address that is independent of the multicast communication, i.e. an address that is independent of the
scope value and that can be used for all scopes. Implementations for scope value and that can be used for all scopes. Implementations for
IPv6 MUST use the scope independent address and the appropriate IPv6 MUST use the scope independent address and the appropriate
prefix for the selected scope. For host-local Mbus communication the prefix for the selected scope. For host-local Mbus communication the
IPv6 node-local scope prefix MUST be used, for link-local Mbus IPv6 node-local scope prefix MUST be used, for link-local Mbus
communication the IPv6 link-local scope prefix MUST be used. communication the IPv6 link-local scope prefix MUST be used.
The permanent IPv6 multicast addresses has yet to be assigned (see The permanent IPv6 multicast addresses has yet to be assigned (see
Section 14). Section 14).
Until an IPv6 multicast address is assigned, FF0X:0:0:0:0:0:0:300
SHOULD be used for Mbus/IPv6 where the X in FF0X indicates that the
scope is not fixed because this is an all scope address. This means,
for node-local scope, FF01:0:0:0:0:0:0:300 SHOULD be used and for
link-local scope FF02:0:0:0:0:0:0:300 SHOULD be used. See RFC2375[4]
for IPv6 multicast address assignements.
If a single application system is distributed across several If a single application system is distributed across several
co-located hosts, link local scope SHOULD be used for multicasting co-located hosts, link local scope SHOULD be used for multicasting
Mbus messages that potentially have recipients on the other hosts. Mbus messages that potentially have recipients on the other hosts.
The Mbus protocol is not intended (and hence deliberately not The Mbus protocol is not intended (and hence deliberately not
designed) for communication between hosts not on the same link. See designed) for communication between hosts not on the same link. See
Section 12 for specifications of Mbus configuration mechanisms. Section 12 for specifications of Mbus configuration mechanisms.
6.1.3 Use of Broadcast 6.1.3 Use of Broadcast
In situations where multicast is not available, broadcast MAY be In situations where multicast is not available, broadcast MAY be
skipping to change at page 32, line 51 skipping to change at page 32, line 51
The algorithms and procedures for applying encryption and The algorithms and procedures for applying encryption and
authentication techniques are specified in the following sections. authentication techniques are specified in the following sections.
11.2 Encryption 11.2 Encryption
Encryption of messages is OPTIONAL, that means, an Mbus MAY be Encryption of messages is OPTIONAL, that means, an Mbus MAY be
configured not to use encryption. configured not to use encryption.
Implementations can choose between different encryption algorithms. Implementations can choose between different encryption algorithms.
Either AES [17], DES [15], 3DES (triple DES) [15] or IDEA [21] Either AES [18], DES [16], 3DES (triple DES) [16] or IDEA [23]
SHOULD be used for encryption. Implementations MUST at least provide SHOULD be used for encryption. Implementations MUST at least provide
AES and it is RECOMMENDED that they support the other algorithms as AES and it is RECOMMENDED that they support the other algorithms as
well. well.
For algorithms requiring en/decryption data to be padded to certain For algorithms requiring en/decryption data to be padded to certain
boundaries octets with a value of 0 SHOULD be used for padding boundaries octets with a value of 0 SHOULD be used for padding
characters. characters.
The length of the encryption keys is determined by the currently The length of the encryption keys is determined by the currently
used encryption algorithm. This means, the configured encryption key used encryption algorithm. This means, the configured encryption key
MUST NOT be shorter than the native key length for the currently MUST NOT be shorter than the native key length for the currently
configured algorithm. configured algorithm.
DES implementations MUST use the DES Cipher Block Chaining (CBC) DES implementations MUST use the DES Cipher Block Chaining (CBC)
mode. DES keys (56 bits) MUST be encoded as 8 octets as described in mode. DES keys (56 bits) MUST be encoded as 8 octets as described in
RFC1423[11], resulting in 12 Base64-encoded characters. IDEA uses RFC1423[12], resulting in 12 Base64-encoded characters. IDEA uses
128-bit keys (24 Base64-encoded characters). AES can use either 128-bit keys (24 Base64-encoded characters). AES can use either
128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES only 128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES only
128-bit keys (24 Base64-encoded characters) MUST be used. 128-bit keys (24 Base64-encoded characters) MUST be used.
11.3 Message Authentication 11.3 Message Authentication
For authentication of messages, hashed message authentication codes For authentication of messages, hashed message authentication codes
(HMACs) as described in RFC2104[4] are deployed. In general, (HMACs) as described in RFC2104[5] are deployed. In general,
implementations can choose between a number of digest algorithms. implementations can choose between a number of digest algorithms.
For Mbus authentication, the HMAC algorithm MUST be applied in the For Mbus authentication, the HMAC algorithm MUST be applied in the
following way: following way:
The keyed hash value is calculated using the HMAC algorithm The keyed hash value is calculated using the HMAC algorithm
specified in RFC2104[4]. The concrete hash algorithm and the specified in RFC2104[5]. The concrete hash algorithm and the
secret hash key MUST be obtained from the Mbus configuration (see secret hash key MUST be obtained from the Mbus configuration (see
Section 12). Section 12).
The keyed hash values (see RFC2104[4]) MUST be truncated to 96 The keyed hash values (see RFC2104[5]) MUST be truncated to 96
bits (12 octets). bits (12 octets).
Subsequently, the resulting 12 octets MUST be Base64-encoded, Subsequently, the resulting 12 octets MUST be Base64-encoded,
resulting in 16 Base64-encoded characters (see RFC1521[6]). resulting in 16 Base64-encoded characters (see RFC1521[7]).
Either MD5 [14] or SHA-1 [16] SHOULD be used for message Either MD5 [15] or SHA-1 [17] SHOULD be used for message
authentication codes (MACs). An implementation MAY provide MD5, authentication codes (MACs). An implementation MAY provide MD5,
whereas SHA-1 MUST be implemented. whereas SHA-1 MUST be implemented.
The length of the hash keys is determined by the selected hashing The length of the hash keys is determined by the selected hashing
algorithm. This means, the configured hash key MUST NOT be shorter algorithm. This means, the configured hash key MUST NOT be shorter
than the native key length for the currently configured algorithm. than the native key length for the currently configured algorithm.
11.4 Procedures for Senders and Receivers 11.4 Procedures for Senders and Receivers
The mandatory subset of algorithms that MUST be provided by The mandatory subset of algorithms that MUST be provided by
skipping to change at page 36, line 11 skipping to change at page 36, line 11
The non-standard UDP port number to use for message transport. The non-standard UDP port number to use for message transport.
Two distinct facilities for parameter storage are considered: For Two distinct facilities for parameter storage are considered: For
Unix-like systems a per-user configuration file SHOULD be used and Unix-like systems a per-user configuration file SHOULD be used and
for Windows-95/98/NT/2000 systems a set of registry entries is for Windows-95/98/NT/2000 systems a set of registry entries is
defined that SHOULD be used. For other systems it is RECOMMENDED defined that SHOULD be used. For other systems it is RECOMMENDED
that the file-based configuration mechanism is used. that the file-based configuration mechanism is used.
The syntax of the values for the respective parameter entries The syntax of the values for the respective parameter entries
remains the same for both configuration facilities. The following remains the same for both configuration facilities. The following
defines a set of ABNF (see RFC2234[12]) productions that are later defines a set of ABNF (see RFC2234[13]) productions that are later
re-used for the definitions for the configuration file syntax and re-used for the definitions for the configuration file syntax and
registry entries: registry entries:
algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" / algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
"HMAC-MD5-96" / "HMAC-SHA1-96" "HMAC-MD5-96" / "HMAC-SHA1-96"
scope = "HOSTLOCAL" / "LINKLOCAL" scope = "HOSTLOCAL" / "LINKLOCAL"
key = base64 key = base64
skipping to change at page 36, line 40 skipping to change at page 36, line 40
Given the definition above, a key entry MUST be specified using this Given the definition above, a key entry MUST be specified using this
notation: notation:
"("algo-id","base64string")" "("algo-id","base64string")"
algo-id is one of the character strings specified above. For algo-id is one of the character strings specified above. For
algo-id==``NOENCR'' the other fields are ignored. The delimiting algo-id==``NOENCR'' the other fields are ignored. The delimiting
commas MUST always be present though. commas MUST always be present though.
A Base64 string consists of the characters defined in the Base64 A Base64 string consists of the characters defined in the Base64
char-set (see RFC1521[6]) including all eventual padding characters, char-set (see RFC1521[7]) including all eventual padding characters,
i.e. the length of a Base64-string is always a multiple of 4. i.e. the length of a Base64-string is always a multiple of 4.
The scope parameter is used to configure an IP-Multicast scope and The scope parameter is used to configure an IP-Multicast scope and
may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations
SHOULD choose an appropriate IP-Multicast scope depending on the SHOULD choose an appropriate IP-Multicast scope depending on the
value of this parameter and construct an effective IP-Address value of this parameter and construct an effective IP-Address
considering the specifications of Section 6.1. considering the specifications of Section 6.1.
The use of broadcast is configured by providing the value The use of broadcast is configured by providing the value
"BROADCAST" for the address field. If broadcast has been configured, "BROADCAST" for the address field. If broadcast has been configured,
skipping to change at page 40, line 7 skipping to change at page 40, line 7
implementations that do not conform to RFC 1122[2] and do send implementations that do not conform to RFC 1122[2] and do send
datagrams with TTL values of zero, resulting in Mbus messages sent datagrams with TTL values of zero, resulting in Mbus messages sent
to the local network link although a user might have selected host to the local network link although a user might have selected host
local scope in the Mbus configuration. When using of local scope in the Mbus configuration. When using of
administratively scoped multicast users cannot always assume the administratively scoped multicast users cannot always assume the
presence of correctly configured boundary routers. In these cases presence of correctly configured boundary routers. In these cases
the use of encryption SHOULD be considered if privacy is desired. the use of encryption SHOULD be considered if privacy is desired.
14. IANA Considerations 14. IANA Considerations
The IANA is requested to assign a link-local IPv4 multicast address The IANA has assigned a scope-relative multicast address with an
from the address space 224.0.0.0/24 and an IPv6 permanent multicast offset of 8 for Mbus/IPv4. The IANA is requested to assign an IPv6
address. For the time being the tentative IPv4 multicast address permanent multicast address. Until the IPv6 is assigned,
239.255.255.247 SHOULD be used. FF0X:0:0:0:0:0:0:300 SHOULD be used for Mbus/IPv6.
The registered Mbus UDP port number is 47000. The registered Mbus UDP port number is 47000.
References References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Braden, R., "Requirements for Internet Hosts -- Communication [2] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC 1122, October 1989. Layers", RFC 1122, October 1989.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing [4] Hinden, R.M. and S.E. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[5] Crocker, D.H., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT [6] Crocker, D.H., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
MESSAGES", August 1982. MESSAGES", August 1982.
[6] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail [7] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September the Format of Internet Message Bodies", RFC 1521, September
1993. 1993.
[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 1889, January 1996.
[8] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, [9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999. "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley, M. and V. Jacobsen, "SDP: Session Description [10] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[10] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, [11] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
July 1998. July 1998.
[11] Balenson, D., "Privacy Enhancement for Internet Electronic [12] Balenson, D., "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423,
February 1993. February 1993.
[12] Crocker, D. and P. Overell, "Augmented BNF for Syntax [13] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[13] Myers, J., "SMTP Service Extension for Authentication", RFC [14] Myers, J., "SMTP Service Extension for Authentication", RFC
2554, March 1999. 2554, March 1999.
[14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[15] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards [16] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards
and Technology, "Data Encryption Standard (DES)", FIPS PUB and Technology, "Data Encryption Standard (DES)", FIPS PUB
46-3, Category Computer Security, Subcategory Cryptography, 46-3, Category Computer Security, Subcategory Cryptography,
October 1999. October 1999.
[16] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards [17] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards
and Technology, "Secure Hash Standard", FIPS PUB 180-1, April and Technology, "Secure Hash Standard", FIPS PUB 180-1, April
1995. 1995.
[17] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March [18] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March
1999. 1999.
[18] Hinden, R.M. and S.E. Deering, "IP Version 6 Addressing [19] Hinden, R.M. and S.E. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[19] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The [20] IANA, "INTERNET MULTICAST ADDRESSES", URL
http://www.iana.org/assignments/multicast-addresses, May 2001.
[21] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The
Internet Multimedia Conferencing Architecture", Internet Draft Internet Multimedia Conferencing Architecture", Internet Draft
draft-ietf-mmusic-confarch-03.txt, status: non-normative, July draft-ietf-mmusic-confarch-03.txt, status: non-normative, July
2000. 2000.
[20] Ott, J., Perkins, C. and D. Kutscher, "Requirements for Local [22] Ott, J., Perkins, C. and D. Kutscher, "Requirements for Local
Conference Control", Internet Draft Conference Control", Internet Draft
draft-ietf-mmusic-mbus-req-00.txt, status: non-normative, draft-ietf-mmusic-mbus-req-00.txt, status: non-normative,
December 1999. December 1999.
[21] Schneier, B., "Applied Cryptography", Edition 2, Publisher [23] Schneier, B., "Applied Cryptography", Edition 2, Publisher
John Wiley & Sons, Inc., status: non-normative, 1996. John Wiley & Sons, Inc., status: non-normative, 1996.
[22] distributed.net, "Project DES", WWW [24] distributed.net, "Project DES", WWW
http://www.distributed.net/des/, status: non-normative, 1999. http://www.distributed.net/des/, status: non-normative, 1999.
Authors' Addresses Authors' Addresses
Joerg Ott Joerg Ott
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
 End of changes. 

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