numbers, next messages will appear out of synch, yielding the
control connection to terminate.
- If sequence numbers are inconsistent with current control
connection states, the spoofed control message will be queued
or discarded, as described in [RFC2661], Section 5.8.
The activation of the L2TP multicast capability on the LAC could make
the equipment more sensitive to Denial of Service attacks if the
control connection or the related LNS is hacked. The LAC might also
be sensitive to the burden generated by the additional replication
work.
As mentioned in [RFC2661], Section 9.2, securing L2TP requires that
the underlying transport make encryption, integrity, and
authentication services available for all L2TP traffic, including
L2TP multicast traffic (control and data).
11. References
11.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC
2661, August 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
Assigned Numbers Authority (IANA) Considerations Update",
BCP 68, RFC 3438, December 2002.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September
2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
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. Acknowledgements
Thanks to Christian Jacquenet for all the corrections done on this
document and his precious advice, to Pierre Levis for his
contribution about IGMP, to Francis Houllier for PPP considerations,
and to Xavier Vinet for his input about thresholds. Many thanks to
W. Mark Townsley, Isidor Kouvelas, and Brian Haberman for their
highly valuable input on protocol definition.
Appendix A. Examples of Group States Determination
*Example 1:
All users are managed in the same control connection.
Users {1, 2, 3} subscribe to (Group G1, EXCLUDE {})
Users {3, 4, 5} subscribe to (Group G2, EXCLUDE {})
Group states for this L2TP tunnel will be:
(G1, EXCLUDE, {})
(G2, EXCLUDE, {})
Therefore, two replication contexts will be created:
-RC1:
(*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(*, G2) packets, Multicast Session MS2, OSL = 3, 4, 5
*Example 2:
All users are managed in the same control connection.
Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1})
Users {4, 5, 6} subscribe to (Group G1, INCLUDE {S1,S2})
Users {7, 8, 9} subscribe to (Group G1, INCLUDE {S2})
The group state for this L2TP tunnel will be:
(G1, INCLUDE, {S1, S2)})
If the LNS policy allows one replication context per (group, source),
two replication contexts will be created:
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4, 5, 6
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 4, 5, 6, 7, 8, 9
If the LNS policy allows one replication context per (group, source-
list), one replication context will be created:
-RC1:
({S1, S2}, G1) packets, Multicast Session MS1, OSL = [1..9]
*Example 3:
All users are managed in the same control connection.
Users {1, 2} subscribe to (Group G1, EXCLUDE {S1})
User {3} subscribes to (Group G1, EXCLUDE {S1, S2})
The group state for this L2TP tunnel will be:
(G1, EXCLUDE, {S1})
Therefore, one replication context will be created:
-RC1:
(*-{S1}, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
Next, user {4} subscribes to (Group G1, INCLUDE {S1}). The group
state for the L2TP tunnel is changed to:
(G1, EXCLUDE, {})
The replication context RC1 is changed to:
-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4
*Example 4:
All users are managed in the same control connection. The LNS policy
allows one replication context per (group, source).
Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1, S2})
The group state for this L2TP tunnel will be:
(G1, INCLUDE, {S1, S2)})
Therefore, two replication contexts will be created:
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
Next, user {4} subscribes to (Group G1, EXCLUDE {}), equivalent to an
IGMPv2 membership report. The group state for the L2TP tunnel is
changed to:
(G1, EXCLUDE, {})
The replication context RC1 is changed to:
-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4
The replication context RC2 is changed to:
-RC2: no packets to forward, Multicast Session MS2, OSL = {}
(Multicast Session MS2 will be deleted)
When user {4} leaves G1, the group state for the L2TP tunnel goes
back to:
(G1, INCLUDE, {S1, S2})
Replication contexts become:
-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
(Multicast Session MS2 is re-established)
Author’s Address
Gilles Bourdon
France Telecom
38-40, rue du General Leclerc
92794 Issy les Moulineaux Cedex 9 - FRANCE
Phone: +33 1 4529-4645
EMail: gilles.bourdon@francetelecom.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.