< draft-ietf-magma-msnip-03.txt   draft-ietf-magma-msnip-04.txt >
Internet Engineering Task Force MAGMA WG Internet Engineering Task Force MAGMA WG
INTERNET-DRAFT B. Fenner/AT&T INTERNET-DRAFT B. Fenner/AT&T
draft-ietf-magma-msnip-03.txt B. Haberman/Caspian Networks draft-ietf-magma-msnip-04.txt B. Haberman/Caspian Networks
H. Holbrook/Cisco H. Holbrook/Cisco
I. Kouvelas/Cisco I. Kouvelas/Cisco
2 April 2003 19 June 2003
Expires: October 2003 Expires: December 2003
Multicast Source Notification of Interest Protocol (MSNIP) Multicast Source Notification of Interest Protocol (MSNIP)
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3
2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3
3. Service Interface for Requesting Membership Noti- 3. Service Interface for Requesting Membership Noti-
fication . . . . . . . . . . . . . . . . . . . . . . . . . 4 fication . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Application Operation. . . . . . . . . . . . . . . . 5 3.1. Application Operation. . . . . . . . . . . . . . . . 5
4. MSNIP Managed Address Range Negotiation . . . . . . . . 6 4. MSNIP Managed Address Range Negotiation . . . . . . . . 6
4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6
4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6
4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7
4.2. Managed Range Discovery by Source Systems. . . . . . 7 4.2. Managed Range Discovery by Source Systems. . . . . . 8
5. Requesting and Receiving Notifications. . . . . . . . . 8 5. Requesting and Receiving Notifications. . . . . . . . . 8
5.1. Host Interest Solicitation . . . . . . . . . . . . . 9 5.1. Host Interest Solicitation . . . . . . . . . . . . . 9
5.2. Router Receiver Membership Reports . . . . . . . . . 9 5.2. Router Receiver Membership Reports . . . . . . . . . 9
6. Application Notification. . . . . . . . . . . . . . . . 10 6. Application Notification. . . . . . . . . . . . . . . . 11
7. Router Processing . . . . . . . . . . . . . . . . . . . 12 7. Router Processing . . . . . . . . . . . . . . . . . . . 13
8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14
8.1. Host Interest Solicitation Packet. . . . . . . . . . 15 8.1. Host Interest Solicitation Message . . . . . . . . . 15
8.2. Receiver Membership Report Packet. . . . . . . . . . 15 8.2. Receiver Membership Report Packet. . . . . . . . . . 16
8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 17 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 18
8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 17 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 18
9. Constants Timers and Default Values . . . . . . . . . . 18 9. Constants Timers and Default Values . . . . . . . . . . 18
10. Possible Optimisations . . . . . . . . . . . . . . . . 18 10. Possible Optimisations . . . . . . . . . . . . . . . . 19
10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 18 10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 19
10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 18 10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 19
10.3. Responding to Unexpected IGMP Queries . . . . . . . 19 10.3. Responding to Unexpected IGMP Queries . . . . . . . 19
10.4. Host and Router Startup . . . . . . . . . . . . . . 19 10.4. Host and Router Startup . . . . . . . . . . . . . . 20
11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20 11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20
12. Security Considerations. . . . . . . . . . . . . . . . 20 12. Security Considerations. . . . . . . . . . . . . . . . 21
12.1. Receiver Membership Report attacks. . . . . . . . . 21 12.1. Receiver Membership Report attacks. . . . . . . . . 21
12.2. Host Interest Solicitation attacks. . . . . . . . . 21 12.2. Host Interest Solicitation attacks. . . . . . . . . 22
12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22
13. IANA Considerations. . . . . . . . . . . . . . . . . . 22 13. IANA Considerations. . . . . . . . . . . . . . . . . . 23
14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23 14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23
15. Normative References . . . . . . . . . . . . . . . . . 23 15. Normative References . . . . . . . . . . . . . . . . . 23
16. Informative References . . . . . . . . . . . . . . . . 23 16. Informative References . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Multicast Source Notification of Interest Protocol (MSNIP) is The Multicast Source Notification of Interest Protocol (MSNIP) is
an extension to version 3 of the Internet Group Membership Protocol an extension to version 3 of the Internet Group Membership Protocol
(IGMPv3 [1]) and version 2 of the Multicast Listener Discovery Protocol (IGMPv3 [1]) and version 2 of the Multicast Listener Discovery Protocol
(MLDv2 [2]). MSNIP operates between multicast sources and their first- (MLDv2 [2]). MSNIP operates between multicast sources and their first-
hop routers to provide information on the presence of receivers to the hop routers to provide information on the presence of receivers to the
source systems. Using the services offered by MSNIP an application on an source systems. Using the services offered by MSNIP an application on an
IP system wishing to source multicast data can register to be notified IP system wishing to source multicast data can register to be notified
skipping to change at page 4, line 48 skipping to change at page 4, line 48
for receiving notifications from the IP system: for receiving notifications from the IP system:
IPMulticastSourceStart (socket, source-address, multicast-address) IPMulticastSourceStart (socket, source-address, multicast-address)
IPMulticastSourceStop (socket, source-address, multicast-address) IPMulticastSourceStop (socket, source-address, multicast-address)
where: where:
socket socket
is an implementation-specific parameter used to distinguish amongst is an implementation-specific parameter used to distinguish amongst
different requesting entities (e.g., programs or processes) within different requesting entities (e.g., programs or processes) within
the system; the socket parameter of BSD Unix system calls is a the system; the socket parameter of BSD UNIX system calls is a
specific example. specific example.
source-address source-address
is the IP unicast source address that the application wishes to use is the IP unicast source address that the application wishes to use
in transmitting data to the specified multicast address. The in transmitting data to the specified multicast address. The
specified address must be one of the IP addresses associated with specified address must be one of the IP addresses associated with
the network interfaces of the IP system. Note that an interface in the network interfaces of the IP system. Note that an interface in
an IP system may be associated with more than one IP address. An an IP system may be associated with more than one IP address. An
implementation may allow a special "unspecified" value to be passed implementation may allow a special "unspecified" value to be passed
as the source-address parameter, in which case the request would as the source-address parameter, in which case the request would
skipping to change at page 6, line 13 skipping to change at page 6, line 13
the teardown of the associated socket state. the teardown of the associated socket state.
4. MSNIP Managed Address Range Negotiation 4. MSNIP Managed Address Range Negotiation
With current multicast deployment in the Internet, different With current multicast deployment in the Internet, different
multicast routing protocols coexist and operate under separate parts of multicast routing protocols coexist and operate under separate parts of
the multicast address space. Multicast routers are consistently the multicast address space. Multicast routers are consistently
configured with information that maps specific multicast address ranges configured with information that maps specific multicast address ranges
to multicast routing protocols. Part of this configuration describes the to multicast routing protocols. Part of this configuration describes the
subset of the address space that is used by source-specific multicast subset of the address space that is used by source-specific multicast
(SSM) [12]. As described in section 2 MSNIP only tries to control (SSM) [12]. As described in section 2, MSNIP only tries to control
application transmission within the SSM address range. application transmission within the SSM address range.
It is desirable for applications within an IP system that supports It is desirable for applications within an IP system that supports
MSNIP to have a consistent service interface for multicast transmission MSNIP to have a consistent service interface for multicast transmission
that does not require the application to be aware of the SSM address that does not require the application to be aware of the SSM address
range. MSNIP supports this by allowing applications to use the service range. MSNIP supports this by allowing applications to use the service
interface described in section 3 for multicast destination addresses interface described in section 3 for multicast destination addresses
that are outside its operating range. When an application registers for that are outside its operating range. When an application registers for
notifications for a destination address that is not managed by MSNIP it notifications for a destination address that is not managed by MSNIP it
is immediately notified to start transmitting. This is equivalent to the is immediately notified to start transmitting. This is equivalent to the
default behaviour of IP multicast without MSNIP support which forces default behaviour of IP multicast without MSNIP support which forces
multicast applications to assume that there are multicast receivers multicast applications to assume that there are multicast receivers
present in the network. present in the network.
4.1. Router Coordination 4.1. Router Coordination
In order for MSNIP to operate on a shared link where more than one In order for MSNIP to operate on a shared link where two or more
multicast routers may be present, all multicast routers must be MSNIP- multicast routers may be present, all the multicast routers must be
capable and have an identical configuration for the SSM address range. MSNIP-capable and have an identical configuration for the SSM address
MSNIP enforces these requirements by using two new options for IPv4 in range. MSNIP enforces these requirements by using two new options for
the Multicast Router Discovery protocol [3] and one new option for IPv6 IPv4 in the Multicast Router Discovery protocol [3] and one new option
in the Neighbor Discovery / ICMPv6 protocol [6]. for IPv6 in the Neighbour Discovery / ICMPv6 protocol [6].
4.1.1. MSNIP Operation Option 4.1.1. MSNIP Operation Option
A multicast router advertises that it is participating in MSNIP A multicast router advertises that it is participating in MSNIP
using the MSNIP Operation option in either the Multicast Router using the MSNIP Operation option in either the Multicast Router
Discovery protocol for IPv4 or the Neighbor Discovery / ICMPv6 protocol Discovery protocol for IPv4 or the Neighbour Discovery / ICMPv6 protocol
for IPv6. This option MUST be included in all router advertisement for IPv6. This option MUST be included in all router advertisement
messages of a router that is configured for MSNIP. The format of the messages of a router that is configured for MSNIP. The format of the
option is as follows: option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Padding | | Type | Length | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | | Padding |
skipping to change at page 7, line 26 skipping to change at page 7, line 26
Length Length
The length field is set to 0 for IPv4 and 1 for IPv6. The length field is set to 0 for IPv4 and 1 for IPv6.
Padding Padding
The six extra bytes of padding are only present in IPv6 and are The six extra bytes of padding are only present in IPv6 and are
required to bring the size of the option up to the eight octet required to bring the size of the option up to the eight octet
boundary. The value of the padding bytes must be set to zero on boundary. The value of the padding bytes must be set to zero on
transmission and ignored on receipt. transmission and ignored on receipt.
A multicast router uses received Multicast Router Advertisement and A multicast router uses received Multicast Router Advertisement and
Neighbor Discovery / ICMPv6 messages to determine if all live neighbour Neighbour Discovery / ICMPv6 messages to determine if all live neighbour
multicast routers on each interface are participating in MSNIP. When a multicast routers on each interface are participating in MSNIP. When a
router advertisement message not containing an MSNIP option is received router advertisement message not containing an MSNIP option is received
by a router participating in MSNIP, the mis-configuration SHOULD be by a router participating in MSNIP, the mis-configuration SHOULD be
logged to the operator in a rate-limited manner. logged to the operator in a rate-limited manner.
If even one multicast router on a link does not have MSNIP If even one multicast router on a link does not have MSNIP
capability then ALL routers on that link MUST be configured to not capability then ALL routers on that link MUST be configured to not
provide MSNIP services and to not advertise the MSNIP Operation option. provide MSNIP services and to not advertise the MSNIP Operation option.
4.1.2. SSM Range Option 4.1.2. SSM Range Option
The SSM Range Multicast Router Discovery option advertises the SSM The SSM Range Multicast Router Discovery option advertises the IPv4
Range with which the router is configured. The option is defined in [4]. SSM Range with which the router is configured. The option is defined in
This option is only valid in IPv4. SSM support in IPv6 does not allow [4]. This option is only valid in IPv4.
for alternative SSM address ranges.
The SSM range for IPv6 is well defined for all valid scopes [15]
and a mechanism to allow additional ranges to operate in SSM mode on a
per-link bases is not required.
4.2. Managed Range Discovery by Source Systems 4.2. Managed Range Discovery by Source Systems
When an application in an IP system uses the MSNIP service When an application in an IP system uses the MSNIP service
interface to register for notification, the IP system must behave interface to register for notification, the IP system must behave
differently depending on whether or not the destination address for differently depending on whether or not the destination address for
which the application registered is operating under SSM (and is being which the application registered is operating under SSM (and is being
managed by MSNIP). For SSM channels, the IP system should only instruct managed by MSNIP). For SSM channels, the IP system should only instruct
the application to transmit when there are receivers for the multicast the application to transmit when there are receivers for the multicast
destination. For non-SSM destination addresses the IP system will not be destination. For non-SSM destination addresses the IP system will not be
skipping to change at page 8, line 19 skipping to change at page 8, line 26
must be able to detect if there are multicast routers on its connected must be able to detect if there are multicast routers on its connected
links and if they support MSNIP operation. If no multicast routers are links and if they support MSNIP operation. If no multicast routers are
present or if the multicast routers are not MSNIP-capable then the IP present or if the multicast routers are not MSNIP-capable then the IP
system MUST default to flooding and immediately instruct applications to system MUST default to flooding and immediately instruct applications to
transmit. transmit.
An IP system controls transmission behaviour under the different An IP system controls transmission behaviour under the different
possible conditions by adapting its definition of the MSNIP-managed possible conditions by adapting its definition of the MSNIP-managed
multicast destination address range: multicast destination address range:
o On a link with multicast routers operating the MSNIP protocol the IP o On a link with multicast routers operating the MSNIP protocol the
system MUST use the SSM multicast destination address range as the IP system MUST use the SSM multicast destination address range as
MSNIP-managed range. IPv4 systems MUST use the contents of the SSM the MSNIP-managed range. IPv4 systems MUST use the contents of
Range option in received Multicast Router Advertisement messages [4] the SSM Range option in received Multicast Router Advertisement
to discover the configured SSM range. SSM range discovery is not messages [4] to discover the configured SSM range. SSM range
needed in IPv6 where the SSM destination address range is fixed. discovery is not needed in IPv6 where the SSM destination address
range is fixed.
o On a link not connected to a multicast routed infrastructure or on a o On a link not connected to a multicast routed infrastructure or
link with multicast routers that do not support MSNIP operation, the on a link with multicast routers that do not support MSNIP
IP system MUST use an empty range as its MSNIP-managed range. This operation, the IP system MUST use an empty range as its MSNIP-
forces applications transmitting to any multicast destination address managed range. This forces applications transmitting to any
to default to flooding thus providing backward compatibility. multicast destination address to default to flooding thus
providing backward compatibility.
As described in 4.1.1, an IP system can determine the status of a As described in 4.1.1, an IP system can determine the status of a
link and distinguish between the above two cases through the reception link and distinguish between the above two cases through the reception
of IPv4 Multicast Router Advertisement and Neighbor Discovery / ICMPv6 of IPv4 Multicast Router Advertisement and Neighbour Discovery / ICMPv6
messages. messages.
5. Requesting and Receiving Notifications 5. Requesting and Receiving Notifications
Like IGMP, MSNIP is an asymmetric protocol specifying different Like IGMP, MSNIP is an asymmetric protocol specifying different
behaviour for systems wishing to source traffic and for multicast behaviour for systems wishing to source traffic and for multicast
routers. Host IP systems multicast Host Interest Solicitation messages routers. Host IP systems multicast Host Interest Solicitation messages
to register for notification with their first-hop routers. Routers to register for notification with their first-hop routers. Routers
unicast Router Receiver Membership Reports to IP systems to notify them unicast Router Receiver Membership Reports to IP systems to notify them
of the arrival of the first or departure of the last receiver for a of the arrival of the first or departure of the last receiver for a
session. Note that a system may perform at the same time both of the session. Note that a system may perform at the same time both of the
above functions. An example is a router that wishes to source traffic. above functions. An example is a router that wishes to source traffic.
5.1. Host Interest Solicitation 5.1. Host Interest Solicitation
Source systems that wish to be managed by MSNIP periodically Source systems that wish to be managed by MSNIP periodically
transmit an Interest Solicitation message. This message is multicast transmit a Host Interest Solicitation message. This message is multicast
with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22)
or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest
Solicitation Interval] seconds. The Interest Solicitation message Solicitation Interval] seconds. The Host Interest Solicitation message
contains a holdtime which is set to [Interest Solicitation Holdtime] and contains a holdtime which is set to [Interest Solicitation Holdtime] and
instructs the multicast first-hop routers to maintain MSNIP state for instructs the multicast first-hop routers to maintain MSNIP state for
this IP system for the specified period. A generation ID is also this IP system for the specified period. Systems with multiple
included in the Interest Solicitation message to provide support for interfaces or multiple IP addresses per interface must originate
routers to detect IP system restarts (see section 8.1). Systems with separate Host Interest Solicitation messages from each of their IP
multiple interfaces or multiple IP addresses per interface must addresses that they wish to have managed by MSNIP. In practice a system
originate separate Host Interest Solicitation messages from each of with more than one IP address is treated by MSNIP as multiple IP
their IP addresses that they wish to have managed by MSNIP. In practice systems.
a system with more than one IP address is treated by MSNIP as multiple
IP systems.
When an IP system first comes up it transmits [Robustness Variable] When an IP system first comes up it transmits [Robustness Variable]
Interest Solicitation messages spaced by [Initial Interest Solicitation Host Interest Solicitation messages spaced by [Initial Interest
Interval] seconds. Solicitation Interval] seconds.
All MSNIP capable routers that receive an Interest Solicitation All MSNIP capable routers that receive a Host Interest Solicitation
message from an IP system, maintain a system interest record of the message from an IP system, maintain a system interest record of the
form: form:
(IP system address, holdtime timer) (IP system address, holdtime timer)
Each time an Interest Solicitation message is received from the IP Each time a Host Interest Solicitation message is received from the IP
system, the holdtime timer is reset to the holdtime in the received system, the holdtime timer is reset to the holdtime in the received
message. In addition the router may respond to the solicitation message message. In addition the router may respond to the solicitation message
with a Receiver Membership Report message described in section 5.2. The with a Receiver Membership Report message described in section 5.2. The
message contains a TRANSMIT record for each of the multicast destination message contains a TRANSMIT record for each of the multicast destination
addresses within the MSNIP-managed range for which the routing protocol addresses within the MSNIP-managed range for which the routing protocol
indicates there are receivers for this source system. indicates there are receivers for this source system.
The holdtime timer of a record counts down to zero. When the The holdtime timer of a record counts down to zero. When the
holdtime timer of a specific system interest record expires, the record holdtime timer of a specific system interest record expires, the record
is deleted. is deleted.
skipping to change at page 10, line 7 skipping to change at page 10, line 10
5.2. Router Receiver Membership Reports 5.2. Router Receiver Membership Reports
Receiver Membership Report messages are used by routers to Receiver Membership Report messages are used by routers to
communicate the receiver membership status of particular multicast communicate the receiver membership status of particular multicast
destination addresses to a specific IP system. Each message contains a destination addresses to a specific IP system. Each message contains a
list of transmission control records of either TRANSMIT or HOLD type list of transmission control records of either TRANSMIT or HOLD type
that instruct a system to respectively start or stop sending traffic on that instruct a system to respectively start or stop sending traffic on
this link to the specified multicast destination address. Receiver this link to the specified multicast destination address. Receiver
Membership Report messages are unicast to the target system. Membership Report messages are unicast to the target system.
In addition to reports sent in response to Interest Solicitation In addition to reports sent in response to Host Interest
messages, routers send unsolicited Receiver Membership Reports to IP Solicitation messages, routers send unsolicited Receiver Membership
systems when the receiver membership status reported by the multicast Reports to IP systems when the receiver membership status reported by
routing protocol changes for a specific source and multicast the multicast routing protocol changes for a specific source and
destination. Such reports are only sent if the multicast destination multicast destination. Such reports are only sent if the multicast
address is managed by MSNIP and the router has a system interest record destination address is managed by MSNIP and the router has a system
created by a previously received Interest Solicitation message with an interest record created by a previously received Host Interest
IP system address equal to the source address. If the source / Solicitation message with an IP system address equal to the source
destination pair satisfy these conditions then [Robustness Variable] address. If the source / destination pair satisfy these conditions then
Receiver Membership Reports are sent out spaced by [Unsolicited [Robustness Variable] Receiver Membership Reports are sent out spaced by
Membership Report Interval] seconds. If the membership status changes [Unsolicited Membership Report Interval] seconds. If the membership
again for the same destination address and source system while status changes again for the same destination address and source system
transmission of Receiver Membership Reports is still pending then the while transmission of Receiver Membership Reports is still pending then
pending report messages are canceled and a new set of [Robustness the pending report messages are canceled and a new set of [Robustness
Variable] messages indicating the new state are scheduled. Variable] messages indicating the new state are scheduled.
When an IP system receives a Receiver Membership Report message, When an IP system receives a Receiver Membership Report message,
for each of the TRANSMIT records listed in the message, it creates or for each of the TRANSMIT records listed in the message, it creates or
updates a transmission record of the form: updates a transmission record of the form:
(router address, source address, multicast address, holdtime timer) (router address, source address, multicast address, holdtime timer)
The router address is obtained from the source address on the IP header The router address is obtained from the source address on the IP header
of the received message. The source address is obtained from the of the received message. The source address is obtained from the
skipping to change at page 11, line 16 skipping to change at page 11, line 22
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 1: Per source-address (S) and multicast destination address (G) Figure 1: Per source-address (S) and multicast destination address (G)
state machine at an IP system state machine at an IP system
In tabular form, the state-machine is: In tabular form, the state-machine is:
+-----------+-----------------------------------------------------------+ +-------------------+---------------------------------------------------+
| | Event | | | Prev State |
| +----------+-----------+------------+-----------+-----------+ | Event +----------------+------------------+---------------+
|Prev State |New |Start |Stop |Recv |Recv last | | | No Info | Hold | Transmit |
| |Register |Manage |Manage |TRANSMIT |HOLD or | +-------------------+----------------+------------------+---------------+
| | | | | |timeout | | New Register | - | - | - |
+-----------+----------+-----------+------------+-----------+-----------+ | | Start new | | Start new |
| |Start new |-> Hold |- |- |- | +-------------------+----------------+------------------+---------------+
|No Info | |Stop ALL | | | | | | -> Hold | - | - |
| | |registered | | | | | Start Manage | Stop ALL | | |
+-----------+----------+-----------+------------+-----------+-----------+ | | registered | | |
| |- |- |-> No Info |-> |- | +-------------------+----------------+------------------+---------------+
|Hold | | | |Transmit | | | | - | -> No Info | -> No Info |
| | | |Stop ALL |Start ALL | | | Stop Manage | | Stop ALL | |
| | | |registered |registered | | | | | registered | |
+-----------+----------+-----------+------------+-----------+-----------+ +-------------------+----------------+------------------+---------------+
| |Start new |- |-> No Info |- |-> Hold | | | - | -> Transmit | - |
|Transmit | | | | |Stop ALL | | Recv TRANSMIT | | Start ALL | |
| | | | | |registered | | | | registered | |
+-----------+----------+-----------+------------+-----------+-----------+ +-------------------+----------------+------------------+---------------+
| Recv last HOLD | - | - | -> Hold |
| or timeout | | | Stop ALL |
| | | | registered |
+-------------------+----------------+------------------+---------------+
The events in state machine above have the following meaning: The events in the state machine above have the following meaning:
New register New register
A new application has registered through a call to A new application has registered through a call to
IPMulticastSourceRegister for this S and G. IPMulticastSourceRegister for this S and G.
Start manage Start manage
We received a SSM Range option in an MRD packet on the interface We received a SSM Range option in an MRD packet on the interface
that S belongs to that changed the status of G from a non-managed that S belongs to that changed the status of G from a non-managed
to a MSNIP-managed destination address. The SSM Range option is to a MSNIP-managed destination address. The SSM Range option is
only valid in IPv4. only valid in IPv4.
skipping to change at page 13, line 13 skipping to change at page 13, line 19
operated by each first-hop router. The initial state is No Info. operated by each first-hop router. The initial state is No Info.
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 2: Per IP source system (S) state machine at a router Figure 2: Per IP source system (S) state machine at a router
In tabular form, the state-machine is: In tabular form, the state-machine is:
+------------+----------------------------------------------------------+ +----------------------+------------------------------------------------+
| | Event | | | Prev State |
| +------------+-----------+--------------+------------------+ | Event +------------------------+-----------------------+
|Prev State | Receive | HIS | Receivers | Receivers | | | Not tracking | Tracking |
| | HIS | timeout | for new | of G leave | +----------------------+------------------------+-----------------------+
| | | | destination | | | | -> Tracking | - |
| | | | G | | | Receive HIS | Set HT to message | Set HT to message |
+------------+------------+-----------+--------------+------------------+ | | holdtime; Send ALL | holdtime; Send ALL |
| | -> | - | - | - | | | existing TRANSMITs | existing TRANSMITs |
| | Tracking | | | | +----------------------+------------------------+-----------------------+
| | Set HT to | | | | | HIS timeout | - | -> Not tracking |
|Not | message | | | | | | | |
|tracking | holdtime | | | | +----------------------+------------------------+-----------------------+
| | Send ALL | | | | | Receivers for new | - | - |
| | existing | | | | | destination G | | Send TRANSMIT for |
| | TRANSMITs | | | | | | | G |
+------------+------------+-----------+--------------+------------------+ +----------------------+------------------------+-----------------------+
| | Set HT to | -> Not | Send | Send HOLD | | Receivers of G | - | - |
| | message | tracking | TRANSMIT | for G | | leave | | Send HOLD for G |
|Tracking | holdtime | | for G | | +----------------------+------------------------+-----------------------+
| | Send ALL | | | |
| | existing | | | |
| | TRANSMITs | | | |
+------------+------------+-----------+--------------+------------------+
The events in state machine above have the following meaning: The events in state machine above have the following meaning:
Receive HIS Receive HIS
The router has received a Host Interest Solicitation from S. The router has received a Host Interest Solicitation from S.
HIS timeout HIS timeout
The holdtime timer (HT) in the host interest record associated with The holdtime timer (HT) in the host interest record associated with
S has expired. S has expired.
skipping to change at page 14, line 41 skipping to change at page 15, line 4
The following packet formats are valid for both IPv4 and IPv6. IP The following packet formats are valid for both IPv4 and IPv6. IP
version-specific values will be explicitly defined. version-specific values will be explicitly defined.
There are two message types of concern to the MSNIP protocol There are two message types of concern to the MSNIP protocol
described in this document: described in this document:
+-------------------+----------------------------+ +-------------------+----------------------------+
| Type Number (hex) | Message Name | | Type Number (hex) | Message Name |
+-------------------+----------------------------+ +-------------------+----------------------------+
| | |
| 0xXX | Host Interest Solicitation | | 0xXX | Host Interest Solicitation |
+-------------------+----------------------------+ +-------------------+----------------------------+
| 0xYY | Receiver Membership Report | | 0xYY | Receiver Membership Report |
+-------------------+----------------------------+ +-------------------+----------------------------+
8.1. Host Interest Solicitation Packet
A Interest Solicitation packet is periodically multicast by MSNIP Both the Host Interest Solicitation message and the Receiver
Membership Report message MUST not be forwarded by routers (see section
12). The Router Alert option [9] [10] MUST be included in the packet by
the router or host IP system transmitting the message. Routers receiving
Host Interest Solicitation messages and IP systems receiving Receiver
Membership Reports MUST not process a received MSNIP message if the
Router Alert option is not present.
8.1. Host Interest Solicitation Message
A Host Interest Solicitation message is periodically multicast by MSNIP
capable systems to declare interest in Receiver Membership Reports from capable systems to declare interest in Receiver Membership Reports from
multicast routers on the link. The Interest Solicitation message is multicast routers on the link. The Host Interest Solicitation message is
multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22)
or ALL_MLDv2_ROUTERS (TBA). or ALL_MLDv2_ROUTERS (TBA).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum | | Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 16 skipping to change at page 18, line 36
Robustness Variable Robustness Variable
The Robustness Variable allows tuning for the expected packet loss The Robustness Variable allows tuning for the expected packet loss
on a network. If a network is expected to be lossy, the Robustness on a network. If a network is expected to be lossy, the Robustness
Variable may be increased. MSNIP is robust to (Robustness Variable Variable may be increased. MSNIP is robust to (Robustness Variable
- 1) packet losses. The Robustness Variable MUST NOT be zero, and - 1) packet losses. The Robustness Variable MUST NOT be zero, and
SHOULD NOT be one. Default: 2 SHOULD NOT be one. Default: 2
Interest Solicitation Interval Interest Solicitation Interval
The interval used by MSNIP capable systems between transmissions of The interval used by MSNIP capable systems between transmissions of
Interest Solicitation messages. Default: 60 secs Host Interest Solicitation messages. Default: 60 secs
Interest Solicitation Holdtime Interest Solicitation Holdtime
The interval inserted in Interest Solicitation messages by systems The interval inserted in Host Interest Solicitation messages by
to instruct routers how long they should maintain system interest systems to instruct routers how long they should maintain system
state for. This MUST be ((the Robustness Variable) times (the interest state for. This MUST be ((the Robustness Variable) times
Interest Solicitation Interval) plus (one second)). (the Interest Solicitation Interval) plus (one second)).
Initial Interest Solicitation Interval Initial Interest Solicitation Interval
The interval used by systems to send out the initial Interest The interval used by systems to send out the initial Host Interest
Solicitation messages when they first come up. Default: 1 second. Solicitation messages when they first come up. Default: 1 second.
Unsolicited Membership Report Interval Unsolicited Membership Report Interval
The interval used by routers to send out a set of Membership Report The interval used by routers to send out a set of Membership Report
messages when the receiver membership changes for a specific messages when the receiver membership changes for a specific
system. Default: 1 second. system. Default: 1 second.
10. Possible Optimisations 10. Possible Optimisations
10.1. Suppressing HIS Messages 10.1. Suppressing HIS Messages
skipping to change at page 20, line 40 skipping to change at page 21, line 8
operate the Multicast Router Discovery protocol [3] on all its operate the Multicast Router Discovery protocol [3] on all its
downstream interfaces and advertise the MSNIP capability option (section downstream interfaces and advertise the MSNIP capability option (section
4.1.1) and SSM address range option (section 4.1.2). The MSNIP 4.1.1) and SSM address range option (section 4.1.2). The MSNIP
capability option should be advertised on downstream interfaces only if capability option should be advertised on downstream interfaces only if
it is included in MRD messages received on the upstream interface. The it is included in MRD messages received on the upstream interface. The
address range to be included in the SSM Range option MUST be determined address range to be included in the SSM Range option MUST be determined
by MRD and IGMP messages received on the upstream interface of the proxy by MRD and IGMP messages received on the upstream interface of the proxy
according to the rules in section 4.2. according to the rules in section 4.2.
In addition to the forwarding of MSNIP messages, an MLD proxy MUST In addition to the forwarding of MSNIP messages, an MLD proxy MUST
operate the IPv6 Neighbor Discovery protocol. The MSNIP capability operate the IPv6 Neighbour Discovery protocol. The MSNIP capability
option should be advertised on downstream interfaces when it is included option should be advertised on downstream interfaces when it is included
in IPv6 Neighbor Discovery messages received on the upstream interface. in IPv6 Neighbour Discovery messages received on the upstream interface.
12. Security Considerations 12. Security Considerations
We consider the ramifications of a forged message of each type. As We consider the ramifications of a forged message of each type. As
described in [1] and [2], IPSEC AH can be used to authenticate IGMP and described in [1] and [2], IPSEC AH can be used to authenticate IGMP and
MLD messages if desired. MLD messages if desired.
12.1. Receiver Membership Report attacks 12.1. Receiver Membership Report attacks
A DoS attack on a host could be staged through forged Receiver A DoS attack on a host could be staged through forged Receiver
skipping to change at page 21, line 19 skipping to change at page 21, line 32
reports, each with a large number of TRANSMIT records and a holdtime reports, each with a large number of TRANSMIT records and a holdtime
field set to a large value. The host will have to store and maintain the field set to a large value. The host will have to store and maintain the
transmission records specified in all of those reports for the duration transmission records specified in all of those reports for the duration
of the holdtime. This would consume both memory and CPU cycles in the of the holdtime. This would consume both memory and CPU cycles in the
host. host.
Forged Receiver Membership Report messages from the local network Forged Receiver Membership Report messages from the local network
can be easily traced. There are three measures necessary to defend can be easily traced. There are three measures necessary to defend
against externally forged reports: against externally forged reports:
o Routers SHOULD NOT forward Receiver Membership Reports. This is easier o Routers SHOULD NOT forward Receiver Membership Reports. This is
for a router to accomplish if the report carries the Router-Alert easier for a router to accomplish if the report carries the
option. Router-Alert option.
o Hosts SHOULD ignore Receiver Membership Reports without the Router- o Hosts SHOULD ignore Receiver Membership Reports without the
Alert option. Router-Alert option.
Note that a remote attack through the multicast routing protocol is Note that a remote attack through the multicast routing protocol is
possible. A remote site can originate join state for a large number of possible. A remote site can originate join state for a large number of
groups that will propagate through MSNIP to the target source host. groups that will propagate through MSNIP to the target source host.
Such attacks are considered a more significant problem for the routers Such attacks are considered a more significant problem for the routers
involved and are left up to the routing protocol security. involved and are left up to the routing protocol security.
HOLD records in forged Receiver Membership Report messages are not HOLD records in forged Receiver Membership Report messages are not
a significant threat as hosts track the individual interests of each a significant threat as hosts track the individual interests of each
first-hop router separately. Only by forging the source address of the first-hop router separately. Only by forging the source address of the
report message so that is appears to have originated from a real first- report message so that is appears to have originated from a real first-
hop router can the attacker cause the source to stop transmitting to a hop router can the attacker cause the source to stop transmitting to a
group that has valid receivers. Such forged messages can be detected by group that has valid receivers. Such forged messages can be detected by
the router itself. the router itself.
12.2. Host Interest Solicitation attacks 12.2. Host Interest Solicitation attacks
Forged Host Interest Solicitation messages can have two effects: Forged Host Interest Solicitation messages can have two effects:
o When non-existent source addresses are used the solicitation messages o When non-existent source addresses are used the solicitation
can create unwanted host record state on attached routers for the messages can create unwanted host record state on attached
duration of the holdtime specified in the message. routers for the duration of the holdtime specified in the
message.
o When a source address corresponding to an existing host is used in the o When a source address corresponding to an existing host is used
forged HIS message, receipt of the message by attached routers will in the forged HIS message, receipt of the message by attached
cause them to transmit Receiver Membership Reports messages for all routers will cause them to transmit Receiver Membership Reports
MSNIP-managed multicast destination addresses with receivers for the messages for all MSNIP-managed multicast destination addresses
target host. Although no additional state will be created in routers with receivers for the target host. Although no additional state
or hosts from this attack, bandwidth and CPU is wasted in both the will be created in routers or hosts from this attack, bandwidth
first-hop routers and the target host. and CPU is wasted in both the first-hop routers and the target
host.
Just like for the Receiver Membership Report message, attacks using Just like for the Receiver Membership Report message, attacks using
the Host Interest Solicitation message can be reduced by requiring the the Host Interest Solicitation message can be reduced by requiring the
use of the Router-Alert option on the message. use of the Router-Alert option on the message.
12.3. MSNIP Managed Range Discovery 12.3. MSNIP Managed Range Discovery
As discussed in [4] it is possible for directly connected systems As discussed in [4] it is possible for directly connected systems
to send forged Multicast Router Advertisement messages containing the to send forged Multicast Router Advertisement messages containing the
SSM Range Discovery option. As the SSM Range Discovery option determines SSM Range Discovery option. As the SSM Range Discovery option determines
the MSNIP-managed range under IPv4, such forged messages can temporarily the MSNIP-managed range under IPv4, such forged messages can temporarily
replace the managed range map with incorrect information in receiving replace the managed range map with incorrect information in receiving
hosts. An incorrect mapping can have two effects: hosts. An incorrect mapping can have two effects:
o Applications using a multicast destination address within the real SSM o Applications using a multicast destination address within the
range that have no valid receivers can be tricked into thinking that real SSM range that have no valid receivers can be tricked into
their chosen destination address is no longer an SSM address and will thinking that their chosen destination address is no longer an
therefore start transmitting data. SSM address and will therefore start transmitting data.
o Applications using group addresses outside the valid SSM range can be o Applications using group addresses outside the valid SSM range
tricked into thinking that they are using an SSM destination address can be tricked into thinking that they are using an SSM
and therefore prevented from transmitting data. destination address and therefore prevented from transmitting
data.
The Multicast Router Discovery SSM Range Option specification The Multicast Router Discovery SSM Range Option specification
suggests that a router receiving a Multicast Router Advertisement with suggests that a router receiving a Multicast Router Advertisement with
an inconsistent SSM Range Option log the event to the operator. Such an inconsistent SSM Range Option log the event to the operator. Such
logging will enable tracking of this type of attack. logging will enable tracking of this type of attack.
13. IANA Considerations 13. IANA Considerations
This document introduces the following new types and options that This document introduces the following new types and options that
require allocation by IANA: require allocation by IANA:
o Two new IGMP messages for Host Interest Solicitation and Receiver o Two new IGMP messages for Host Interest Solicitation and Receiver
Membership Report. Each of these messages requires a new IGMP type Membership Report. Each of these messages requires a new IGMP
value to be assigned by IANA [13]. type value to be assigned by IANA [13].
o The new MSNIP Operation option for the Multicast Router Discovery o The new MSNIP Operation option for the Multicast Router Discovery
protocol. This option requires a new MRD type value to be assigned by protocol. This option requires a new MRD type value to be
IANA. assigned by IANA.
o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6 o The new MSNIP Operation option for the Neighbour Discovery /
protocol. This option requires a new NDP / ICMPv6 type value to be ICMPv6 protocol. This option requires a new NDP / ICMPv6 type
assigned by IANA. value to be assigned by IANA.
14. Acknowledgments 14. Acknowledgments
The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless
Eckert, Haixiang He, Pekka Savola and Karen Kimball for their Eckert, Haixiang He, Pekka Savola and Karen Kimball for their
contribution to this specification. contribution to this specification.
15. Normative References 15. Normative References
[1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet [1] Cain B., Deering S., Fenner W., Kouvelas I. and A. Thyagarajan,
Group Management Protocol, Version 3", RFC 3376. "Internet Group Management Protocol, Version 3", RFC 3376.
[2] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for [2] Vida R. and Costa L., "Multicast Listener Discovery Version 2
IPv6", work in progress, <draft-vida-mld-v2-06.txt>, November 2002. (MLDv2) for IPv6", work in progress, <draft-vida-mld-v2-07.txt>,
June 2003.
[3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In [3] Biswas S. and Haberman B., "IGMP Multicast Router Discovery", Work
Progress, <draft-ietf-idmr-igmp-mrdisc-10.txt>, January 2003. In Progress, <draft-ietf-idmr-igmp-mrdisc-10.txt>, January 2003.
[4] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in [4] Kouvelas I., "Multicast Router Discovery SSM Range Option", work in
progress, <draft-ietf-magma-mrdssm-02.txt>, February 2003. progress, <draft-ietf-magma-mrdssm-03.txt>, June 2003.
[5] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) [5] Conta A. and Deering S., "Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)", RFC 2463. for the Internet Protocol Version 6 (IPv6)", RFC 2463.
[6] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP [6] Narten T., Nordmark E. and Simpson W., "Neighbour Discovery for IP
Version 6 (IPv6)", RFC 2461. Version 6 (IPv6)", RFC 2461.
[7] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in [7] Holbrook H. and Cain B., "Source-Specific Multicast for IP", work in
progress, <draft-ietf-ssm-arch-02.txt>, March 2003. progress, <draft-ietf-ssm-arch-02.txt>, March 2003.
[8] S. Kent, R. Atkinson, "Security Architecture for the Internet [8] Kent S. and Atkinson R., "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[9] D. Katz, "IP Router Alert Option", RFC 2113. [9] Katz D., "IP Router Alert Option", RFC 2113.
[10] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711. [10] Partridge C. and Jackson A., "IPv6 Router Alert Option", RFC 2711.
16. Informative References 16. Informative References
[11] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [11] Fenner W., Handley M., Holbrook H. and Kouvelas I., "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress, <draft-ietf-pim-sm- Specification (Revised)", Work In Progress, <draft-ietf-pim-sm-
v2-new-07.txt>, March 2003. v2-new-07.txt>, March 2003.
[12] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 [12] Albanna Z., Almeroth K. and Meyer D., "IANA Guidelines for IPv4
Multicast Address Allocation", Best Current Practices, <draft-ietf- Multicast Address Allocation", Best Current Practices, <draft-ietf-
iana-IPv4-mcast-guidelines-00.txt>, 2001. iana-IPv4-mcast-guidelines-00.txt>, 2001.
[13] W. Fenner, "IANA Considerations for IGMP", [13] Fenner W., "IANA Considerations for IGMP",
http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP
57), February 2002. 57), February 2002.
[14] W. Fenner, H. He, B. Haberman, H. Sandick, "IGMP / MLD-based [14] Fenner W., He H., Haberman B. and Sandick H., "IGMP / MLD-based
Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp- Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp-
proxy-02.txt, March 2003. proxy-02.txt, March 2003.
[15] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast
Addresses", RFC 3306, August 2002.
Authors' Addresses Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
One Park Drive, Suite 300 1 Park Drive, Suite 300
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
bkhabs@nc.rr.com brian@innovationslab.net
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
holbrook@cisco.com holbrook@cisco.com
Isidor Kouvelas Isidor Kouvelas
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
skipping to change at page 25, line 42 skipping to change at page 25, line 42
Copyright (C) The Internet Society (Apr 1 2003). All Rights Reserved. Copyright (C) The Internet Society (Apr 1 2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organisations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 End of changes. 65 change blocks. 
181 lines changed or deleted 201 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/