< draft-ietf-l2tpext-mcast-04.txt   draft-ietf-l2tpext-mcast-05.txt >
Network Working Group G. Bourdon Network Working Group G. Bourdon
Internet Draft France Telecom Internet Draft France Telecom
Document: draft-ietf-l2tpext-mcast-04.txt July 2004 Document: draft-ietf-l2tpext-mcast-05.txt October 2004
Category: Experimental Category: Experimental
Extensions to support efficient carrying of Extensions to support efficient carrying of
multicast traffic in Layer-2 Tunneling Protocol (L2TP) multicast traffic in Layer-2 Tunneling Protocol (L2TP)
<draft-ietf-l2tpext-mcast-04.txt> <draft-ietf-l2tpext-mcast-05.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 10 skipping to change at page 2, line 10
1.2. Terminology.................................................3 1.2. Terminology.................................................3
2. Motivation for a session-based solution.....................4 2. Motivation for a session-based solution.....................4
3. Control Connection establishment............................5 3. Control Connection establishment............................5
3.1. Negotiation phase...........................................5 3.1. Negotiation phase...........................................5
3.2. Multicast Capability AVP (SCCRQ, SCCRP).....................5 3.2. Multicast Capability AVP (SCCRQ, SCCRP).....................5
4. L2TP multicast session establishment decision...............6 4. L2TP multicast session establishment decision...............6
4.1. Multicast states in LNS.....................................6 4.1. Multicast states in LNS.....................................6
4.2. Group state determination...................................7 4.2. Group state determination...................................7
4.3. Triggering..................................................8 4.3. Triggering..................................................8
4.4. Multicast traffic sent from group members...................9 4.4. Multicast traffic sent from group members...................9
5. L2TP multicast session opening process......................9 5. L2TP multicast session opening process.....................10
5.1. Multicast-Session-Request (MSRQ)...........................10 5.1. Multicast-Session-Request (MSRQ)...........................10
5.2. Multicast-Session-Response (MSRP)..........................11 5.2. Multicast-Session-Response (MSRP)..........................11
5.3. Multicast-Session-Established (MSE)........................11 5.3. Multicast-Session-Established (MSE)........................12
6. Session maintenance and management.........................12 6. Session maintenance and management.........................12
6.1. Multicast-Session-Information (MSI)........................12 6.1. Multicast-Session-Information (MSI)........................12
6.2. Outgoing Sessions List updates.............................13 6.2. Outgoing Sessions List updates.............................13
6.2.1. New Outgoing Sessions AVP (MSI)............................13 6.2.1. New Outgoing Sessions AVP (MSI)............................13
6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI)............14 6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI)............14
6.2.3. Withdraw Outgoing Sessions AVP (MSI).......................15 6.2.3. Withdraw Outgoing Sessions AVP (MSI).......................15
6.3. Multicast Packets Priority AVP (MSI).......................15 6.3. Multicast Packets Priority AVP (MSI).......................16
6.3.1. Global configuration.......................................17 6.3.1. Global configuration.......................................17
6.3.2. Individual configuration...................................17 6.3.2. Individual configuration...................................17
6.3.3. Priority...................................................17 6.3.3. Priority...................................................17
7. Multicast session teardown.................................17 7. Multicast session teardown.................................18
7.1. Operations.................................................18 7.1. Operations.................................................18
7.2. Multicast-Session-End-Notify (MSEN)........................18 7.2. Multicast-Session-End-Notify (MSEN)........................19
7.3. Result Codes...............................................19 7.3. Result Codes...............................................19
8. Traffic merging............................................19 8. Traffic merging............................................20
9. IANA Considerations........................................20 9. IANA Considerations........................................20
10. Security Considerations....................................20 10. Security Considerations....................................21
11. References.................................................21 11. References.................................................21
11.1. Normative References.......................................21
11.2. Informative References.....................................22
12. Acknowledgments............................................22 12. Acknowledgments............................................22
13. Author's Addresses.........................................22 13. Author's Addresses.........................................22
Appendix A. Examples of group states determination................22 Appendix A. Examples of group states determination................23
1. Introduction 1. Introduction
The deployment of IP multicast-based services may have to deal with The deployment of IP multicast-based services may have to deal with
L2TP tunnel engineering. From this perspective, the forwarding of L2TP tunnel engineering. From this perspective, the forwarding of
multicast data within L2TP sessions may impact the throughput of L2TP multicast data within L2TP sessions may impact the throughput of L2TP
tunnels because the same traffic may be sent multiple times within tunnels because the same traffic may be sent multiple times within
the same L2TP tunnel, but in different sessions. This proposal aims the same L2TP tunnel, but in different sessions. This proposal aims
to reduce this impact by applying replication mechanism of multicast to reduce this impact by applying replication mechanism of multicast
traffic only when necessary. traffic only when necessary.
The solution described herein provides a mechanism for transmitting The solution described herein provides a mechanism for transmitting
multicast data only once for all the L2TP sessions that have been multicast data only once for all the L2TP sessions that have been
established in a tunnel, each multicast flow having a dedicated L2TP established in a tunnel, each multicast flow having a dedicated L2TP
session. session.
Within the context of deploying IP multicast-based services, it is Within the context of deploying IP multicast-based services, it is
assumed that the routers of the IP network that embed a L2TP Network assumed that the routers of the IP network that embed a L2TP Network
Server (LNS) capability may be involved in the forwarding of Server (LNS) capability may be involved in the forwarding of
multicast data, towards users who access the network through an L2TP multicast data, towards users who access the network through an L2TP
tunnel. Then the LNS is in charge of replicating the multicast data tunnel. Then the LNS is in charge of replicating the multicast data
for a multicast group G for each L2TP session that is used by a for each L2TP session that is used by a receiver who has requested a
receiver who has actually subscribed to group G. The solution multicast flow. The solution described here gives the ability for a
described here gives the ability for a LNS to send multicast data LNS to send multicast data only once and let the L2TP Access
only once and let the L2TP Access Concentrator (LAC) perform the Concentrator (LAC) perform the traffic replication. By doing so, it
traffic replication. By doing so, it is expected to spare is expected to spare transmission resources in the core network that
transmission resources in the core network that supports L2TP supports L2TP tunnels. This multicast extension to L2TP is designed
tunnels. This multicast extension to L2TP is designed so that it does so that it does not affect the behavior of L2TP equipment under
not affect the behavior of L2TP equipment under normal conditions. A normal conditions. A solution to carry multicast data only once in a
solution to carry multicast data only once in a L2TP tunnel is L2TP tunnel is interesting for service providers since edge devices
interesting for service providers since edge devices are aggregating are aggregating more and more users. This is particularly true for
more and more users. This is particularly true for operators who are operators who are deploying xDSL (Digital Subscriber Line) services
deploying xDSL (Digital Subscriber Line) services and cable and cable infrastructures. Therefore, L2TP tunnels that may be
infrastructures. Therefore, L2TP tunnels that may be supported by the supported by the network will have to carry multiple redundant
network will have to carry multiple redundant multicast data more multicast data more often. The solution described in this document
often. The solution described in this document applies to downstream applies to downstream traffic exclusively, i.e. data coming from the
traffic exclusively, i.e. data coming from the LNS towards end-users LNS towards end-users connected to the LAC. This downstream multicast
connected to the LAC. This downstream multicast traffic is not framed traffic is not framed by the LNS but by the LAC, thus ensuring
by the LNS but by the LAC, thus ensuring compatibility for all users compatibility for all users in a common tunnel whatever the framing
in a common tunnel whatever the framing scheme. scheme.
1.1. Conventions used in this document 1.1. Conventions used in this document
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
Unicast session Unicast session
skipping to change at page 7, line 4 skipping to change at page 7, line 8
states of the form (group, filter-mode, source-list): states of the form (group, filter-mode, source-list):
- group: denotes the multicast group - group: denotes the multicast group
- filter-mode: either INCLUDE or EXCLUDE, as defined in - filter-mode: either INCLUDE or EXCLUDE, as defined in
[RFC3376] [RFC3376]
- source-list: list of IP unicast addresses from which multicast - source-list: list of IP unicast addresses from which multicast
reception is desired or not, depending on the filter-mode. reception is desired or not, depending on the filter-mode.
2- According to each group state, the LNS will create one or multiple 2- According to each group state, the LNS will create one or multiple
replication contexts, depending on the filter-mode for the considered replication contexts, depending on the filter-mode for the considered
group and the local policy configured in the LNS. group and the local policy configured in the LNS.
For groups in INCLUDE mode, the LNS SHOULD implement two different For groups in INCLUDE mode, the LNS SHOULD implement two different
policies: policies:
- One session per source: the LNS creates one replication - One session per (source, group) pair: the LNS creates one
context per (group, source) pair. replication context per (source, group) pair.
or or
- One session per group: the LNS creates one replication context - One session per group: the LNS creates one replication context
per (group, source-list) pair. per (source-list, group) pair.
For groups in EXCLUDE mode, the LNS will create one replication For groups in EXCLUDE mode, the LNS will create one replication
context per (group, list of sources excluded by *all* the receivers). context per (list of sources excluded by *all* the receivers, group).
The list of sources represents the intersection of the sets, not the
union.
3- For each replication context, the LNS will create one L2TP 3- For each replication context, the LNS will create one L2TP
multicast session (if threshold conditions are met, see Section 4.3) multicast session (if threshold conditions are met, see Section 4.3)
and its associated Outgoing Session List (OSL). The OSL lists L2TP and its associated Outgoing Session List (OSL). The OSL lists L2TP
sessions that requested the multicast flow corresponding to the group sessions that requested the multicast flow corresponding to the group
and the associated source-filtering properties. There is one OSL per and the associated source-filtering properties. There is one OSL per
replication context, i.e. per L2TP multicast session. replication context, i.e. per L2TP multicast session.
For a group member running a SFGMP, it is therefore possible to For a group member running a SFGMP, it is therefore possible to
receive multicast traffic from sources that have been explicitly receive multicast traffic from sources that have been explicitly
excluded in its SFGMP membership report if other group members in the excluded in its SFGMP membership report if other group members in the
same L2TP tunnel wish to receive packets from these sources. This same L2TP tunnel wish to receive packets from these sources. This
behavior is comparable to the case where group members are connected behavior is comparable to the case where group members are connected
to the same network. When a group is in EXCLUDE mode or in INCLUDE to the same multi-access network. When a group is in EXCLUDE mode or
mode with a policy allowing one session per (group, source-list), in INCLUDE mode with a policy allowing one session per (group,
sharing the same L2TP tunnel is equivalent to be connected to the source-list), sharing the same L2TP tunnel is equivalent to be
same network from a multicast point of view. For groups in INCLUDE connected to the same multi-access network in term of multicast
mode with a policy allowing one session per source, the behavior is traffic received. For groups in INCLUDE mode with a policy allowing
slightly improved since there is one L2TP multicast session per one L2TP multicast session per (source, group), the behavior is
(source, group), hence preventing group members to receive traffic slightly improved because it prevents group members to receive
from non-requested sources. On the other hand, this policy traffic from non-requested sources. On the other hand, this policy
potentially increases the number of L2TP multicast sessions to potentially increases the number of L2TP multicast sessions to
establish and maintain. Examples are provided in Appendix A. establish and maintain. Examples are provided in Appendix A.
In order for the LAC to forward the multicast traffic received In order for the LAC to forward the multicast traffic received
through the L2TP multicast session to group members, the LNS sends through the L2TP multicast session to group members, the LNS sends
the OSL to the LAC for the related multicast session (see Section 6). the OSL to the LAC for the related multicast session (see Section 6).
4.2. Group state determination 4.2. Group state determination
Source Filtering Group Management Protocols require querier routers Source Filtering Group Management Protocols require querier routers
to keep a filter-mode per group per attached network, to condense the to keep a filter-mode per group per attached network, to condense the
total desired reception state of a group to a minimum set such that total desired reception state of a group to a minimum set such that
all systems' memberships are satisfied. all systems' memberships are satisfied.
Within the context of L2TP, each L2TP session has to be considered as Within the context of L2TP, each L2TP session has to be considered as
an attached network by GMP and SFGMP protocols. When activating L2TP an attached network by GMP and SFGMP protocols. When activating L2TP
multicast extension, each L2TP Control Connection has to be multicast extension, each L2TP Control Connection has to be
considered as a pseudo attached network as well, in order to condense considered as a pseudo attached network as well in order to condense
group membership reports for every L2TP session in the tunnel. group membership reports for every L2TP session in the tunnel.
Control Connection-related activity exclusively focuses on filter-
mode and source-list information processing, whatever GMP/SFGMP
protocol machinery.
The rules applied to determine the appropriate filter-mode and Therefore, a list of group states is maintained for each L2TP Control
source-list for an attached network are described in SFGMP Connection into which the membership information of each of its L2TP
specifications ([RFC3376], [RFC3810]), including the case where sessions is merged. This list of group states is a set of membership
different versions of GMP or SFGMP protocols are in use records of the form (group, filter-mode, source-list).
simultaneously. Group timers and source timers must therefore be Each group state represents the result of a merging process applied
maintained for every L2TP tunnel that will convey multicast traffic. to subscriptions on L2TP sessions of a Control Connection for a
considered group. This merging process is performed in three steps:
1- Conversion of any GMP subscription into SFGMP subscription
(IGMPv1/v2 to IGMPv3, MLDv1 to MLDv2);
2- Removal of subscription timers and, if filter-mode is
EXCLUDE, sources with source timer > 0;
3- Then, resulting subscription are merged using merging rules
described in SFGMP specifications ([RFC3376] Section 3.2,
[RFC3810] Section 4.2).
When the LNS activates a GMP protocol, the filter used is always in This process is also described in [PROXY]. Examples of group state
EXCLUDE mode, with an empty source-list (equivalent to a (*, G) determination are provided in Appendix A.
multicast state).
4.3. Triggering 4.3. Triggering
The rules to be enforced by the LNS so as to decide when to open a The rules to be enforced by the LNS so as to decide when to open a
dedicated L2TP multicast session for a multicast group SHOULD be dedicated L2TP multicast session for a multicast group SHOULD be
configurable by the LNS administrator. This would typically happen configurable by the LNS administrator. This would typically happen
whenever a threshold of MULTICAST_SESSION_THRESHOLD whenever a threshold of MULTICAST_SESSION_THRESHOLD
receivers/sessions referenced in a replication context is reached. receivers/sessions referenced in a replication context is reached.
This threshold value SHOULD be valued at 2 by default, if we consider This threshold value SHOULD be valued at 2 by default, if we consider
that it is worth opening a dedicated L2TP multicast session for two that it is worth opening a dedicated L2TP multicast session for two
skipping to change at page 8, line 44 skipping to change at page 9, line 4
Whenever an OSL gets empty, the LNS MUST stop sending multicast Whenever an OSL gets empty, the LNS MUST stop sending multicast
traffic over the corresponding L2TP multicast session. Then the L2TP traffic over the corresponding L2TP multicast session. Then the L2TP
multicast session MUST be torn down as described in Section 7 of this multicast session MUST be torn down as described in Section 7 of this
document. document.
Filter-mode changes for a group can also trigger the opening or the Filter-mode changes for a group can also trigger the opening or the
termination of L2TP multicast session(s): termination of L2TP multicast session(s):
a- From INCLUDE mode to EXCLUDE mode a- From INCLUDE mode to EXCLUDE mode
When a group state filter-mode switches from INCLUDE to EXCLUDE, only When a group state filter-mode switches from INCLUDE to EXCLUDE, only
one replication context (and its associated L2TP multicast session) one replication context (and its associated L2TP multicast session)
issued from this group state can exist (see Section 4.1). The LNS issued from this group state can exist (see Section 4.1). The LNS
SHOULD keep one replication context previously created for this group SHOULD keep one replication context previously created for this group
state and has to update it with: state and has to update it with:
-a new source-list that has to be excluded from forwarding -a new source-list that has to be excluded from forwarding
-a new OSL -a new OSL
The LNS MUST send an OSL update to the LAC to reflect L2TP sessions The LNS MUST send an OSL update to the LAC to reflect L2TP sessions
list changes (section 6.2), whenever appropriate. The unused L2TP list changes (section 6.2), whenever appropriate. The unused L2TP
multicast sessions that correspond to previously created replication multicast sessions that correspond to previously created replication
contexts for the group SHOULD be terminated, either actively or contexts for the group SHOULD be terminated, either actively or
passively by emptying their corresponding OSLs. passively by emptying their corresponding OSLs.
The remaining L2TP multicast session MAY also be terminated if the The remaining L2TP multicast session MAY also be terminated if the
number of receivers is below a predefined threshold (see Section 7). number of receivers is below a predefined threshold (see Section 7).
To limit the duration of temporary packet loss or duplicates to
receivers, the LNS has to minimize delay between OSL updates messages
sent to the LAC. Therefore, one can assume that terminating a
multicast session passively gives the smoothest transition.
b- From EXCLUDE mode to INCLUDE mode b- From EXCLUDE mode to INCLUDE mode
When a group state filter-mode switches from EXCLUDE to INCLUDE, When a group state filter-mode switches from EXCLUDE to INCLUDE,
multiple replication contexts issued by this group state may be multiple replication contexts issued by this group state may be
created (see Section 4.1). The LNS SHOULD keep the replication created (see Section 4.1). The LNS SHOULD keep the replication
context previously created for this group state and has to update it context previously created for this group state and has to update it
accordingly with the following information: accordingly with the following information:
-a new list of sources that has to be forwarded, this list -a new list of sources that has to be forwarded, this list
having only one record if there is one replication context per having only one record if there is one replication context per
(group, source) (group, source)
-a new OSL -a new OSL
The LNS MUST send an OSL update to the LAC to reflect L2TP sessions The LNS MUST send an OSL update to the LAC to reflect L2TP sessions
list changes, whenever appropriate. If the LNS is configured to list changes, whenever appropriate. If the LNS is configured to
create one replication context per (group, source), L2TP multicast create one replication context per (group, source), L2TP multicast
sessions will be opened in addition to the existing one, depending on sessions will be opened in addition to the existing one, depending on
the number of sources for the group. the number of sources for the group.
If new L2TP multicast sessions need to be opened, the LNS SHOULD wait
until these multicast sessions are established before updating the
OSL of the original multicast session. To limit the duration of
temporary packet loss or duplicates to receivers, the LNS has to
minimize delay between OSL updates messages sent to the LAC.
4.4. Multicast traffic sent from group members 4.4. Multicast traffic sent from group members
The present document proposes a solution to enhance the forwarding of The present document proposes a solution to enhance the forwarding of
downstream multicast traffic exclusively, i.e. data coming from the downstream multicast traffic exclusively, i.e. data coming from the
LNS towards end-users connected to the LAC. LNS towards end-users connected to the LAC.
In the case where a group member that uses a L2TP session is also a In the case where a group member that uses a L2TP session is also a
multicast source for traffic conveyed in a multicast session, multicast source for traffic conveyed in a multicast session,
datagrams may be sent back to the source. To prevent this behavior, datagrams may be sent back to the source. To prevent this behavior,
two options can be used in the LNS: two options can be used in the LNS:
skipping to change at page 20, line 40 skipping to change at page 21, line 10
error code : TBA11 error code : TBA11
o No multicast traffic for the group : TBA12 o No multicast traffic for the group : TBA12
o No more receivers : TBA13 o No more receivers : TBA13
o No more receivers (filter-mode change): TBA14 o No more receivers (filter-mode change): TBA14
IANA will assign, register and maintain values for these new IANA will assign, register and maintain values for these new
attributes ([RFC3438]). attributes ([RFC3438]).
10. Security Considerations 10. Security Considerations
It is possible for one receiver to be able to make additional
multicast traffic that has not been requested go down the link of
another receiver. This can happen if a single replication context per
group is used in INCLUDE mode with receivers having divergent source
lists, as well as in EXCLUDE mode if a receiver has a source list not
shared by another. This behavior can be encountered every time
receivers are connected to a common multi-access network.
The extension described in this document does not introduce any The extension described in this document does not introduce any
additional security issues as far as the activation of the L2TP additional security issues as far as the activation of the L2TP
protocol is concerned. protocol is concerned.
Injecting appropriate control packets in the tunnel towards a LAC to Injecting appropriate control packets in the tunnel towards a LAC to
modify Outgoing Session List and flood end-users with unwanted modify Outgoing Session List and flood end-users with unwanted
multicast traffic is only possible if the control connection is multicast traffic is only possible if the control connection is
hacked. As for any reception of illegitimate L2TP control messages: hacked. As for any reception of illegitimate L2TP control messages:
- If the spoofed control message embeds consistent sequence - If the spoofed control message embeds consistent sequence
skipping to change at page 21, line 4 skipping to change at page 21, line 30
protocol is concerned. protocol is concerned.
Injecting appropriate control packets in the tunnel towards a LAC to Injecting appropriate control packets in the tunnel towards a LAC to
modify Outgoing Session List and flood end-users with unwanted modify Outgoing Session List and flood end-users with unwanted
multicast traffic is only possible if the control connection is multicast traffic is only possible if the control connection is
hacked. As for any reception of illegitimate L2TP control messages: hacked. As for any reception of illegitimate L2TP control messages:
- If the spoofed control message embeds consistent sequence - If the spoofed control message embeds consistent sequence
numbers, next messages will appear out of synch yielding the control numbers, next messages will appear out of synch yielding the control
connection to terminate. connection to terminate.
- If sequence numbers are inconsistent with current control - If sequence numbers are inconsistent with current control
connection states, the spoofed control message will be queued or connection states, the spoofed control message will be queued or
discarded, as described in [RFC2661] section 5.8. discarded, as described in [RFC2661] section 5.8.
The activation of the L2TP multicast capability on a LAC could make The activation of the L2TP multicast capability on a LAC could make
the equipment more sensitive to Denial of Service attacks if the the equipment more sensitive to Denial of Service attacks if the
control connection or the related LNS is hacked. The LAC might also control connection or the related LNS is hacked. The LAC might also
be sensitive to the burden generated by the additional replication be sensitive to the burden generated by the additional replication
work. work.
As mentioned in [RFC2661] section 9.2, securing L2TP requires that As mentioned in [RFC2661] section 9.2, securing L2TP requires that
the underlying transport makes encryption, integrity and the underlying transport makes encryption, integrity and
authentication services available for all L2TP traffic, including authentication services available for all L2TP traffic, including
L2TP multicast traffic (control and data). L2TP multicast traffic (control and data).
11. References 11. References
11.1. Normative References
[RFC1112] S. Deering, "Host Extensions for IP Multicasting", [RFC1112] S. Deering, "Host Extensions for IP Multicasting",
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994. 51, RFC 1661, July 1994.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] W. Fenner, "Internet Group Management Protocol, Version [RFC2236] W. Fenner, "Internet Group Management Protocol, Version
skipping to change at page 22, line 5 skipping to change at page 22, line 29
Version 3", RFC 3376, October 2002. Version 3", RFC 3376, October 2002.
[RFC3438] W. Townsley, "Layer Two Tunneling Protocol (L2TP) [RFC3438] W. Townsley, "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA) Internet Assigned Numbers Authority (IANA)
Considerations Update", RFC 3438, December 2002. Considerations Update", RFC 3438, December 2002.
[RFC3810] Vida, R., L. Costa, S.Fdida, S. Deering, B. Fenner, I. [RFC3810] Vida, R., L. Costa, S.Fdida, S. Deering, B. Fenner, I.
Kouvelas, and B. Haberman, "Multicast Listener Discovery Kouvelas, and B. Haberman, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
11.2. Informative References
[PROXY] Fenner, B., He, H., Haberman, B., Sandick, H.,
"IGMP/MLD-based Multicast Forwarding ("IGMP/MLD
Proxying")", Work in Progress.
12. Acknowledgments 12. Acknowledgments
Thanks to Christian Jacquenet for all the corrections done on this Thanks to Christian Jacquenet for all the corrections done on this
document and his precious advice, Pierre Levis for his contribution document and his precious advice, Pierre Levis for his contribution
about IGMP, Francis Houllier for PPP considerations and Xavier Vinet about IGMP, Francis Houllier for PPP considerations and Xavier Vinet
for his input about thresholds. Many thanks to W. Mark Townsley, for his input about thresholds. Many thanks to W. Mark Townsley,
Isidor Kouvelas and Brian Haberman for their highly valuable input on Isidor Kouvelas and Brian Haberman for their highly valuable input on
protocol definition. protocol definition.
13. Author's Addresses 13. Author's Addresses
 End of changes. 28 change blocks. 
57 lines changed or deleted 87 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/