< draft-ietf-malloc-madcap-03.txt   draft-ietf-malloc-madcap-04.txt >
MALLOC working group Baiju V. Patel, Intel Corp. MALLOC working group Baiju V. Patel, Intel Corp.
Internet Draft Munil Shah, Microsoft Corp. Internet Draft Munil Shah, Microsoft Corp.
January 1999 Stephen R. Hanna, Sun Microsystems, Inc. February 1999 Stephen R. Hanna, Sun Microsystems, Inc.
Expires: July 1999 draft-ietf-malloc-madcap-03.txt Expires: August 1999 draft-ietf-malloc-madcap-04.txt
Multicast Address Dynamic Client Allocation Protocol (MADCAP) Multicast Address Dynamic Client Allocation Protocol (MADCAP)
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its Areas, all provisions of Section 10 of RFC 2026.
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 Internet-Drafts are working documents of the Internet Engineering
months. Internet Drafts may be updated, replaced, or obsoleted by Task Force (IETF), its areas, and its working groups. Note that
other documents at any time. It is not appropriate to use Internet other groups may also distribute working documents as Internet-
Drafts as reference material or to cite them other than as a "working Drafts.
draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the Internet-Drafts are draft documents valid for a maximum of six months
1id-abstracts.txt listing contained in the Internet-Drafts Shadow and may be updated, replaced, or obsoleted by other documents at any
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or time. It is inappropriate to use Internet- Drafts as reference
munnari.oz.au. material or to cite them other than as "work in progress."
A revised version of this draft document will be submitted to the RFC The list of current Internet-Drafts can be accessed at
editor as a Proposed Standard for the Internet Community. Discussion http://www.ietf.org/ietf/1id-abstracts.txt.
and suggestions for improvement are requested. This document will
expire before June 1999. Distribution of this draft is unlimited. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a protocol, Multicast Address Dynamic Client This document defines a protocol, Multicast Address Dynamic Client
Allocation Protocol (MADCAP), that allows hosts to request multicast Allocation Protocol (MADCAP), that allows hosts to request multicast
addresses from multicast address allocation servers. addresses from multicast address allocation servers.
1. Introduction 1. Introduction
Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a
protocol that allows hosts to request multicast address allocation protocol that allows hosts to request multicast address allocation
services from multicast address allocation servers. This protocol is services from multicast address allocation servers. This protocol is
part of the Multicast Address Allocation Architecture defined in [5]. part of the Multicast Address Allocation Architecture being defined
However, it may be used separately from the rest of that architecture by the IETF Multicast Address Allocation Working Group. However, it
as appropriate. may be used separately from the rest of that architecture as
appropriate.
1.1. Protocol Overview 1.1. Protocol Overview
MADCAP is built on a client-server model, where hosts request address MADCAP is built on a client-server model, where hosts request address
allocation services from address allocation servers. See Appendix A allocation services from address allocation servers. See Appendix A
for examples of typical protocol exchanges. for examples of typical protocol exchanges.
1.2. Terminology 1.2. Terminology
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. document are to be interpreted as described in RFC 2119.
Throughout the rest of this document, the words "server" or "MADCAP Throughout the rest of this document, the words "server" or "MADCAP
server" refer to a host providing multicast address allocation server" refer to a host providing multicast address allocation
services via MADCAP. The words "client" or "MADCAP client" refer to a services via MADCAP. The words "client" or "MADCAP client" refer to a
host requesting multicast address allocation services via MADCAP. host requesting multicast address allocation services via MADCAP.
1.3. Motivation and Protocol Requirements 1.3. Motivation and Protocol Requirements
For multicast applications to be deployed everywhere, there is a need For multicast applications to be deployed everywhere, there is a need
skipping to change at page 5, line 7 skipping to change at page 4, line 51
be ignored. be ignored.
2.1.2. The msgtype field 2.1.2. The msgtype field
The msgtype field defines the "type" of the MADCAP message. The msgtype field defines the "type" of the MADCAP message.
For more information about this field, see section 2.2. For more information about this field, see section 2.2.
2.1.3. The addrfamily field 2.1.3. The addrfamily field
The addrfamily field defines the default address family (such as IPv4 or The addrfamily field defines the default address family (such as IPv4
IPv6) for this MADCAP message. Unless otherwise specified, all or IPv6) for this MADCAP message. Unless otherwise specified, all
addresses included in the message will be from this family. The set of addresses included in the message will be from this family. The set
address families is defined by the IANA, with IPv4 being 1 and IPv6 of address families is defined by the IANA, with IPv4 being 1 and
being 2. IPv6 being 2.
2.1.4. The xid field 2.1.4. The xid field
The xid field is a transaction id. This is a number chosen by the The xid field is a transaction id. This is a number chosen by the
client so that the combination of xid, msgtype, and Client Identifier client so that the combination of xid, msgtype, and Client Identifier
option value is unique over some short period of time. option value is unique over some short period of time.
The xid field is used by the client and server to associate messages The xid field is used by the client and server to associate messages
and responses between a client and a server. Before a client sends a and responses between a client and a server. Before a client sends a
message, it chooses a number to use as an xid. When the server message, it chooses a number to use as an xid. When the server
skipping to change at page 6, line 26 skipping to change at page 6, line 18
Table 3 and elsewhere in this document. They MAY also include other Table 3 and elsewhere in this document. They MAY also include other
MADCAP options that are defined in the future. A MADCAP client or MADCAP options that are defined in the future. A MADCAP client or
server MUST NOT include more than one option with the same option server MUST NOT include more than one option with the same option
type in one MADCAP message. type in one MADCAP message.
All MADCAP clients and servers MUST recognize all options listed in All MADCAP clients and servers MUST recognize all options listed in
this document and behave in accordance with this document when this document and behave in accordance with this document when
receiving and processing any of these options. Any unrecognized receiving and processing any of these options. Any unrecognized
options MUST be ignored. If a message is received that does not options MUST be ignored. If a message is received that does not
conform to the requirements of this document (for instance, not conform to the requirements of this document (for instance, not
including all required options) it MUST be ignored.The order of options including all required options) it MUST be ignored. The order of
within a message has no significance and any order MUST be supported options within a message has no significance and any order MUST be
in an equivalent manner, with the exception that the End option must supported in an equivalent manner, with the exception that the End
occur once per message, as the last option in the option field. option must occur once per message, as the last option in the option
field.
New MADCAP options may only be defined by IETF Consensus, as New MADCAP options may only be defined by IETF Consensus, as
described in [12]. Basically, this means that they are defined by described in [7]. Basically, this means that they are defined by RFCs
RFCs approved by the IESG. approved by the IESG.
2.2. Message Types 2.2. Message Types
The msgtype field defines the "type" of a MADCAP message. Legal The msgtype field defines the "type" of a MADCAP message. Legal
values for this field are: values for this field are:
Value Message Type Value Message Type
----- ------------ ----- ------------
1 DISCOVER 1 DISCOVER
2 OFFER 2 OFFER
skipping to change at page 7, line 9 skipping to change at page 6, line 50
6 NAK 6 NAK
7 RELEASE 7 RELEASE
8 INFORM 8 INFORM
Table 2: MADCAP message types Table 2: MADCAP message types
Throughout this document, MADCAP messages will be referred to by the Throughout this document, MADCAP messages will be referred to by the
type of the message; e.g., a MADCAP message with a message type of 0 type of the message; e.g., a MADCAP message with a message type of 0
will be referred to as an INFORM message. will be referred to as an INFORM message.
Here are descriptions of the MADCAP message types. Table 3, which Here are descriptions of the MADCAP message types. Table 3, which
appears at the end of this section, summarizes which options are appears at the end of this section, summarizes which options are
allowed with each message type. allowed with each message type.
MADCAP clients and servers MUST handle all MADCAP message types MADCAP clients and servers MUST handle all MADCAP message types
defined in this document in a manner consistent with this document. defined in this document in a manner consistent with this document.
If a client or server receives a message whose message type it does If a client or server receives a message whose message type it does
not recognize, it MUST ignore this message. Note, however, that not recognize, it MUST ignore this message. Note, however, that under
under some circumstances this document requires or suggests that some circumstances this document requires or suggests that clients or
clients or servers ignore certain messages. For instance, clients servers ignore certain messages. For instance, clients that do not
that do not send DISCOVER messages SHOULD ignore OFFER messages. send DISCOVER messages SHOULD ignore OFFER messages. Also, secure
Also, secure servers SHOULD ignore DISCOVER messages and all servers servers SHOULD ignore DISCOVER messages and all servers SHOULD ignore
SHOULD ignore DISCOVER or INFORM messages that they cannot satisfy. DISCOVER or INFORM messages that they cannot satisfy.
New MADCAP message types may only be defined by IETF Consensus, as New MADCAP message types may only be defined by IETF Consensus, as
described in [12]. Basically, this means that they are defined by described in [7]. Basically, this means that they are defined by RFCs
RFCs approved by the IESG. approved by the IESG.
2.2.1. INFORM 2.2.1. INFORM
The INFORM message is used by a MADCAP client that wants to acquire The INFORM message is used by a MADCAP client that wants to acquire
configuration parameters, especially a multicast scope list. This configuration parameters, especially a multicast scope list. This
message also allows a client to determine which servers are likely to message also allows a client to determine which servers are likely to
be able to handle future requests. be able to handle future requests.
The MADCAP client sends out an INFORM message. The message may be The MADCAP client sends out an INFORM message. The message may be
unicast to a particular MADCAP server or multicast to a MADCAP Server unicast to a particular MADCAP server or multicast to a MADCAP Server
skipping to change at page 8, line 23 skipping to change at page 8, line 23
multicast INFORM message, caching an IP address that worked in the multicast INFORM message, caching an IP address that worked in the
past or obtaining a DNS name or IP address from DHCP or prior past or obtaining a DNS name or IP address from DHCP or prior
configuration. Using the DISCOVER message has the particular configuration. Using the DISCOVER message has the particular
advantage that it allows clients to automatically move to another advantage that it allows clients to automatically move to another
server if one fails. server if one fails.
The MADCAP client begins by sending a multicast DISCOVER message to a The MADCAP client begins by sending a multicast DISCOVER message to a
MADCAP Server Multicast Address. Any servers that wish to assist the MADCAP Server Multicast Address. Any servers that wish to assist the
client respond by sending a unicast OFFER message to the client. If a client respond by sending a unicast OFFER message to the client. If a
server can process the request with a shorter lease time or later server can process the request with a shorter lease time or later
start time than the client requested, it MAY send an OFFER message start time than the client requested, it SHOULD send an OFFER message
with the lease time or start time that it can offer. with the lease time or start time that it can offer. However, it
However, it MUST NOT offer a lease time shorter than the minimum MUST NOT offer a lease time shorter than the minimum lease time
lease time specified by the client or a start time later than the specified by the client or a start time later than the maximum start
maximum start time specified by the client. time specified by the client.
For more details about the MADCAP Server Multicast Address, see For more details about the MADCAP Server Multicast Address, see
section 2.9. section 2.9.
After a suitable delay [DISCOVER-DELAY], the client MAY select the After a suitable delay [DISCOVER-DELAY], the client MAY select the
server it wants to use (if any) and send a multicast REQUEST message server it wants to use (if any) and send a multicast REQUEST message
identifying that server. See section 2.2.4 for more information about identifying that server. See section 2.2.4 for more information about
the REQUEST message. the REQUEST message.
The value of [DISCOVER-DELAY] and the mechanism used by the client in The value of [DISCOVER-DELAY] and the mechanism used by the client in
selecting the server it wants to use are implementation dependent. selecting the server it wants to use are implementation dependent.
When a MADCAP client sends a DISCOVER message, it MAY include the When a MADCAP client sends a DISCOVER message, it MAY include the
Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, Lease Time, Minimum Lease Time, Start Time, Maximum Start Time,
Number of Addresses Requested, and List of Address Ranges options, Number of Addresses Requested, and List of Address Ranges options,
describing the addresses it wants to receive. However, it need not describing the addresses it wants to receive. However, it need not
include any of these options. If one of these options is not included, include any of these options. If one of these options is not
the server will provide the appropriate default (maximum available for included, the server will provide the appropriate default (maximum
Lease Time, no minimum for Minimum Lease Time, as soon as possible for available for Lease Time, no minimum for Minimum Lease Time, as soon
Start Time, no maximum for Maximum Start Time, one for Number of as possible for Start Time, no maximum for Maximum Start Time, one
Addresses Requested, and any addresses available for List of Address for Number of Addresses Requested, and any addresses available for
Ranges). The Multicast Scope option MUST be included in the DISCOVER List of Address Ranges). The Multicast Scope option MUST be included
message so that the server knows what scope should be used. The Current in the DISCOVER message so that the server knows what scope should be
Time option MUST be included if the Start Time or Maximum Start Time used. The Current Time option MUST be included if the Start Time or
options are included. Maximum Start Time options are included.
If a client sends a DISCOVER message and does not receive any OFFER If a client sends a DISCOVER message and does not receive any OFFER
messages after an appropriate delay, the client MAY retransmit its messages after an appropriate delay, the client MAY retransmit its
DISCOVER message, as described in section 2.3. DISCOVER message, as described in section 2.3.
2.2.3. OFFER 2.2.3. OFFER
The OFFER message is a unicast message sent by a MADCAP server in The OFFER message is a unicast message sent by a MADCAP server in
response to a DISCOVER message that it can probably satisfy. response to a DISCOVER message that it can probably satisfy.
skipping to change at page 9, line 27 skipping to change at page 9, line 31
the Lease Time and Multicast Scope options, describing the addresses the Lease Time and Multicast Scope options, describing the addresses
it is willing to provide. However, it need not include the List of it is willing to provide. However, it need not include the List of
Address Ranges option. If the List of Address Ranges Allocated option Address Ranges option. If the List of Address Ranges Allocated option
is not included, it is assumed that the server is willing to provide is not included, it is assumed that the server is willing to provide
the number of addresses that the client requested. If the Start Time the number of addresses that the client requested. If the Start Time
option is not included, it is assumed that the server is willing to option is not included, it is assumed that the server is willing to
provide the start time requested by the client (if any). The Current provide the start time requested by the client (if any). The Current
Time option MUST be included if the Start Time option is included. Time option MUST be included if the Start Time option is included.
If a server can process the request with a shorter lease time or If a server can process the request with a shorter lease time or
later start time than the client requested, it MAY send an OFFER later start time than the client requested, it SHOULD send an OFFER
message with the lease time or start time that it can offer. message with the lease time or start time that it can offer.
However, it MUST NOT offer a lease time shorter than the minimum However, it MUST NOT offer a lease time shorter than the minimum
lease time specified by the client or a start time later than the lease time specified by the client or a start time later than the
maximum start time specified by the client. maximum start time specified by the client.
If the server sends an OFFER message, it SHOULD attempt to hold If the server sends an OFFER message, it SHOULD attempt to hold
enough addresses to complete the transaction. If it receives a enough addresses to complete the transaction. If it receives a
multicast REQUEST message with the same xid and Client Identifier multicast REQUEST message with the same xid and Client Identifier
option as the DISCOVER message for which it is holding these option as the DISCOVER message for which it is holding these
addresses and a Server Identifier option that does not match its own, addresses and a Server Identifier option that does not match its own,
skipping to change at page 10, line 14 skipping to change at page 10, line 19
existing lease. The RENEW message is used for that. existing lease. The RENEW message is used for that.
If a REQUEST message is completing a transaction initiated by a If a REQUEST message is completing a transaction initiated by a
DISCOVER message, the following procedure MUST be followed so that DISCOVER message, the following procedure MUST be followed so that
all MADCAP servers know which server was selected. The same xid value all MADCAP servers know which server was selected. The same xid value
used in the DISCOVER message MUST be used in the REQUEST message. used in the DISCOVER message MUST be used in the REQUEST message.
Also, the Server Identifier option MUST be included, using the Server Also, the Server Identifier option MUST be included, using the Server
Identifier of the server selected. Also, the REQUEST message MUST be Identifier of the server selected. Also, the REQUEST message MUST be
multicast to the MADCAP Server Multicast Address. multicast to the MADCAP Server Multicast Address.
Otherwise, the REQUEST message MUST be unicast to the MADCAP server If a REQUEST message is not completing a transaction initiated by a
that the client wants to use. In this case, the Server Identifier DISCOVER message, the REQUEST message MUST be unicast to the MADCAP
option MAY be included, but need not be. server that the client wants to use. In this case, the Server
Identifier option MAY be included, but need not be.
If the selected server can process the request successfully, it If the selected server can process the request successfully, it
SHOULD unicast an ACK message to the client. Otherwise, it SHOULD SHOULD unicast an ACK message to the client. Otherwise, it SHOULD
unicast an NAK to the client. If a server can process the request unicast an NAK to the client. If a server can process the request
with a shorter lease time or later start time than the client with a shorter lease time or later start time than the client
requested, it MAY send an ACK message with the lease time or start requested, it SHOULD send an ACK message with the lease time or start
time that it can offer. However, it MUST NOT offer a lease time time that it can offer. However, it MUST NOT offer a lease time
shorter than the minimum lease time specified by the client or a shorter than the minimum lease time specified by the client or a
start time later than the maximum start time specified by the client. start time later than the maximum start time specified by the client.
When a MADCAP client sends a REQUEST message, it MAY include the When a MADCAP client sends a REQUEST message, it MAY include the
Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, Lease Time, Minimum Lease Time, Start Time, Maximum Start Time,
Number of Addresses Requested, and List of Address Ranges options, Number of Addresses Requested, and List of Address Ranges options,
describing the addresses it wants to receive. However, it need not describing the addresses it wants to receive. However, it need not
include any of these options. If one of these options is not included, include any of these options. If one of these options is not
the server will provide the appropriate default (maximum available for included, the server will provide the appropriate default (maximum
Lease Time, no minimum for Minimum Lease Time, as soon as possible for available for Lease Time, no minimum for Minimum Lease Time, as soon
Start Time, no maximum for Maximum Start Time, one for Number of as possible for Start Time, no maximum for Maximum Start Time, one
Addresses Requested, and any addresses available for List of Address for Number of Addresses Requested, and any addresses available for
Ranges). The Multicast Scope option MUST be included in the REQUEST List of Address Ranges). The Multicast Scope option MUST be included
message so that the server knows what scope should be used. The Current in the REQUEST message so that the server knows what scope should be
Time option MUST be included if the Start Time or Maximum Start Time used. The Current Time option MUST be included if the Start Time or
options are included. Maximum Start Time options are included.
If a client sends a REQUEST message and does not receive any ACK or If a client sends a REQUEST message and does not receive any ACK or
NAK messages in response after an appropriate delay, the client MAY NAK messages in response after an appropriate delay, the client MAY
resend its REQUEST message, as described in section 2.3. resend its REQUEST message, as described in section 2.3.
If the server responds with a NAK or fails to respond within a If the server responds with a NAK or fails to respond within a
reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the
client MAY try to find another server by sending a DISCOVER message client MAY try to find another server by sending a DISCOVER message
with another xid or sending a REQUEST message with another xid to with another xid or sending a REQUEST message with another xid to
another server. another server.
2.2.5. ACK 2.2.5. ACK
The ACK message is used by a MADCAP server to respond affirmatively The ACK message is used by a MADCAP server to respond affirmatively
to an INFORM, REQUEST, or RELEASE message. to an INFORM, REQUEST, or RELEASE message. The server unicasts the
ACK message to the client from which it received the message to which
it is responding.
The set of options included with an ACK message differs, depending on The set of options included with an ACK message differs, depending on
what sort of message it is responding to. what sort of message it is responding to.
If the ACK message is responding to an INFORM message, it SHOULD If the ACK message is responding to an INFORM message, it SHOULD
include any options requested by the client using the Option Request include any options requested by the client using the Option Request
List option in the INFORM message. If the Option Request List option List option in the INFORM message. If the Option Request List option
was not included in the INFORM message, the server SHOULD include the was not included in the INFORM message, the server SHOULD include the
Multicast Scope List option. Multicast Scope List option.
skipping to change at page 11, line 40 skipping to change at page 11, line 49
As with all messages sent by the server, the xid field MUST match the As with all messages sent by the server, the xid field MUST match the
xid field included in the client request to which this message is xid field included in the client request to which this message is
responding. The Client Identifier option MUST be included, with the responding. The Client Identifier option MUST be included, with the
value matching the one included in the client request. The Server value matching the one included in the client request. The Server
Identifier option MUST be included, with the value being the server's Identifier option MUST be included, with the value being the server's
IP address. And the packet MUST NOT be retransmitted. IP address. And the packet MUST NOT be retransmitted.
2.2.6. NAK 2.2.6. NAK
The NAK message is used by a MADCAP server to respond negatively to a The NAK message is used by a MADCAP server to respond negatively to a
REQUEST, RELEASE, or RENEW message. REQUEST, RELEASE, or RENEW message. The server unicasts the NAK
message to the client from which it received the message to which it
is responding.
As with all messages sent by the server, the xid field MUST match the As with all messages sent by the server, the xid field MUST match the
xid field included in the client request to which this message is xid field included in the client request to which this message is
responding. The Client Identifier option MUST be included, with the responding. The Client Identifier option MUST be included, with the
value matching the one included in the client request. The Server value matching the one included in the client request. The Server
Identifier option MUST be included, with the value being the server's Identifier option MUST be included, with the value being the server's
IP address. And the packet MUST NOT be retransmitted. IP address. And the packet MUST NOT be retransmitted.
2.2.7. RELEASE 2.2.7. RELEASE
skipping to change at page 12, line 25 skipping to change at page 12, line 37
If a client sends a RELEASE message and does not receive any ACK or If a client sends a RELEASE message and does not receive any ACK or
NAK messages in response after an appropriate delay, the client MAY NAK messages in response after an appropriate delay, the client MAY
resend its RELEASE message, as described in section 2.3. resend its RELEASE message, as described in section 2.3.
If the server responds with a NAK or fails to respond within a If the server responds with a NAK or fails to respond within a
reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the
client MAY send a RELEASE message with another xid to another server, client MAY send a RELEASE message with another xid to another server,
provided that the Server Mobility feature was used in the original provided that the Server Mobility feature was used in the original
REQUEST message and that this feature is required for the subsequent REQUEST message and that this feature is required for the subsequent
RELEASE message sent to another server. For more information about the RELEASE message sent to another server. For more information about
Server Mobility feature, see section 2.12.1. the Server Mobility feature, see section 2.12.1.
2.2.8. RENEW 2.2.8. RENEW
The RENEW message is used by a MADCAP client that wants to renew a The RENEW message is used by a MADCAP client that wants to renew a
multicast address lease, changing the lease time or start time. multicast address lease, changing the lease time or start time.
The client unicasts the RENEW message to a MADCAP server. If the The client unicasts the RENEW message to a MADCAP server. If the
server can process the request successfully, it SHOULD unicast an ACK server can process the request successfully, it SHOULD unicast an ACK
message to the client. Otherwise, it SHOULD unicast a NAK to the message to the client. Otherwise, it SHOULD unicast a NAK to the
client. client.
skipping to change at page 15, line 24 skipping to change at page 15, line 49
Minimum Lease Time MUST NOT Minimum Lease Time MUST NOT
Maximum Start Time MUST NOT Maximum Start Time MUST NOT
Table 3: Options allowed in MADCAP messages Table 3: Options allowed in MADCAP messages
2.3. Retransmission 2.3. Retransmission
MADCAP clients are responsible for all message retransmission. The MADCAP clients are responsible for all message retransmission. The
client MUST adopt a retransmission strategy that incorporates an client MUST adopt a retransmission strategy that incorporates an
exponential backoff algorithm to determine the delay between exponential backoff algorithm to determine the delay between
retransmissions. The delay between retransmissions SHOULD be retransmissions. The delay between retransmissions SHOULD be chosen
chosen to allow sufficient time for replies from the server to be to allow sufficient time for replies from the server to be delivered
delivered based on the characteristics of the internetwork between based on the characteristics of the internetwork between the client
the client and the server. and the server.
For example, in a 10Mb/sec Ethernet internetwork, the delay before For example, in a 10Mb/sec Ethernet internetwork, the delay before
the first retransmission SHOULD be at least 4 seconds. The delay the first retransmission SHOULD be at least 4 seconds. The delay
before the next retransmission SHOULD be at least 8 seconds. The before the next retransmission SHOULD be at least 8 seconds. The
retransmission delay SHOULD be doubled with subsequent retransmissions retransmission delay SHOULD be doubled with subsequent
up to a maximum of 64 seconds. The client MAY provide an indication of retransmissions up to a maximum of 64 seconds. The client MAY provide
retransmission attempts to the user as an indication of the progress of an indication of retransmission attempts to the user as an indication
the process. The client MAY halt retransmission at any point. of the progress of the process. The client MAY halt retransmission at
any point.
2.4. The Client Identifier 2.4. The Client Identifier
The Client Identifier option is included in each message sent by an The Client Identifier option is included in each message sent by an
MADCAP client. Its value is used to identify a particular client and MADCAP client. Its value is used to identify a particular client and
MUST be unique across all clients in a multicast address allocation MUST be unique across all clients in a multicast address allocation
domain. In addition, for each lease requested by a client, the client domain. In addition, for each lease requested by a client, the client
must use a different client identifier. This allows the lease to be must use a different client identifier. This allows the lease to be
identified using just the client identifier. identified using just the client identifier.
The first octet of the client identifier is the client identifier type. The first octet of the client identifier is the client identifier
If the client identifier type is 0, the remainder of the client type. If the client identifier type is 0, the remainder of the
identifier client identifier is a long random number (such as 128 bits from a
is a long random number (such as 128 bits from a decent random number decent random number generator). If the client identifier type is 1,
generator). If the client identifier is 1, the remainder of the client the remainder of the client identifier is a two octet IANA-defined
identifier is a two octet IANA-defined address family number, an address address family number, an address from the specified address family,
from the specified address family, and a client-specific identifier (such and a client-specific identifier (such as a sequence number or the
as a sequence number or the current time). current time).
New MADCAP client identifier types may only be defined by IETF Consensus, New MADCAP client identifier types may only be defined by IETF
as described in [12]. Basically, this means that they are defined by RFCs Consensus, as described in [7]. Basically, this means that they are
approved by the IESG. defined by RFCs approved by the IESG.
The MADCAP server does not need to parse the client identifier. It SHOULD The MADCAP server does not need to parse the client identifier. It
use the client identifier only as an opaque identifier, which must be SHOULD use the client identifier only as an opaque identifier, which
unique for each lease. The purpose of defining different client must be unique for each lease. The purpose of defining different
identifier client identifier types is to allow MADCAP clients that already have
types is to allow MADCAP clients that already have a globally unique a globally unique address to avoid the possibility of client ID
address to avoid the possibility of client ID collisions by using this collisions by using this address together with a client-specific
address together with a client-specific identifier. MADCAP clients that identifier. MADCAP clients that do not have a globally unique address
do not have a globally unique address SHOULD use client identifier type SHOULD use client identifier type 0.
0.
In addition to associating client and server messages (along with the In addition to associating client and server messages (along with the
xid field, as described in the next section), the Client Identifier xid field, as described in the next section), the Client Identifier
is used to control who can renew or release a lease. MADCAP servers is used to control who can renew or release a lease. MADCAP servers
MUST require that the client identifier used in a RENEW or RELEASE MUST require that the client identifier used in a RENEW or RELEASE
message match the client identifier used in the initial REQUEST message match the client identifier used in the initial REQUEST
message. If not, the server MUST ignore the message. To provide true message. If not, the server MUST ignore the message. To provide true
security with this technique, the confidentiality of the client security with this technique, the confidentiality of the client
identifier must be maintained by encrypting all messages that contain identifier must be maintained by encrypting all messages that contain
it. it.
skipping to change at page 17, line 12 skipping to change at page 18, line 7
that have joined that group and fall within the same organization as that have joined that group and fall within the same organization as
the sender. the sender.
Different sets of scopes may be in effect at different places in the Different sets of scopes may be in effect at different places in the
network and at different times. Before attempting to allocate an network and at different times. Before attempting to allocate an
address from an administrative scope (other than global or link- address from an administrative scope (other than global or link-
level scope, which are always in effect), a MADCAP client SHOULD level scope, which are always in effect), a MADCAP client SHOULD
determine that the scope is in effect at its location at this time. determine that the scope is in effect at its location at this time.
Several techniques that a MADCAP client may use to determine the set Several techniques that a MADCAP client may use to determine the set
of administrative scopes in effect (the scope list) are: manual of administrative scopes in effect (the scope list) are: manual
configuration, configuration via MADCAP (using the Multicast Scope configuration or configuration via MADCAP (using the Multicast Scope
List option), or listening to MZAP messages [6]. List option).
If a MADCAP client is unable to determine its scope list using one of If a MADCAP client is unable to determine its scope list using one of
these techniques, it MAY temporarily assume a scope list consisting these techniques, it MAY temporarily assume a scope list consisting
of a single scope. If it is using IPv4, it SHOULD use IPv4 Local of a single scope. If it is using IPv4, it SHOULD use IPv4 Local
Scope (239.255.0.0/16), with a maximum TTL of 16. If it is using Scope (239.255.0.0/16), with a maximum TTL of 16. If it is using
IPv6, it SHOULD use SCOP 3, with a maximum TTL of 16. Using this IPv6, it SHOULD use SCOP 3, with a maximum TTL of 16. Using this
temporary scope list, it MAY attempt to contact a MADCAP server temporary scope list, it MAY attempt to contact a MADCAP server that
that can provide a scope list for it. can provide a scope list for it.
When a MADCAP client requests an address with a DISCOVER or REQUEST When a MADCAP client requests an address with a DISCOVER or REQUEST
message, it MUST specify the administrative scope from which the message, it MUST specify the administrative scope from which the
address should be allocated. This scope is indicated with the address should be allocated. This scope is indicated with the
Multicast Scope option. Likewise, the server MUST include the Multicast Scope option. Likewise, the server MUST include the
Multicast Scope option in all OFFER messages and all ACK messages Multicast Scope option in all OFFER messages and all ACK messages
sent in response to REQUEST messages. sent in response to REQUEST messages.
2.7. Multicast TTL 2.7. Multicast TTL
skipping to change at page 19, line 4 skipping to change at page 19, line 50
This technique allows MADCAP servers to provide services for scopes This technique allows MADCAP servers to provide services for scopes
in which they do not reside. However, this is a dangerous and in which they do not reside. However, this is a dangerous and
complicated technique and is *not* recommended at this time. complicated technique and is *not* recommended at this time.
Therefore, MADCAP clients SHOULD only send multicast messages to the Therefore, MADCAP clients SHOULD only send multicast messages to the
MADCAP Server Multicast Address corresponding to the IPv4 Local Scope MADCAP Server Multicast Address corresponding to the IPv4 Local Scope
(or SCOP 3, if using IPv6), unless configured otherwise. (or SCOP 3, if using IPv6), unless configured otherwise.
MADCAP servers that wish to provide services for scopes in which they MADCAP servers that wish to provide services for scopes in which they
do not reside MUST make special efforts to ensure that their services do not reside MUST make special efforts to ensure that their services
meet clients' needs for largely conflict-free allocation and accurate meet clients' needs for largely conflict-free allocation and accurate
scope list information. In particular, AAP [9] traffic does not extend scope list information. In particular, coordinating with other
outside of the scope that is being managed so coordinating with other servers that provide services for this scope may be difficult. Also,
servers may be difficult. Also, establishing which scope the client establishing which scope the client is in may be difficult. If a
is in may be difficult. If a MADCAP server is not prepared to provide MADCAP server is not prepared to provide services for scopes in which
services for scopes in which it does not reside, it SHOULD ignore it does not reside, it SHOULD ignore REQUEST, RENEW, and RELEASE
REQUEST, RENEW, and RELEASE messages whose scope does not match (or is messages whose scope does not match (or is enclosed by) the scope of
enclosed by) the scope of the MADCAP Server Multicast Address on which the MADCAP Server Multicast Address on which the request was
the request was received. It SHOULD also ignore INFORM messages that received. It SHOULD also ignore INFORM messages that are not received
are not received on the MADCAP Server Multicast Address for IPv4 on the MADCAP Server Multicast Address for IPv4 Local Scope.
Local Scope.
2.11. Clock Skew 2.11. Clock Skew
The Current Time option is used to detect and handle clock skew The Current Time option is used to detect and handle clock skew
between MADCAP clients and servers. This option MUST be included in between MADCAP clients and servers. This option MUST be included in
any MADCAP message that includes an absolute time (such as the Start any MADCAP message that includes an absolute time (such as the Start
Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, or Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, or
ACK message. ACK message.
Clock skew is a situation where two systems have clocks that are not Clock skew is a situation where two systems have clocks that are not
skipping to change at page 19, line 40 skipping to change at page 20, line 36
dependent. A reasonable value might be one hour. dependent. A reasonable value might be one hour.
The Current Time option contains the sender's opinion of the current The Current Time option contains the sender's opinion of the current
time in UTC at or about the time the message was assembled. Because time in UTC at or about the time the message was assembled. Because
of delays in transmission and processing, this value will rarely of delays in transmission and processing, this value will rarely
match the receiver's opinion of the current time at the time the match the receiver's opinion of the current time at the time the
option is processed by the receiver. option is processed by the receiver.
If a MADCAP server detects clock skew greater than If a MADCAP server detects clock skew greater than
[CLOCK_SKEW_ALLOWANCE], it SHOULD ignore the client. The server MAY [CLOCK_SKEW_ALLOWANCE], it SHOULD ignore the client. The server MAY
log a message. log a message. While it would be possible for the server to correct
for the clock skew, this would probably cause other problems, such as
the client advertising a session with an incorrect time. This is an
error condition and should be handled as such.
2.12. Optional Features 2.12. Optional Features
Each MADCAP client or server MAY implement one or more optional Each MADCAP client or server MAY implement one or more optional
features. Optional features of MADCAP are identified with a two features. Optional features of MADCAP are identified with a two
octet feature code. octet feature code.
A MADCAP client MAY request, require, or indicate support for an A MADCAP client MAY request, require, or indicate support for an
optional feature by including a Feature List option in a message. A optional feature by including a Feature List option in a message. A
MADCAP server MUST either provide all required features for this MADCAP server MUST either provide all required features for this
message or ignore that message. For more information about optional message or ignore that message. For more information about optional
features, see the description of the Feature List option. features, see the description of the Feature List option.
Table 4 lists the feature codes defined at this time and sections Table 4 lists the feature codes defined at this time and sections
2.12.1 and 2.12.2 describe how these features work. 2.12.1 and 2.12.2 describe how these features work.
New MADCAP feature codes may only be defined by IETF Consensus, as New MADCAP feature codes may only be defined by IETF Consensus, as
described in [12]. Basically, this means that they are defined by described in [7]. Basically, this means that they are defined by RFCs
RFCs approved by the IESG. approved by the IESG.
Feature Code Feature Name Feature Code Feature Name
------------ ------------ ------------ ------------
0 Server Mobility 0 Server Mobility
1 Retry After 1 Retry After
Table 4: MADCAP message types Table 4: MADCAP message types
2.12.1. Server Mobility 2.12.1. Server Mobility
skipping to change at page 21, line 20 skipping to change at page 22, line 9
Even if the Server Mobility feature is used, there is no guarantee Even if the Server Mobility feature is used, there is no guarantee
that a server will be available to perform the renewal or release or that a server will be available to perform the renewal or release or
that the renewal or release will succeed. Server connectivity may that the renewal or release will succeed. Server connectivity may
have failed, for instance. have failed, for instance.
2.12.2. Retry After 2.12.2. Retry After
The Retry After feature allows a MADCAP server to ask the MADCAP The Retry After feature allows a MADCAP server to ask the MADCAP
client to retry its request later, as may be required when allocating client to retry its request later, as may be required when allocating
large numbers of addresses or allocating addresses for a long period of large numbers of addresses or allocating addresses for a long period
time. of time.
If a MADCAP client includes the Retry After feature in the If a MADCAP client includes the Retry After feature in the supported
supported list of a Feature List option in a REQUEST message, a list of a Feature List option in a REQUEST message, a MADCAP server
MADCAP server that also implements the Retry After feature MAY that also implements the Retry After feature MAY decide to perform a
decide to implement the feature for this message. In this case, the future allocation. In this case, the MADCAP server will include an
MADCAP empty List of Address Ranges option in its ACK message, a Feature
server will include an empty List of Address Ranges option in its ACK List option that includes the Retry After feature in the supported
message, a Feature List option that includes the Retry After list, and a Retry Time option with a time after which the client
feature in the supported list, and a Retry Time option with a time after should retry the REQUEST.
which the client should retry the REQUEST.
The client MUST NOT include the Retry After feature in the The client MUST NOT include the Retry After feature in the requested
requested or required list of a Feature List option, since the or required list of a Feature List option, since the decision about
decision about whether Retry After is desirable should be left whether Retry After is desirable should be left to the MADCAP server.
to the MADCAP server.
At some later time (preferably after the time indicated in the Retry At some later time (preferably after the time indicated in the Retry
Time option), the client MAY send a REQUEST message with all the same Time option), the client MAY send a REQUEST message with all the same
options as the original REQUEST message (especially the Client options as the original REQUEST message (especially the Client
Identifier option), but with a new xid value. The server MAY return Identifier option), but with a new xid value. The server MAY return
a normal ACK or NAK message at this point or it MAY continue the a normal ACK or NAK message at this point or it MAY continue the
transaction to a later time by including an empty List of transaction to a later time by including an empty List of Address
Address Ranges option in its ACK message, a Feature List option that Ranges option in its ACK message, a Feature List option that includes
includes the Retry After feature in the supported list, and a the Retry After feature in the supported list, and a Retry Time
Retry Time option with a later time after which the client should retry option with a later time after which the client should retry the
the REQUEST. REQUEST.
At any point after receiving the initial ACK message with the Retry At any point after receiving the initial ACK message with the Retry
Time option, the client MAY terminate the allocation process and any Time option, the client MAY terminate the allocation process and any
accompanying lease by sending to the server performing the allocation accompanying lease by sending to the server performing the allocation
(or another server if the Server Mobility feature is also in effect) (or another server if the Server Mobility feature is also in effect)
a RELEASE message with the Client Identifier included in the original a RELEASE message with the Client Identifier included in the original
REQUEST message. REQUEST message.
The Retry After feature may also be used when renewing a lease. The Retry After feature may also be used when renewing a lease. In
In this case, the description above applies except that the client this case, the description above applies except that the client sends
sends a RENEW message instead of a REQUEST message. a RENEW message instead of a REQUEST message.
If a client sends a RENEW message with a Client Identifier that If a client sends a RENEW message with a Client Identifier that
matches a lease which is currently undergoing Retry After in matches a lease which is currently undergoing allocation with the
response to a REQUEST message, the server SHOULD ignore the RENEW Retry After feature in response to a REQUEST message, the server
message. Also, if a client sends a RENEW message with a Client SHOULD ignore the RENEW message. Also, if a client sends a RENEW
Identifier that matches a lease which is currently undergoing allocation message with a Client Identifier that matches a lease which is
with the Retry After feature in response to a RENEW message, but the currently undergoing allocation with the Retry After feature in
options supplied with the two RENEW messages do not match, the server response to a RENEW message, but the options supplied with the two
SHOULD ignore the second RENEW message. RENEW messages do not match, the server SHOULD ignore the second
RENEW message.
3. MADCAP Options 3. MADCAP Options
The following options are defined for use in MADCAP messages. The The following options are defined for use in MADCAP messages. The
options are listed in numerical order. options are listed in numerical order.
3.1. End 3.1. End
The End option marks the end of valid information in the options The End option marks the end of valid information in the options
field. This option MUST be included at the end of the options field field. This option MUST be included at the end of the options field
skipping to change at page 23, line 13 skipping to change at page 23, line 46
The code for this option is 1, and its length is 4. The code for this option is 1, and its length is 4.
Code Len Lease Time Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 4 | t1 | t2 | t3 | t4 | | 1 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
3.3. Server Identifier 3.3. Server Identifier
This option contains the IP address of a MADCAP server. A two octet This option contains the IP address of a MADCAP server. A two octet
address family (as defined by IANA) is stored first, followed by address family (as defined by IANA) is stored first, followed by the
the address. The address family for this address is not determined by address. The address family for this address is not determined by
the addrfamily field so that addresses from one family may be allocated the addrfamily field so that addresses from one family may be
while communicating with a server via addresses of another family. allocated while communicating with a server via addresses of another
family.
All messages sent by a MADCAP server MUST include a Server Identifier All messages sent by a MADCAP server MUST include a Server Identifier
option with the IP address of the server sending the message. option with the IP address of the server sending the message.
MADCAP clients MUST include a Server Identifier option in multicast MADCAP clients MUST include a Server Identifier option in multicast
REQUEST messages in order to indicate which OFFER message has been REQUEST messages in order to indicate which OFFER message has been
accepted. accepted.
The code for this option is 2, and its minimum length is 3. The code for this option is 2, and its minimum length is 3.
skipping to change at page 24, line 7 skipping to change at page 24, line 41
3.5. Multicast Scope 3.5. Multicast Scope
The multicast scope option is used by the client to indicate the The multicast scope option is used by the client to indicate the
requested multicast scope in a DISCOVER or REQUEST message. It is requested multicast scope in a DISCOVER or REQUEST message. It is
also used by the MADCAP server to indicate the scope of an assigned also used by the MADCAP server to indicate the scope of an assigned
address. address.
The client may obtain the scope list through the Multicast Scope List The client may obtain the scope list through the Multicast Scope List
option or using some other means. The scope id is the first multicast option or using some other means. The scope id is the first multicast
address in the scope. The address family of the Scope ID is determined address in the scope. The address family of the Scope ID is
by the addrfamily field. determined by the addrfamily field.
The code for this option is 4, and its minimum length is 1. The code for this option is 4, and its minimum length is 1.
Code Len Scope ID Code Len Scope ID
+-----+-----+-----+-----+-----+----- +-----+-----+-----+-----+-----+-----
| 4 | n | i1 | ... | 4 | n | i1 | ...
+-----+-----+-----+-----+-----+----- +-----+-----+-----+-----+-----+-----
3.6. Option Request List 3.6. Option Request List
skipping to change at page 24, line 53 skipping to change at page 25, line 41
If the Start Time option is present, the IP Address Lease Time option If the Start Time option is present, the IP Address Lease Time option
specifies the duration of the lease beginning at the Start Time specifies the duration of the lease beginning at the Start Time
option value. option value.
If the Start Time option is present, the Current Time option MUST If the Start Time option is present, the Current Time option MUST
also be present, as described in section 2.11. also be present, as described in section 2.11.
The time value is an unsigned 32 bit integer in network byte order The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This giving the number of seconds since 00:00 UTC, 1st January 1970. This
is consistent with the time format used in AAP [9] and can be can be converted to an NTP timestamp by adding decimal 2208988800.
converted to an NTP timestamp by adding decimal 2208988800. This time This time format will not wrap until the year 2106.
format will not wrap until the year 2106.
The code for this option is 6 and the length is 4. The code for this option is 6 and the length is 4.
Code Len Time Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 4 | t1 | t2 | t3 | t4 | | 6 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
3.8. Number of Addresses Requested 3.8. Number of Addresses Requested
skipping to change at page 24, line 94 skipping to change at page 26, line 35
Code Len Minimum Desired Code Len Minimum Desired
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 7 | 4 | min | desired | | 7 | 4 | min | desired |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
3.9. Requested Language 3.9. Requested Language
This option specifies the language in which the MADCAP client would This option specifies the language in which the MADCAP client would
like strings such as zone names to be returned. It is only included like strings such as zone names to be returned. It is only included
in an INFORM message sent by the client. It is an RFC 1766 [11] in an INFORM message sent by the client. It is an RFC 1766 [6]
language tag. The proper way to handle this tag with respect to zone language tag. The proper way to handle this tag with respect to zone
names is discussed further in the definition of the Multicast Scope names is discussed further in the definition of the Multicast Scope
List option. List option.
The code for this option is 8 and the minimum length is 0. The code for this option is 8 and the minimum length is 0.
Code Len Language Tag Code Len Language Tag
+-----+-----+-----+-----+-----+-...-+-----+ +-----+-----+-----+-----+-----+-...-+-----+
| 8 | n | L1 | | Ln | | 8 | n | L1 | | Ln |
+-----+-----+-----+-----+-----+-...-+-----+ +-----+-----+-----+-----+-----+-...-+-----+
skipping to change at page 24, line 147 skipping to change at page 27, line 39
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
| ... ID ... | ... Last ... | T | n | EN1 | | ENn | | ... ID ... | ... Last ... | T | n | EN1 | | ENn |
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
where Scope ID is the first multicast address in the scope, Last where Scope ID is the first multicast address in the scope, Last
Address is the last multicast address in the scope, TTL is the Address is the last multicast address in the scope, TTL is the
multicast TTL value for the multicast addresses of the scope, and multicast TTL value for the multicast addresses of the scope, and
Name Count is the number of encoded names for this zone (which may be Name Count is the number of encoded names for this zone (which may be
zero). The address family of the Scope ID and Last Address is zero). The address family of the Scope ID and Last Address is
determined by the addrfamily field. Each encoded name is of the form determined by the addrfamily field. Each encoded name is of the form
Name Lang Language Tag Name Name Name Lang Language Tag Name Name
Flags Length Length Flags Length Length
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
| F | q | L1 | | Lq | r | N1 | | Nr | | F | q | L1 | | Lq | r | N1 | | Nr |
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
where Name Flags is a flags field with flags defined below, Lang where Name Flags is a flags field with flags defined below, Lang
Length is the length of the Language Tag in octets (which MUST NOT be Length is the length of the Language Tag in octets (which MUST NOT be
zero), Language Tag is a language tag indicating the language of the zero), Language Tag is a language tag indicating the language of the
zone name (as described in [11]), Name Length is the length of the zone name (as described in [6]), Name Length is the length of the
Name in octets (which MUST NOT be zero), and Name is a UTF-8 [10] string Name in octets (which MUST NOT be zero), and Name is a UTF-8 [5]
indicating the name given to the scope zone. string indicating the name given to the scope zone.
The high bit of the Name Flags field is set if the following name The high bit of the Name Flags field is set if the following name
should be used if no name is available in a desired language. should be used if no name is available in a desired language.
Otherwise, this bit is cleared. All remaining bits in the octet Otherwise, this bit is cleared. All remaining bits in the octet
SHOULD be set to zero and MUST be ignored. SHOULD be set to zero and MUST be ignored.
The scope IDs of entries in the list MUST be unique and the scopes The scope IDs of entries in the list MUST be unique and the scopes
SHOULD be listed from smallest (topologically speaking) to largest. SHOULD be listed from smallest (topologically speaking) to largest.
Example: Example:
skipping to change at page 24, line 238 skipping to change at page 29, line 39
3.12. Current Time 3.12. Current Time
This option is used to express what the sender thinks the current This option is used to express what the sender thinks the current
time is. This is useful for detecting clock skew. This option MUST be time is. This is useful for detecting clock skew. This option MUST be
included if the Start Time or Maximum Start Time options are used, as included if the Start Time or Maximum Start Time options are used, as
described in section 2.11. described in section 2.11.
The time value is an unsigned 32 bit integer in network byte order The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This giving the number of seconds since 00:00 UTC, 1st January 1970. This
is consistent with the time format used in AAP [9] and can be can be converted to an NTP [4] timestamp by adding decimal
converted to an NTP [4] timestamp by adding decimal 2208988800. This 2208988800. This time format will not wrap until the year 2106.
time format will not wrap until the year 2106.
The code for this option is 11 and the length is 4. The code for this option is 11 and the length is 4.
Code Len Time Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 11 | 4 | t1 | t2 | t3 | t4 | | 11 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
3.13. Feature List 3.13. Feature List
This option lists optional MADCAP features supported, This option lists optional MADCAP features supported, requested, or
requested, or required by the sender. This option MAY be included in required by the sender. This option MAY be included in any message
any message sent by a MADCAP server or client. sent by a MADCAP server or client.
Optional features of MADCAP are identified with a two octet feature Optional features of MADCAP are identified with a two octet feature
code. New MADCAP feature codes may only be defined by IETF code. New MADCAP feature codes may only be defined by IETF
Consensus, as described in [12]. Basically, this means that they are Consensus, as described in [7]. Basically, this means that they are
defined by RFCs approved by the IESG. defined by RFCs approved by the IESG.
The Feature List option consists of three separate lists: supported The Feature List option consists of three separate lists: supported
features, requested features, and required features. Each list features, requested features, and required features. Each list
consists of an unordered list of feature codes. Features in the consists of an unordered list of feature codes. Features in the
supported list are features that the sender supports. Features in the supported list are features that the sender supports. Features in the
requested list are features that the sender would like the receiver requested list are features that the sender would like the receiver
to support and use. However, it is OK if the receiver does not to support and use. However, it is OK if the receiver does not
support or use those features. Features in the required list are support or use those features. Features in the required list are
features that the sender requires. If the receiver does not support features that the sender requires. If the receiver does not support
those features, it MUST ignore the message. those features, it MUST ignore the message.
If a MADCAP client includes the Feature List option in a message, it If a MADCAP client includes the Feature List option in a message, it
MAY include features in any of the lists: supported, requested, and MAY include features in any of the lists: supported, requested, and
required. A MADCAP server that receives a message containing the required. A MADCAP server that receives a message containing the
Feature List option from a client MUST ignore the entire message if Feature List option from a client MUST ignore the entire message if
it does not support all of the features in the required list. If it it does not support all of the features in the required list. If it
supports all of the features in the required list, it MUST implement supports all of the features in the required list, it MUST implement
them as appropriate for this message. It SHOULD try to implement the them as appropriate for this message. It SHOULD try to implement the
features in the requested list and it MAY implement any of the features in the requested list and it MAY implement any of the
features in the supported list. If an optional feature (such as Retry features in the supported list. If an optional feature (such as
After) is not included in any part of the Feature List option included Retry After) is not included in any part of the Feature List option
in the client's message (or if the client does not include a Feature included in the client's message (or if the client does not include a
List option in its message), the server MUST NOT use that feature in Feature List option in its message), the server MUST NOT use that
its response. If the server does respond to a client's message that feature in its response. If the server does respond to a client's
includes a Feature List option, it MUST include a Feature List option message that includes a Feature List option, it MUST include a
listing the features that it supports and with an empty requested and Feature List option listing the features that it supports and with an
required features list. empty requested and required features list.
The code for this option is 12 and the minimum length is 6. The code for this option is 12 and the minimum length is 6.
Code Len Supported Requested Required Code Len Supported Requested Required
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 12 | n | FL1 | FL2 | FL3 | | 12 | n | FL1 | FL2 | FL3 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
where each of the Feature Lists is of the following format: where each of the Feature Lists is of the following format:
Feature Feature Feature Feature Feature Feature
Count Code 1 Code m Count Code 1 Code m
+-----+-----+-----+-----+-...-+-----+-----+ +-----+-----+-----+-----+-...-+-----+-----+
| m | FC1 | | FCm | | m | FC1 | | FCm |
+-----+-----+-----+-----+-...-+-----+-----+ +-----+-----+-----+-----+-...-+-----+-----+
3.14. Retry Time 3.14. Retry Time
The Retry Time option specifies the time at which a client should The Retry Time option specifies the time at which a client should
retry a REQUEST or RENEW message when the Retry After feature. retry a REQUEST or RENEW message when using the Retry After feature.
This option should only be sent by a MADCAP server in an ACK when This option should only be sent by a MADCAP server in an ACK when
responding to a REQUEST or RENEW message that includes the Retry responding to a REQUEST or RENEW message that includes the Retry
After feature in the supported, requested, or required list. For After feature in the supported, requested, or required list. For more
more discussion of Retry After, see section 2.12.2. discussion of Retry After, see section 2.12.2.
If the Retry Time option is present, the Current Time option MUST If the Retry Time option is present, the Current Time option MUST
also be present. also be present.
The time value is an unsigned 32 bit integer in network byte order The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This giving the number of seconds since 00:00 UTC, 1st January 1970. This
is consistent with the time format used in AAP [9] and can be can be converted to an NTP timestamp by adding decimal 2208988800.
converted to an NTP timestamp by adding decimal 2208988800. This time This time format will not wrap until the year 2106.
format will not wrap until the year 2106.
The code for this option is 13 and the length is 4. The code for this option is 13 and the length is 4.
Code Len Time Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 13 | 4 | t1 | t2 | t3 | t4 | | 13 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
3.15. Minimum Lease Time 3.15. Minimum Lease Time
This option is used in a client request (DISCOVER, REQUEST, or RENEW) This option is used in a client request (DISCOVER, REQUEST, or RENEW)
to allow the client to specify a minimum lease time for the multicast to allow the client to specify a minimum lease time for the multicast
address. If a server cannot meet this minimum lease time, it SHOULD address. If a server cannot meet this minimum lease time, it SHOULD
ignore a DISCOVER or send a NAK in response to a RENEW or REQUEST ignore a DISCOVER or send a NAK in response to a RENEW or REQUEST
(unless it's a multicast REQUEST with a Server Identifier that doesn't (unless it's a multicast REQUEST with a Server Identifier that
match the server's, which should be ignored altogether). doesn't match the server's, which should be ignored altogether).
The time is in units of seconds, and is specified as a 32-bit The time is in units of seconds, and is specified as a 32-bit
unsigned integer. unsigned integer.
The code for this option is 14, and its length is 4. The code for this option is 14, and its length is 4.
Code Len Lease Time Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 14 | 4 | t1 | t2 | t3 | t4 | | 14 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
3.16. Maximum Start Time 3.16. Maximum Start Time
The Maximum Start Time option specifies the latest starting time The Maximum Start Time option specifies the latest starting time that
that the client is willing to accept for a multicast address lease. the client is willing to accept for a multicast address lease.
A client may include this option in a DISCOVER, RENEW, or REQUEST A client may include this option in a DISCOVER, RENEW, or REQUEST
message to specify that it does not want to receive a lease with a message to specify that it does not want to receive a lease with a
starting time later than the specified value. If a server cannot starting time later than the specified value. If a server cannot meet
meet this maximum start time, it SHOULD ignore a DISCOVER or send this maximum start time, it SHOULD ignore a DISCOVER or send a NAK in
a NAK in response to a RENEW or REQUEST (unless it's a multicast response to a RENEW or REQUEST (unless it's a multicast REQUEST with
REQUEST with a Server Identifier that doesn't match the server's, a Server Identifier that doesn't match the server's, which should be
which should be ignored altogether). ignored altogether).
If the Maximum Start Time option is present, the Current Time option MUST If the Maximum Start Time option is present, the Current Time option
also be present, as described in section 2.11. MUST also be present, as described in section 2.11.
The time value is an unsigned 32 bit integer in network byte order The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This giving the number of seconds since 00:00 UTC, 1st January 1970. This
is consistent with the time format used in AAP [9] and can be can be converted to an NTP timestamp by adding decimal 2208988800.
converted to an NTP timestamp by adding decimal 2208988800. This time This time format will not wrap until the year 2106.
format will not wrap until the year 2106.
The code for this option is 15 and the length is 4. The code for this option is 15 and the length is 4.
Code Len Time Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| 15 | 4 | t1 | t2 | t3 | t4 | | 15 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
4. Security Considerations 4. Security Considerations
skipping to change at page 31, line 25 skipping to change at page 33, line 5
address for the time period, without any restrictions on its use. address for the time period, without any restrictions on its use.
To protect against rogue MADCAP servers (mis-configured servers and To protect against rogue MADCAP servers (mis-configured servers and
intentional), clients in certain situations would like to intentional), clients in certain situations would like to
authenticate the server. Similarly, for auditing or book-keeping authenticate the server. Similarly, for auditing or book-keeping
purposes, the server may want to authenticate clients. Moreover, in purposes, the server may want to authenticate clients. Moreover, in
some cases, the server may have certain policies in place to restrict some cases, the server may have certain policies in place to restrict
number of addresses that are allocated to a system or a user. This number of addresses that are allocated to a system or a user. This
feature is of much value when a well behaved but naive user or client feature is of much value when a well behaved but naive user or client
requests a large number of addresses, and therefore, inadvertently requests a large number of addresses, and therefore, inadvertently
impacts other users or systems. Therefore, an administrator may want to impacts other users or systems. Therefore, an administrator may want
exert a limited amount of control based on the client identification. to exert a limited amount of control based on the client
The client identification could be based on the system or user identification. The client identification could be based on the
identity. In most practical situations, system identification will system or user identity. In most practical situations, system
suffice, however, particularly in case of multi-user systems, at identification will suffice, however, particularly in case of
times, user identification will play an important role. Therefore, multi-user systems, at times, user identification will play an
authentication capabilities based on user identification may be important role. Therefore, authentication capabilities based on user
desirable. As usual, data integrity is a strong requirement and if identification may be desirable. As usual, data integrity is a strong
not protected, can lead to many problems including denial of service requirement and if not protected, can lead to many problems including
attacks. denial of service attacks.
In the case of MADCAP, confidentiality is not a strong requirement. In the case of MADCAP, confidentiality is not a strong requirement.
In most of the cases, at least when a multicast address is in use, an In most of the cases, at least when a multicast address is in use, an
adversary will be able to determine information that was contained in adversary will be able to determine information that was contained in
the MADCAP messages. In some cases, the users/systems may want to the MADCAP messages. In some cases, the users/systems may want to
protect information in the MADCAP messages so that an adversary is protect information in the MADCAP messages so that an adversary is
not able to determine relevant information in advance and thus, plan not able to determine relevant information in advance and thus, plan
an attack in advance. For example, if an adversary knows in advance an attack in advance. For example, if an adversary knows in advance
(based on MADCAP messages) that a particular user has requested large (based on MADCAP messages) that a particular user has requested large
number of address for certain time period and scope, he may be able number of address for certain time period and scope, he may be able
to guess the purpose behind such request and target an attack. If to guess the purpose behind such request and target an attack. If
MADCAP servers are configured to allow renewal or release purely on MADCAP servers are configured to allow renewal or release purely on
the basis of knowledge of the Client Identifier option (without the basis of knowledge of the Client Identifier option (without
consideration of authentication), preserving the confidentiality of consideration of authentication), preserving the confidentiality of
MADCAP messages becomes more important. Also, there may be features MADCAP messages becomes more important. Also, there may be features
added to the protocol in future that may have stronger added to the protocol in future that may have stronger
confidentiality requirements. confidentiality requirements.
The IPSEC protocol [13] meets client/server identification and The IPSEC protocol [8] meets client/server identification and
integrity protection requirements stated above, requires no integrity protection requirements stated above, requires no
modification to the MADCAP protocol, and leverages extensive work in modification to the MADCAP protocol, and leverages extensive work in
IETF and industry. Therefore, when security is a strong requirement, IETF and industry. Therefore, when security is a strong requirement,
IPSEC SHOULD be used for protecting all the unicast messages of IPSEC SHOULD be used for protecting all the unicast messages of
MADCAP protocol. When IPSEC based security is in use, all the MADCAP protocol. When IPSEC based security is in use, all the
multicast packets except INFORM MUST be dropped by the MADCAP server. multicast packets except INFORM MUST be dropped by the MADCAP server.
The prevalent implementations of IPSEC support client identification The prevalent implementations of IPSEC support client identification
in form of system identification and do not support user in form of system identification and do not support user
identification. However, when desired, IPSEC with appropriate API's identification. However, when desired, IPSEC with appropriate API's
may be required to support user identification. may be required to support user identification.
5. IANA Considerations 5. IANA Considerations
This document defines several number spaces (MADCAP options, MADCAP This document defines several number spaces (MADCAP options, MADCAP
message types, MADCAP client identifier types, and MADCAP features). message types, MADCAP client identifier types, and MADCAP features).
For all of these number spaces, certain values are defined in this For all of these number spaces, certain values are defined in this
specification. New values may only be defined by IETF Consensus, as specification. New values may only be defined by IETF Consensus, as
described in [12]. Basically, this means that they are defined by described in [7]. Basically, this means that they are defined by RFCs
RFCs approved by the IESG. approved by the IESG.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Rajeev Byrisetty, Steve Deering, The authors would like to thank Rajeev Byrisetty, Steve Deering,
Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning,
Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for
their assistance with this protocol. their assistance with this protocol.
Much of this document is based on [1] and [2]. The authors of this Much of this document is based on [1] and [2]. The authors of this
document would like to express their gratitude to the authors of document would like to express their gratitude to the authors of
skipping to change at page 32, line 52 skipping to change at page 34, line 32
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[3] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, [3] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
July 1998. July 1998.
[4] Mills, D., "Network Time Protocol (Version 3) Specification, [4] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992. Implementation and Analysis", RFC 1305, March 1992.
[5] Handley, M., D. Thaler, and D. Estrin, "The Internet Multicast [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
Address Allocation Architecture", Internet Draft, draft-handley-
malloc-arch-00.txt, December 1997.
[6] Handley, M., "Multicast-Scope Zone Announcement Protocol
(MZAP)", Internet Draft, draft-ietf-mboned-mzap-00.txt, December
1997.
[7] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
Stanford University and Sun Microsystems, September 1985.
[8] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, July 1992.
[9] Handley, M., "Multicast Address Allocation Protocol (AAP)",
Internet Draft, draft-handley-aap-00.txt, December 1997.
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[11] Alvestrand, H., "Tags for the Identification of Languages", RFC [6] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995. 1766, March 1995.
[12] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
[13] R. Atkinson, S. Kent, "Security Architecture for the Internet [8] R. Atkinson, S. Kent, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
8. Authors' Addresses 8. Authors' Addresses
Baiju V. Patel Baiju V. Patel
Intel Corp. Intel Corp.
2111 NE 25th Ave. 2111 NE 25th Ave.
Hillsboro, OR 97124 Hillsboro, OR 97124
Phone: 503 264 2422 Phone: 503 264 2422
skipping to change at page 34, line 32 skipping to change at page 35, line 43
option, an Option Request List including the Multicast Scope List option, an Option Request List including the Multicast Scope List
option code, and a Requested Language option containing the string option code, and a Requested Language option containing the string
"en", since the client is configured to prefer the English language. "en", since the client is configured to prefer the English language.
Two MADCAP servers respond by sending ACK messages. These ACK Two MADCAP servers respond by sending ACK messages. These ACK
messages include the Client Identifier option and xid supplied by the messages include the Client Identifier option and xid supplied by the
client, the server's Server Identifier, and the Multicast Scope List client, the server's Server Identifier, and the Multicast Scope List
with one name per scope (the one that most closely matches the with one name per scope (the one that most closely matches the
language tag "en"). language tag "en").
The following figure illustrates this exchange.
Server Client Server Server Client Server
v v v v v v
| | | | | |
| | | | | |
| _____________/|\_____________ | | _____________/|\_____________ |
|/ INFORM | INFORM \| |/ INFORM | INFORM \|
| | | | | |
| | | | | |
|\ | ____________/| |\ | ____________/|
| \_________ | / ACK | | \_________ | / ACK |
skipping to change at page 38, line 35 skipping to change at page 39, line 38
has recently worked with a server, it decides to try sending a has recently worked with a server, it decides to try sending a
unicast REQUEST to that server. If this doesn't work, it can always unicast REQUEST to that server. If this doesn't work, it can always
try a multicast DISCOVER, as illustrated in example 2. try a multicast DISCOVER, as illustrated in example 2.
The client unicasts a REQUEST packet to the server from which it The client unicasts a REQUEST packet to the server from which it
wants to allocate the address. This packet includes the Lease Time, wants to allocate the address. This packet includes the Lease Time,
Client Identifier, and Multicast Scope options. Client Identifier, and Multicast Scope options.
The server responds with an ACK packet containing the Lease Time, The server responds with an ACK packet containing the Lease Time,
Client Identifier, and Multicast Scope options from the REQUEST Client Identifier, and Multicast Scope options from the REQUEST
packet, as well as the Server Identifier option and a List of packet, as well as the Server Identifier option and a List of Address
Address Ranges option listing the address allocated. Ranges option listing the address allocated.
The client now has a lease on the multicast address. The client now has a lease on the multicast address.
If the client had not received an ACK from the server, it would have If the client had not received an ACK from the server, it would have
retransmitted its REQUEST packet for a while. If it still received no retransmitted its REQUEST packet for a while. If it still received no
response, it would start over with a multicast DISCOVER message. response, it would start over with a multicast DISCOVER message.
The following figure illustrates this exchange. The following figure illustrates this exchange.
Client Server Client Server
skipping to change at page 39, line 4 skipping to change at line 1875
| | | |
| Allocates address | Allocates address
| | | |
| _____________/| | _____________/|
|/ ACK | |/ ACK |
| | | |
v v v v
Figure 6: Timeline diagram of messages exchanged Figure 6: Timeline diagram of messages exchanged
in Unicast Address Allocation example in Unicast Address Allocation example
APPENDIX B: Change Log
CHANGES FROM draft-ietf-malloc-mdhcp-02.txt
Removed randomization from retransmission.
Added client identifier type.
Changed section 2.2.1 so that in response to an INFORM with the
option request list option, a scope list need only be returned
if the scope list option was specifically requested.
Added Maximum Start Time and Minimum Lease Time options.
Changed address types to use IANA-registered address family numbers.
Changed IPv6 support to use SCOP 3 instead of SCOP 5 for default
MADCAP Server Multicast Address.
Added back Unicast Address Allocation example.
Various clarifications and corrections.
CHANGES FROM draft-ietf-malloc-mdhcp-01.txt
Remove most reserved fields from header.
Added version in header.
Added security via IPsec.
Removed MADCAP prefix from message types.
Moved MADCAP Message Type option to msgtype header field.
Changed name from MDHCP to MADCAP.
Added IPv6 support via address type fields.
Made option type and length two octets.
Removed references to Allocation Scope.
Renumbered options to start with 0.
Added RENEW message so REQUEST is only for new allocations now.
RELEASE is now ACKed.
Added optional features, including Server Mobility and Future
Allocation.
Renamed IP address Lease Time option to Lease Time.
Renamed List of Address Ranges Allocated option to List of Address
Ranges.
Clarified how Client Identifier is used to identify a particular
lease.
Removed Multicast TTL option, since this is included in the Multicast
Scope List option.
Removed Requested IP Address option. Use the List of Address Rangess
option instead.
Removed Pad option and changed End option so that it matches TLV
format.
Added IANA Considerations section.
Cleaned up and tightened up text in many ways.
CHANGES FROM draft-ietf-malloc-mdhcp-00.txt
Port number assigned.
Removed unused chaddr, sname, and file fields.
Split MDHCP option space from DHCP.
Changed technique for choosing MDHCP Server Multicast Addresses when
initial requests fail.
Added Requested Language option.
Added language tags and multiple names per zone to the Multicast
Scope List option.
CHANGES FROM draft-ietf-dhc-mdhcp-03.txt
Many changes to make this document no longer dependent on the DHCP
spec. This should make the document easier to read and understand.
Removed MDHCPDECLINE.
Added Current Time option to deal with clock skew.
Scopes are now identified by the first multicast address in the scope
instead of using a scope ID.
Changed Total Addresses Requested option to Number of Addresses
Requested. Changed this option to have minimum and desired fields.
Clarified that servers MAY send OFFER or ACK messages with shorter
lifetimes or later start times than those requested by the client.
This is consistent with DHCP and provides a simple way to achieve the
minimum/maximum lifetime functionality described in the malloc
abstract API.
 End of changes. 66 change blocks. 
234 lines changed or deleted 223 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/